codespaces

Today, we’re announcing that the ability to prebuild codespaces is entering general availability. A prebuilt codespace serves as a “ready-to-go” template where your source code, editor extensions, project dependencies, commands, and configurations have already been downloaded, installed, and applied so that new codespaces are available on-demand without any wait period. This helps significantly speed up codespace creations–especially for complex or large codebases.

With general availability, we’ve introduced a ‘prebuild in progress’ label in cases where a prebuild template creation is in progress to enable developers stay informed for when a given branch and machine type is ready for a fast codespace creation experience. Administrators now have more control on how often prebuild configurations are updated to manage Actions usage. They can also configure retention settings on prebuild templates to manage underlying storage costs. Additionally, with failure notifications, repository administrators can specify a set of individuals or teams to be informed via email in case a prebuild-associated workflow fails to help with efficient monitoring. Administrators can also temporarily pause a prebuild workflow run while fixing an underlying issue.

With general availability, organizations will be billed for Actions minutes required to run prebuild associated workflows and storage of templates associated with each prebuild configuration for a given repository and region. As an administrator, you can download the usage report for your organization to get a detailed view of prebuild associated Actions and storage costs for your organization-owned repositories.

Prebuilt codespaces are generally available for all GitHub Enterprise Cloud and Team organizations. Repository admins can head over to their repository’s settings page and create prebuild configurations under the Codespaces tab. Once set up, you can take advantage of fast codespace creation by selecting machine types with the ‘prebuild ready’ tag.

Check out the prebuilds documentation to get started!

When you work in a codespace, the environment you are working in is created using a development container, hosted on a virtual machine. If you don’t define a configuration in your repository, GitHub creates a codespace using a default Linux image. This Linux image includes common languages and runtimes such as Python, Node.js, JavaScript, TypeScript etc. to help you get started with an environment that you can further customize or use as is based on your team’s needs.

‘Zero-configuration’ getting started experience for machine learning users

With this update, we’ve released a new version of the default image that enables a seamless getting started experience for machine learning scenarios:

• The default image now has Jupyter pre-installed by default so that you can immediately run jupyter notebook or jupyter lab from the terminal to get started with your data science project.
• The default image also has the following commonly used machine learning specific Python libraries pre-installed by default:
  • For numeric computing: numpy, pandas, scipy
  • For data visualizations: matplotlib, seaborn
  • For model building: scikit-learn, tensorflow, keras, torch
  • For data fetching: requests
• Lastly, you can include any additional project-dependent Python packages in the requirements.txt file, and those will be automatically installed at a user scope when you create your codespace.

Additional updates

• Alongside these improvements, the default image has been updated with the following tools to optimize for speed and costs associated with default codespaces. We’ve also updated the major version of the image to 2 since the removal of these toolsets introduces breaking changes. While some of the tools are not included by default anymore, you can always add these by creating your own devcontainer configuration.
  
  Tools added:

  • Node 14
  • Node 16
  • Python 3.9
  • Python 3.10
  • Conda 4.12
  • Java 11
  • Maven 3.8
  • Ruby 3.0
  • Ruby 3.1
  • PHP 8.0
  • PHP 8.1
  • PHP Composer 2.3
  • Hugo 0.96
  Tools removed:

  • Node 12
  • Python 3.8
  • Conda 4.8
  • .NET 5.0
  • Ruby 2.7
  • PHP 7.2
  • PHP 7.3
  • PHP Composer 2.0
  • Hugo 0.90
  • Maven 3.6
  • PowerShell
  • Az CLI
  • Rust

• Lastly, as a part of this update, for tools that have LTS support (e.g. node, python), the default image will include the latest two LTS releases going forward.

To learn more, check out the latest Codespaces default image configuration.

Currently, codespaces are automatically stopped after 30 minutes of inactivity to avoid wasteful resources when they're not being used. Additionally, a default idle timeout can be set for a codespace of up to four hours.

