Community AMA - GitHub Codespaces

[tuves]

We are hosting an async AMA that will be open for 24 hours!

We will feature three GitHub Codespaces PMs: @craiglpeters, @cmuto09, and @thisiskirch and Community Manager @otter-computer to answer all your GitHub Codespaces questions. We'll have the AMA open for 24 hours to ensure global participation. No need to register--just join in on this discussion, and ask away!

If you have specific feedback/feature requests, please share them in the appropriate product categories
If you have questions re: our product roadmap, check out our public roadmap
Please keep questions/comments clean and friendly, refer to our Code of Conduct + Community Guidelines if you have any concerns

[samus-aran]

@markpatterson27 (one of our verified GitHub Global Campus teachers) had a couple of fantastic questions! 👍

Q: Best practices for speeding up codespace devcontainer builds? If I'm using anything other than the default GH kitchen sink image, builds can take several minutes (sometimes 5+ minutes) which is not ideal in the middle of a lesson.

Q: Are there any plans for OR Is it possible to have, organisation wide pre-build images? Typical education use for codespaces is to have several/lots of students using the same image but on their own seperate repos. This means each student has to wait for the same custom image to build when launching a codespace from their (GH classroom assignment) repo. (This is different from more typical use where you might have several people working in the same repo, thereby being able to make use of the repo level image pre-build.)

[craiglpeters]

Thanks for the great questions. If a repo is large, or there are many dependencies and steps to take to get a codespace going, the container build step can take some time. As @markpatterson27 clearly understands, using the default or universal container image is a great way to speed things up as it is baked into the default Codespaces environment, so no pull or build is required, and it contains quite a lot of tools. If you extend the image with dev container features or using dev container lifecycle events, or use a different dev container base image then the container needs to be built. Using Codespaces Prebuilds will do that once, and store it, so that each codespace started from the branch(es) configured will not have to rebuild the container.

The second question indicates that @markpatterson27 also understands that Codespaces Prebuilds are (currently) configured for a specific repository and its branches. We are discussing how to allow that same prebuild to move with forks of that repository, which is a common classroom and open source workflow. We do plan to implement this, but we do not yet have a clear timeline we can share for that.

In the mean time it may possible to speed things up a bit in some situations. The dev container can be built ahead of time using the command line tool, or the devcontainer-ci GitHub Action, and pushed to a container registry (possibly GitHub Container Registry) and pulled for each new codespace that is created from forks or copies. This is accomplished by including two dev container definitions in the repository. One for the action to use, and the other for the creation of the codedspace. For example the .devcontainer folder could have this structure.

.devcontainer\
       \devcontainer-build\.devcontainer.json.  // contains the build instructions that the action or command line uses to build the dev container -- can include image creation and container creation lifecycle steps
      .devcontainer.json. // contains the `image` reference to pull the image, and any post container creation lifecycle steps

This will help if container creation steps take a while, but the resulting dev container image is not large.

[markpatterson27]

@craiglpeters I've done pre-building a docker image before for a codespace, just using the normal docker build tools and ghcr. Does the dev container CLI (and CI action) do more and also include devcontainer features in the pre-build? Are there any other settings or customizations (from devcontainer.json) that get included in the dev container CLI pre-build?

[craiglpeters]

Yes, the action and the devcontainer CLI respect all the devcontainer.json specified configurations

[otter-computer]

From the community:

@gtxg16 asked about SSH-ing into a Codespace. How do you SSH into a Codespace? Is it possible to do so without the gh CLI so it can then be used in combo with other tools and automations?

[jkeech]

It's not really possible to SSH into a codespace without using gh since codespaces do not have any public IP addresses. gh bootstraps the SSH connection by first establishing a secure tunnel to the codespace machine, and then running ssh through that tunnel.

One possible solution though is to run gh codespace ssh --config to set up SSH configuration locally so that you can directly run ssh, which proxies through gh to bootstrap the connection.

[otter-computer]

From the community:

@Kirari04 asked if it's possible to restore a deleted Codespace after the repository it was attached to is deleted. Are you able to restore it in this case?

[cmuto09]

Great question! The answer depends on how long ago the codespace was deleted. If the codespace was recently deleted (within the last week), then it should be recoverable regardless of the repository state. This is because the repository association affects clone behavior on creation of a codespace (as well as token permissions); once a Codespace has been created subsequent resumptions read from that codespace's storage record rather than re-pulling from the repository.

However if the codespace's storage record has been deleted, it is no longer recoverable.

I will update when I get confirmation on the amount of time a codespace remains in a recoverable state. Updated! Within 1 week of deletion a codespace is recoverable.

Otherwise, does the above answer your question?

[mrclemds]

Hi, thanks for organizing this !

My question is about limiting resource usage,
Could it be considered to have the possibility to transfer ownership of a Codespace to someone else within an organization ?
My idea is to have a developer to work on a feature and then give it to the QA through the "transfert".
This way we consume the build time and store the built files only once.

[craiglpeters]

Glad you're here! While Codespaces can be collaborated within using tools that the IDE atop brings (for VS Code see Live Share, for JetBrains see Code With Me and for Jupyter share the Server port), the repo used for starting the codespace is tied to the user who started it, thus any push is using that user's identity so care needs to be taken. For that reason we do not support transferring a codespace to another user. You can, and should, use the underlying repository to share by pushing the changes (commit and push) so that other teams can collaborate. If build times are of a concern, the build artifacts can be published to GitHub Packages, and thus reused by the partner team without a rebuild being required. Hope this helps!

[otter-computer]

From the community:

@wbyatt-kr asked, when using a docker compose based devcontainer configuration, is it possible to debug or inspect logs from containers that aren't the main container?

[samruddhikhandale]

Hi 👋

You can stream the logs of the spun up containers with docker-compose logs -f

In my case, I added a docker-in-docker Feature to my devcontainer.json to access the docker commands. Then docker-compose logs -f helped stream the logs of other spun up containers.

[wbyatt-kr]

Hi @samruddhikhandale thank you for your suggestion, but I'm trying to avoid this.

My team right now uses docker compose on local machines to run our suite of services, but the end up having to spend a fair bit of time administering the cluster of services. What I'd like to achieve is a development workflow where they can laser focus on the particular service they're working on, and the operation of the rest of the services is abstracted away, allowing them to focus on their task instead of administering development environments.

Docker-in-docker does not fix this problem, it just moves the administration off of local and into a codespace, so at that point I'm paying for all the additional compute without any improvement in developer workflow.

Codespaces allows me to create docker-compose.yml file for my devcontainer that specifies additional services to be run alongside the devcontainer I'll actually be working in. I would like to be able to access the logs for those additional containers. It is very strange to me that I can create and run containers that I have no insight into.

[tuves]

Thank you to everyone who participated in our Codespaces AMA! Though this event is over, if you have questions or feedback for GitHub Codespaces, please start a new discussion in the Codespaces category!