Update dev container for swift #1238

damuellen · 2022-01-05T18:38:49Z

Changing the setting and installed extension. To reflect the latest state of Swift development.
introducing-swift-for-visual-studio-code

Remove unnecessary package

swift-format

ghost · 2022-01-05T18:39:02Z

All CLA requirements met.

adam-fowler · 2022-01-05T22:52:39Z

There are quite a lot of changes in here. Not sure we need to include all of the extensions in here. Plus I think it is worthwhile bringing in @vknabel to discuss if there should be a transition from the original swift extension or should we add a new swift devcontainer for the SSWG extension.

I think this is also a good time to discuss what is actually needed in the devcontainer. For me there appears to be a lot of unnecessary stuff here. Why are we installing node, python? Is this something MS expects?

Including @0xTim

adam-fowler · 2022-01-05T22:54:51Z

We can remove the lldb install for sure though, it is overriding the swift version of lldb.

0xTim · 2022-01-06T12:49:05Z

I'm guessing node is needed to run the VSCode environment. Python was probably installed for LLDB or to install Swift, but that's now been removed.

As for all the extra extensions - I agree that we're installing a lot we probably don't need. Sticking to just "sswg.swift-lang" as a default would be my preferred option (I have no idea if we need to list dependencies like LLDB however)

adam-fowler · 2022-01-06T13:14:05Z

You don't need node.js, well at least I can build a devcontainer which doesn't install it. Could it be included in the swift docker images already?

We don't need to include vscode-lldb as the swift extension automatically installs it.

adam-fowler

As I've said in previous comments, can we keep this to just the sswg.swift-lang extension. Plus we need to work out what we want to do with the other swift vscode extension.

adam-fowler · 2022-01-06T16:21:34Z

containers/swift/.devcontainer/devcontainer.json

-		"sde.languageservermode": "sourcekite",
-		"swift.path.sourcekite": "/usr/local/bin/sourcekite"
+		"lldb.library": "/usr/lib/liblldb.so",
+		"sourcekit-lsp.toolchainPath": "/usr/bin/",


You shouldn't need to setup sourcekit-lsp paths

adam-fowler · 2022-01-06T16:39:24Z

containers/swift/.devcontainer/Dockerfile

@@ -14,15 +14,8 @@ ARG USER_GID=$USER_UID
 COPY library-scripts/common-debian.sh /tmp/library-scripts/
 RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
    && /bin/bash /tmp/library-scripts/common-debian.sh "${INSTALL_ZSH}" "${USERNAME}" "${USER_UID}" "${USER_GID}" "${UPGRADE_PACKAGES}" "true" "true" \
-    && apt-get -y install --no-install-recommends lldb python3-minimal libpython3.7 \


👍 swift docker images install a later version of python.

vknabel · 2022-01-06T23:38:09Z

Hi, thanks for the mention. I haven't found time for a specific migration plan, yet. But I do also vote for sswg.swift-lang without msde.

The few benefits msde still has, are mostly restricted to very old Swift versions and other niche use cases. Both user groups won't use this dev container.

Regarding the other extensions I'd also prefer using sswg.swift-lang only. Removing extensions or features is hard and we will never have such a great opportunity to do so.

In case we wouldn't, we'd need set up and install all formatter extensions (for apple's and nicklockwood's), not just one to stay neutral and not opinionated. And in that case, also add Swiftlint as it's too widespread. IMHO far too much extensions.

(Do I remember correctly, sswg.swift-lang also has a formatter built in?)

Regarding the other extensions: haven't heard of them until now. But to be fair, haven't been active for a while.

Slightly OT: msde will either be removed or transformed into an extension bundle. Legitimate features will be split into multiple extensions. The features sswg.swift-lang provides will probably be opt-in and deprecated.

damuellen · 2022-01-07T14:40:38Z

I removed the other extensions, even though they are all quite useful.

0xTim · 2022-01-07T15:08:09Z

containers/swift/.devcontainer/devcontainer.json

-		"vknabel.vscode-swift-development-environment",
-		"vadimcn.vscode-lldb"
+		"sswg.swift-lang",
+		"vadimcn.vscode-lldb",


This is not required as it's pulled in automatically by sswg.swift-lang

0xTim

LGTM other than the LLDB requirement as it's pulled in automatically

0xTim · 2022-01-07T15:13:07Z

@tomerd I wonder if there's anyone we can poke about getting this added as an official language rather than a community one