We heard from many organization admins that they want to restrict idle timeouts for organization-owned codespaces as a measure of cost control. With this feature, we've added the ability for administrators to set a maximum idle timeout that applies to organization-owned codespaces. For instance, if the maximum idle timeout constraint is set to 15 minutes, then all organization-owned codespaces will be automatically stopped after 15 minutes of inactivity regardless of the default timeout set by individual developers.

We will continue adding additional policy constraints based on feedback, some of which include setting maximum retention periods, setting allowed container images, and more. We'd love your feedback on additional policies that will help your scenarios on Codespaces discussions.

For more information, see Restricting idle timeouts for organization-owned codespaces

Codespaces now has improvements that will streamline your experience when working with multi-repository and monorepo projects.

To enable teams to develop applications that span across multiple repositories (e.g. common in microservice architectures), we have added the ability for users to configure which permissions their codespace should have on creation. This means that users will no longer have to set up a personal access token inside of their codespace to clone or create pull requests for multiple repositories.

Additionally, if you're a part of a larger organization and have many teams working in a single repository (e.g. monorepo), Codespaces now supports multiple devcontainer.json files inside of your .devcontainer directory, as long as they follow the pattern of .devcontainer/${DIR}/devcontainer.json.

Lastly, to provide more flexibility during codespace creation, there's a new advanced create flow for Codespaces that allows you to select various options, such as branch, geographic region, machine type, and a specific dev container file while creating your codespace. If you want to skip the advanced creation flow, you can always go for the one-click create by selecting Create codespace on <branch name> to create a codespace with the default configuration.

With these updates, repositories can be setup with multiple devcontainers, each with permission sets, setup scripts, and a codespace configuration specific for certain sub-teams or developer roles (e.g. front-end, back-end). Then, developers can select the ideal devcontainer, machine type, and geographic region for their task during the codespace creation with the advanced flow, as needed.

Here are some helpful links to get you started!

• Configuring codespaces for multi-repository scenarios
• Configuring multiple devcontainers for a repository
• Codespaces advanced creation

Repository administrators can now configure how often/when prebuild configurations for a given branch should be updated. Prebuilds enable developers to startup Codespaces in seconds – regardless of repository size or complexity – by building your development environment beforehand. Previously, prebuild configurations were updated on every push made to a prebuild-enabled branch. During public beta, we heard from many repo admins requiring more control on how often their configurations should be updated based on their team’s processes as well costs associated with running Actions workflows to keep configurations up to date.

With this feature, admins can now make more nuanced trade-offs between environment “freshness” and Actions usage. For example, an admin working in a large organization may decide to update their prebuild configuration every hour rather than on every push to get the most economy and efficiency out of their Actions usage. While creating or updating prebuilds for a given repo and branch, repository admins can choose from three triggers to initiate a refresh:

• Every push (default): With this setting, prebuild configurations are updated on every push made to the given branch. This ensures that new Codespaces always contain the latest configuration, including any recently added or updated dependencies.
• On configuration change: With this setting, prebuild configurations are updated only when configuration files (ex. devcontainer) change. This ensures that developers always have access to a Codespace based on the latest configuration without having to run Actions workflows on every push made to the repo.
• Scheduled: With this setting, you can have your prebuild configurations update on a custom schedule only, regardless of any pushes made to the branch or updates made to associated configuration files. This can further reduce consumption of Actions minutes and give admins even more control on how often configurations should be updated.

For more information, see Configuring prebuilds for your repository

Currently, forwarded ports within codespaces can be set to private in which case they can be accessed only by the owner of the codespace, be shared with members of the organization or be set to public at which point anyone the URL is shared with can view the port. We heard from many organization admins that they want to disable public ports for organization-owned codespaces with the goal of ensuring that company assets can only be shared and accessed by members of the organization for security purposes.

With this feature, we have added the ability for organization admins to add port visibility constraints that enable them to control which visibility settings are available within organization-owned codespaces. For instance, admins will be able to disable the 'public' visibility port setting for desired repositories within their organization and enable developers to continue sharing ports only with members of their organization. This would be done to help preventing codespaces users from accidentally exposing company owned assets to unauthorized individuals.

We will continue adding additional policy constraints based on feedback, some of which include setting a maximum idle timeout, setting maximum retention periods, setting allowed container images, and more. We'd love your feedback on additional policies that will help your scenarios.

For more information, see Restricting the visibility of forwarded ports

Today, we’re announcing that the ability to prebuild codespaces is entering public beta. Prebuilding a codespace enables fast environment creation times, regardless of the size or complexity of your repositories. A prebuilt codespace will serve as a ‘ready-to-go’ template where your source code, editor extensions, project dependencies, commands, and configurations have already been downloaded, installed, and applied so that you don’t have to wait for these tasks to finish each time you create a new codespace.

As a part of this release we’ve made improvements to the set-up process for prebuilds, as well as added support for GitHub-managed Actions workflows that will automatically prebuild a codespace for any configured repository’s branch and region(s). Additionally, since prebuild configurations are built on GitHub Actions virtual machines, repository admins will have access to a rich set of logs to help with efficient debugging in case failures occur.

Prebuilt codespaces are available in beta for all GitHub Enterprise Cloud and Team organizations. Repository admins can head over to their repository’s settings page and create prebuild configurations under the Codespaces tab. Once set up, you can take advantage of fast codespace creation by selecting machine types with the ‘prebuild ready’ tag.

Check out the prebuilds documentation to help you get started!

We've gotten a lot of feedback from users that it's hard to differentiate multiple codespaces in the same repo, especially if they're on the same branch. To make it a little easier to tell codespaces apart, we've started automatically creating "friendly" (and fun) names for your codespaces.

If you don't like our names, we're also working on the ability for users to re-name their codespaces.

For more information on Codespaces, see "GitHub Codespaces overview".

Currently, Codespaces users in organizations in Team and Enterprise Cloud plans can use any machine type, from 2-core to 16-core (or even 32-core). We've heard from many organization administrators that they want the ability to restrict which machine sizes repositories in their organization should have access to as a means of cost control, and have implemented a new Codespaces policy feature to allow admins this level of control.

Organization admins can now visit their organization's settings page and create Codespaces policies to restrict which machine types repositories in their organization can use. For instance, an admin can restrict certain repositories to only access 2-core and 4-core machines, while granting other, more compute intensive repositories, access to 16-core machines.

In the future, the Codespaces policy feature will be expanded to include additional constraints, including setting a maximum idle timeout, restricting which port forwarding settings are allowed, and more. We'd love your feedback on other constraints you're interested in.

For more information, see "Restricting access to machine types".

Codespaces have been constrained to specific users or all members of an organization, which, while great for day-to-day software development, didn't allow everyone in an organization to participate. That's why we're so happy to announce that as of today, you can invite outside collaborators to access Codespaces.

Outside collaborators expand Codespaces to use cases like interviewing, training, and teaching, where you can easily add outside collaborators to specific repositories within your organization (or in certain cases, giving each collaborator their own repository). Start by granting "All members and outside collaborators" access to Codespaces, then inviting collaborators to repositories you want them to use Codespaces in.

For more information, see "Enabling Codespaces for your organization."

Dotfiles are a common way to specify custom, user-specific behavior for applications (like Vim or Emacs) and shells on your codespaces. If enabled, dotfiles stored in a user's public dotfiles repository would be used for this configuration. With this change, any user owned repo, including private repos, can be used to install dotfiles into your codespaces.

For more information, see "Dotfiles".

Today, Codespaces is rolling out progressively for organizations on Team and Enterprise Cloud plans. Organization owners can enable Codespaces in organization settings.

Codespaces can be used for free through September 10th, 2021 (PST) for enabled organizations in Team and Enterprise Cloud plans, after which billing begins.

For users in individual plans, we’re extending the existing Codespaces beta. For those in the beta, access will remain and we’ll share updates on what’s coming in the near future.

Read more on our Codespaces page and in docs.