0xTim · 2022-01-07T15:15:55Z

containers/swift/.devcontainer/devcontainer.json

@@ -16,9 +16,7 @@
 	],

 	// Set *default* container specific settings.json values on container create.
-	"settings": {
-		"lldb.library": "/usr/lib/liblldb.so",


@damuellen sorry I may have confused things - this is definitely still required - it's the "vadimcn.vscode-lldb", line in extensions we don't need

adam-fowler · 2022-01-07T16:41:16Z

LGTM

@0xTim Regarding Official vs Community. We can just edit the .devcontainer to say "Swift" instead of "Swift (community)". I'm not sure if that's affects these changes getting merged.

Chuxel · 2022-01-07T16:54:19Z

@adam-fowler The "Community" indicator is more about whether it's a 1st party maintained definition or not. More of a statement around support and ongoing maintenence than validity.

Otherwise, this PR looks great! Happy to merge if you feel like it is ready.

adam-fowler · 2022-01-07T17:01:20Z

@adam-fowler The "Community" indicator is more about whether it's a 1st party maintained definition or not. More of a statement around support and ongoing maintenence than validity.

Well it will be maintained by the Swift Server working group (group promoting swift on server consisting of a mixture of Apple employees and various people from other organisations). If we can't have Swift, Swift(SSWG) might work. Thoughts @0xTim. I guess @tomerd should have final say on this.

damuellen · 2022-01-07T17:06:06Z

@Chuxel Should I open a new PR with squashed commits ?

Chuxel · 2022-01-07T17:29:44Z

@damuellen Nope, no need - I'll do that at merge time (via "Squash and merge").

@adam-fowler In concept, we could have it say (Swift Server Working Group). This appears in the "Add Dev Container Configuration Files" UX - or (SSWG) if you think that has enough meaning to users.

The README should also get updated with the go-forward owner conacts we can "@" in the event an issue or PR is raised. Right now the README says @cloudnull.

0xTim · 2022-01-08T15:29:52Z

@Chuxel if we can have just Swift in the name (without community) that would be great. Understand if that's not possible yet unless we can find an MS staff to step up.

In terms of the README @damuellen if you want to update that for Swift, I'm happy to be listed as a maintainer. It doesn't look like the SSWG team can be tagged so you can list me, @adam-fowler if he's happy, yourself if you want and @cloudnull if he still wants to be tagged

damuellen · 2022-01-08T15:59:09Z

@0xTim Sure I can do this. But I will still wait for the feedback of others.

adam-fowler · 2022-01-08T16:19:40Z

Yeah you can put me on there

Chuxel · 2022-01-11T00:07:40Z

@0xTim Yeah this is more about signaling who is maintaining and keeping the images up to date, etc. The implicit assumption ends up being the VS Code team.

I'd be happy to change this to something indicating the organization maintaining the image rather than (Community), however. e.g. (Official Swift Working Group Definition)

Otherwise, happy to merge.

tomerd · 2022-01-11T00:39:30Z

@adam-fowler @0xTim lets discuss and finalize on our next meeting

adam-fowler · 2022-10-14T17:22:24Z

Hi @bamurtaugh it looks like we will be going forward with hosting our own versions of the swift devcontainer templates. I am away for the next 10 days so will start looking into it once I get back.

bamurtaugh · 2022-10-14T17:37:48Z

Fantastic, thanks for letting us know, @adam-fowler!

adam-fowler · 2022-11-11T08:46:49Z

Hi @bamurtaugh ,
We are going to host our own version of the swift dev container template. I have setup a repo https://github.com/swift-server/vscode-swift-devcontainer. If you could have a look at it to verify everything is ok that'd be great.

The template at the moment is pretty much a copy of the one in vscode-dev-containers. It currently has a number of options (install zsh, update packages, install NodeJS) which we may want to change. Are these options expected to be available or do we have free reign to change as we see fit?

bamurtaugh · 2022-11-11T21:03:23Z

Hi @adam-fowler! Thanks so much for sharing this. The template looks good to me! One note is you could consider renaming the repo to something like "swift-devcontainer" as we're broadening dev containers to any tool with the open spec. I also think the readme looks great - one small change you might consider is that the Remote - Containers extension has been renamed to "Dev Containers," but the link will still work either way.

I'm also sharing it in our new community Slack channel for other eyes. We'd love to have you join our community Slack by the way - here's where you can comment if you'd like to join: https://github.com/orgs/devcontainers/discussions/3.

Are these options expected to be available or do we have free reign to change as we see fit?

The contents of the template are totally up to your team - please feel free to adjust it as you see fit. As it sounds like these could be breaking changes for users currently using the template, we might recommend putting info in the REAMDE and/or a pinned issue in your repo to notify users about changes.

adam-fowler · 2022-11-12T08:04:31Z

The contents of the template are totally up to your team - please feel free to adjust it as you see fit. As it sounds like these could be breaking changes for users currently using the template, we might recommend putting info in the REAMDE and/or a pinned issue in your repo to notify users about changes.

Any changes we would make would be heavily publicised. Depending on responses we could also create a legacy container which was a copy of the original.

How do I go about publishing this template and will it clash with the currently published one?

Chuxel · 2022-11-12T16:29:35Z

@adam-fowler The starter template has some info on this - https://github.com/devcontainers/template-starter#distributing-templates. You can use a GitHub Action to create the needed OCI Artifact - just copy the .github folder into your repo and you'll have a release workflow you can manually trigger. You can update the triggers based on how you want to manage things as well. Setup is completely automatic. You can then make the artifact public (info in the repo README) so anyone can download it.

You can do a PR to add your template collection to the index so it shows up in UX (https://github.com/devcontainers/template-starter#adding-templates-to-the-index). This is one time setup for the repo, so you can add as a many template vacations as you want at that point and they'll all show up.

We can then remove the one here from the index just by deleting the devcontainer-template.json file so there's no conflict.

adam-fowler · 2022-11-18T15:54:10Z

@Chuxel Unfortunately Apple won't allow the usage of the GH action. So I need to do the OCI Artifact generation and release manually

bamurtaugh · 2023-01-05T19:55:25Z

Hey @adam-fowler, happy new year! I just wanted to check in - please let us know if you needed any help with releasing your Template, we're happy to help.

adam-fowler · 2023-01-09T19:50:32Z

Hi, I just haven't got around to it. I'll see if I can find time this week.

adam-fowler · 2023-01-14T16:15:46Z

@bamurtaugh having looked through all the documentation and played with the devcontainer cli tool can I just use

devcontainer template publish <path to folder containing devcontainer-template.json>

bamurtaugh · 2023-01-17T20:03:20Z

@adam-fowler, the templates publish command is a good choice!

Which container registry are you going to use?

adam-fowler · 2023-01-18T14:37:22Z

@bamurtaugh I hadn't really thought about that. I assume we would use the ghcr.io one. I can verify that.

adam-fowler · 2023-01-19T21:38:00Z

@bamurtaugh can we use hub.docker.com?

bamurtaugh · 2023-01-19T21:59:54Z

Yes! You can distribute using any OCI registry that implements the OCI Artifact Distribution Specification: https://containers.dev/implementors/templates-distribution/#oci-registry.

adam-fowler · 2023-02-10T09:17:09Z

Hi, we're back to publishing in ghcr.io.

First I logged into ghcr.io

echo $CR_PAT | docker login ghcr.io -u adam-fowler --password-stdin

Then I tried to publish the template using

devcontainer templates publish -r ghcr.io -n swift-server/swift-dev-container ./src

But am getting the following error

[2 ms] @devcontainers/cli 0.27.1. Node.js v16.15.0. darwin 22.1.0 arm64.
[2 ms] Packaging template collection...
[3 ms] Processing template: swift...
[14 ms] Packaged 1 templates!
[14 ms] Processing template: swift...
[15 ms] Fetching published versions...
[905 ms] [httpOci] Could not fetch bearer token for 'ghcr.io': Error: HTTP 403: Forbidden
[906 ms] [httpOci] ERR: Failed to fetch Bearer token from registry.
[906 ms] Request failed
[906 ms] (!) ERR: Failed to publish 'ghcr.io/swift-server/swift-dev-container/swift'

I have also tried namespace adam-fowler/swift-dev-container and also logging in as swift-server and neither of those work either.

samruddhikhandale · 2023-02-10T17:07:10Z

Hi @adam-fowler 👋

devcontainer templates publish -r ghcr.io -n swift-server/swift-dev-container ./src

Would it be possible to append --log-level trace to the above command ☝️ and paste the output here? thanks!

adam-fowler · 2023-02-10T17:12:37Z

Here you go

[1 ms] @devcontainers/cli 0.27.1. Node.js v16.15.0. darwin 22.1.0 arm64.
[1 ms] Packaging template collection...
[2 ms] Processing template: swift...
[12 ms] Packaged 1 templates!
[12 ms] Processing template: swift...
[12 ms] > input: ghcr.io/swift-server/swift-dev-container/swift
[12 ms] >
[12 ms] > resource: ghcr.io/swift-server/swift-dev-container/swift
[12 ms] > id: swift
[12 ms] > version: latest
[12 ms] > owner: swift-server
[12 ms] > namespace: swift-server/swift-dev-container
[12 ms] > registry: ghcr.io
[12 ms] > path: swift-server/swift-dev-container/swift
[12 ms] Fetching published versions...
[492 ms] [httpOci] Attempting to authenticate via 'Bearer' auth.
[495 ms] [httpOci] No authentication credentials found for registry 'ghcr.io'. Accessing anonymously.
[495 ms] [httpOci] Attempting to fetch bearer token from:  https://ghcr.io/token?service=ghcr.io&scope=repository:swift-server/swift-dev-container/swift:pull
[891 ms] [-] HTTP request failed with status code 403: : Forbidden
[892 ms] [httpOci] Could not fetch bearer token for 'ghcr.io': Error: HTTP 403: Forbidden
[892 ms] [httpOci] ERR: Failed to fetch Bearer token from registry.
[892 ms] Request failed
[892 ms] (!) ERR: Failed to publish 'ghcr.io/swift-server/swift-dev-container/swift'

joshspicer · 2023-02-10T17:36:24Z

Right now there are several ways to provide registry credentials to the CLI. Unfortunately we don't yet have support for reading from OS credential helpers (like what is probably being used on your Mac when you do that docker login).

Here's the code that looks for the credentials:

https://github.com/devcontainers/cli/blob/d02379c581b55233946f407a09a8ee1eeeff5fb4/src/spec-configuration/httpOCIRegistry.ts#L131-L164

The quickest way for you to get publishing from your local machine should be to do:

GITHUB_TOKEN="$CR_PAT" devcontainer templates publish -r ghcr.io -n swift-server/swift-dev-container ./src

joshspicer · 2023-02-10T17:40:04Z

Other auth options include:

Adding a $HOME/.docker/config.json with your credentials (like how docker login does natively on linux)
Using our custom env variable DEVCONTAINERS_OCI_AUTH are also options.
Using the devcontainers/action GitHub action to handle the GITHUB_TOKEN credential for you (this is the way we see most people publishing these days, although we certainly want to support the scenario you're in).

adam-fowler · 2023-02-10T17:40:51Z

bingo, looks like that worked

joshspicer · 2023-02-10T17:41:31Z

Awesome! Making a note to document this more clearly today.

ref: microsoft/vscode-dev-containers#1238

adam-fowler · 2023-02-13T14:38:34Z

@bamurtaugh Here is the PR for adding the Swift dev container devcontainers/devcontainers.github.io#150. I hope it all works.

At the moment it looks like the old devcontainer, but we hope to update to the newer devcontainer feature style that all the new containers seem to have moved to.

samruddhikhandale · 2023-02-13T18:09:12Z

Thanks, looks good to me! ✨

Have #1713 opened to deprecate the older Template.

adam-fowler · 2023-02-13T18:14:31Z

Nothing happens when I select either of these. I'm currently on a really bad internet connection so don't know if that is the cause.

bamurtaugh · 2023-02-13T20:30:47Z

Thanks so much for the PR, @adam-fowler! This is really exciting, and we really appreciate your collaboration.

I'm able to add the Swift Template successfully in the Dev Containers extension. If you're able to 1) try again as you get a more stable internet connection, 2) let us know if Swift is the only Template this is happening for (suggesting there is something unique there for some reason), that'd be great.

0xTim · 2023-02-13T20:39:53Z

I've tested this and it's working for me so I think we're all good!

adam-fowler · 2023-02-14T07:49:19Z

Looks like it's working now
I also managed to update it with a minor fix

* Add docs for `devcontainer templates publish` ref: microsoft/vscode-dev-containers#1238 * Update publish.md * Update publish.md * Update docs/templates/publish.md Co-authored-by: Samruddhi Khandale <[email protected]> * Update publish.md --------- Co-authored-by: Samruddhi Khandale <[email protected]>

damuellen added 3 commits January 5, 2022 18:40

Update Dockerfile

1bfaf16

Remove unnecessary package

Update devcontainer.json

3152d41

Update devcontainer.json

147ecb5

swift-format

damuellen mentioned this pull request Jan 5, 2022

Ensure GH CodeSpaces work swiftlang/vscode-swift#81

Closed

adam-fowler reviewed Jan 6, 2022

View reviewed changes

Update devcontainer.json

2a98cff

0xTim reviewed Jan 7, 2022

View reviewed changes

Update devcontainer.json

e1ebad2

0xTim reviewed Jan 7, 2022

View reviewed changes

Update devcontainer.json

f4e9dcf

Update README.md

e4bc64f

joshspicer added a commit to devcontainers/cli that referenced this pull request Feb 10, 2023

Add docs for devcontainer templates publish

8897cf4

ref: microsoft/vscode-dev-containers#1238

joshspicer mentioned this pull request Feb 10, 2023

Add docs for devcontainer templates publish devcontainers/cli#410

Merged

Update dev container for swift #1238

Update dev container for swift #1238

Conversation

damuellen commented Jan 5, 2022

ghost commented Jan 5, 2022 • edited by ghost Loading

adam-fowler commented Jan 5, 2022

adam-fowler commented Jan 5, 2022

0xTim commented Jan 6, 2022

adam-fowler commented Jan 6, 2022 • edited Loading

adam-fowler left a comment

Choose a reason for hiding this comment

adam-fowler Jan 6, 2022

Choose a reason for hiding this comment

adam-fowler Jan 6, 2022

Choose a reason for hiding this comment

vknabel commented Jan 6, 2022 • edited Loading

damuellen commented Jan 7, 2022

0xTim Jan 7, 2022

Choose a reason for hiding this comment

0xTim left a comment

Choose a reason for hiding this comment

0xTim commented Jan 7, 2022

0xTim Jan 7, 2022

Choose a reason for hiding this comment

adam-fowler commented Jan 7, 2022

Chuxel commented Jan 7, 2022

adam-fowler commented Jan 7, 2022

damuellen commented Jan 7, 2022

Chuxel commented Jan 7, 2022 • edited Loading

0xTim commented Jan 8, 2022

damuellen commented Jan 8, 2022

adam-fowler commented Jan 8, 2022

Chuxel commented Jan 11, 2022

tomerd commented Jan 11, 2022

adam-fowler commented Oct 14, 2022

bamurtaugh commented Oct 14, 2022

adam-fowler commented Nov 11, 2022

bamurtaugh commented Nov 11, 2022 • edited Loading

adam-fowler commented Nov 12, 2022

Chuxel commented Nov 12, 2022 • edited Loading

adam-fowler commented Nov 18, 2022

bamurtaugh commented Jan 5, 2023

adam-fowler commented Jan 9, 2023

adam-fowler commented Jan 14, 2023

bamurtaugh commented Jan 17, 2023

adam-fowler commented Jan 18, 2023 • edited Loading

adam-fowler commented Jan 19, 2023

bamurtaugh commented Jan 19, 2023

adam-fowler commented Feb 10, 2023 • edited Loading

samruddhikhandale commented Feb 10, 2023

adam-fowler commented Feb 10, 2023

joshspicer commented Feb 10, 2023 • edited Loading

joshspicer commented Feb 10, 2023

adam-fowler commented Feb 10, 2023

joshspicer commented Feb 10, 2023

adam-fowler commented Feb 13, 2023

samruddhikhandale commented Feb 13, 2023

adam-fowler commented Feb 13, 2023

bamurtaugh commented Feb 13, 2023

0xTim commented Feb 13, 2023

adam-fowler commented Feb 14, 2023 • edited Loading

ghost commented Jan 5, 2022 •

edited by ghost

Loading

adam-fowler commented Jan 6, 2022 •

edited

Loading

vknabel commented Jan 6, 2022 •

edited

Loading

Chuxel commented Jan 7, 2022 •

edited

Loading

bamurtaugh commented Nov 11, 2022 •

edited

Loading

Chuxel commented Nov 12, 2022 •

edited

Loading

adam-fowler commented Jan 18, 2023 •

edited

Loading

adam-fowler commented Feb 10, 2023 •

edited

Loading

joshspicer commented Feb 10, 2023 •

edited

Loading

adam-fowler commented Feb 14, 2023 •

edited

Loading