Changelog
Feature updates and improvements to Gitpod.
Azure DevOps Integration
We’re excited to announce that our Gitpod Enterprise offering now supports integration with Azure DevOps. This allows Enterprise users to connect their Azure DevOps accounts, enabling seamless access to repositories and enhancing collaborative development workflows within Gitpod.
You can learn more about configuring the Azure DevOps integration in our docs and start using it today.
Interested in exploring how Gitpod Enterprise can benefit your team? Schedule a demo to see our Azure DevOps integration and other Enterprise features in action.
Activity based prebuilds
Triggers for prebuilds are changing from external webhook events to internal workspace creation events emitted within Gitpod. This change reduces the cost of prebuilds by eliminating redundant prebuilds for repositories that have been set up with prebuilds but where workspaces are not being actively created. This removes the requirement for webhook installation, making enabling prebuilds easier and faster, whilst also reducing architectural and network complexity for Gitpod Enterprise customers with privately networked installations. Existing prebuild settings such as the commit interval, branch filter and branch name pattern will still take effect.
Existing prebuilds will continue to use webhook triggering, so no action is required. However, new repository prebuilds settings will use this new behavior by default.
To convert any existing repository prebuild settings to remove webhook triggering and use activity-based prebuilds:
- Disable prebuilds for each repository setting
- Delete any repository webhook connections to Gitpod
- Enable prebuilds for each repository setting
For more details, refer to the documentation on prebuilds.
Audit logs for Gitpod Enterprise
Gitpod Enterprise customers now have access to audit logs to improve proactive monitoring of development environments for unexpected behaviors or for post-incident forensics or analysis.
Audit logs are stored in a data store within the Gitpod instance for 90 days and can be retrieved via API by users with the “owner” role.
Audit events are also forwarded to application logs. Gitpod Enterprise customers can access application logs directly from CloudWatch.
Gitpod logs audit events for every internal API call which including the following examples:
Workspace start, stop, delete
Update to members of organizations
Changes to organization policy settings
Each audit event includes a unique instance id, timestamp, the API action performed, the actor who performed the action and any arguments. An example:
{
"id": "1ac75456-ae7d-4233-9914-32d124fa35c3",
"timestamp": "2024-06-24T13:29:36.484Z",
"action": "getTeamProjects",
"organizationId": "3d5e4ee2-7e5f-468f-b027-276a65518784",
"actorId": "e2eb4315-1ce5-4c5b-b1a1-d6a891c08a56",
"args": "[\"3d5e4ee2-7e5f-468f-b027-276a65518784\"]"
}
Any breaking changes to audit log actions or arguments will be made with sufficient prior communication to their release.
See the API documentation for more.
Frequently asked questions
Are audit logs available in the dashboard?
Audit logs are only available programmatically either through the API or directly from logs.
Can the audit log retention be configured?
Audit logs are retained within Gitpod for 90 days now. Currently, this value cannot be configured yet!
Are events tracked within the development environment itself?
Gitpod audit logs only apply to the Gitpod platform which includes orchestration and administration of workspaces, but does not extend to actions taken within workspaces.
Do audit logs track changes to environment configurations?
Changes to any organization settings or policies are shown in logs. Changes to the .gitpod.yml
definitions are kept in source control history in your SCM.
JetBrains RustRover support now available in Gitpod
We’ve added support for JetBrains RustRover in Gitpod. You can now use RustRover’s advanced features for Rust development directly within your Gitpod workspaces. This includes enhanced code analysis, refactoring, and debugging capabilities tailored for Rust projects.
For detailed instructions on setting up and using RustRover in Gitpod, check out our documentation.
Customizable default role for new organization members
You can now configure the default role for new members who join your Gitpod Organization. Organization owners can adjust the setting in the organization settings and set the default to Collaborator, Member, or Owner. Collaborator users have restricted access and cannot see information such as other invited members, or repository settings.
Learn more about configuring member roles in our docs.
Limit available workspace classes and editors
We’ve expanded organization policies to offer more control over available workspace classes and editors.
Repository workspace class policy: Besides restricting workspace classes for your organization, you can now limit available classes or set a default class for each repository. This can prevent unexpected costs from accidental overuse, but also set a default workspace class for repositories that need a larger class to run better.
Organization and repository editor policy: Organization owners can now limit the available editors to all organization members, and then select which editors are available for each repository within your organization. This can offer consistent editor options, as well as prevent use of unsupported editors for your projects.
Read more about organization policies in our docs.
Simplified repository management
We’ve simplified how you configure repositories in Gitpod by replacing projects with repository settings, and introduced a new prebuilds activity page that aggregates all prebuilds across all repositories in your organization in a single view.
The new repositories page is using a compact list for all the repositories you’ve added to your organization, and you can now glance over the list and quickly filter for repositories that have prebuilds enabled. Repository settings also come with an intuitive settings layout, following the layout of other settings in Gitpod.
The organization-wide prebuilds page now lists all prebuilds that are happening in your organization and lets you filter prebuilds for a specific repository, as well as filter by status.
Both pages are accessible to all organization members, except the ones with collaborator access. Learn more in our documentation.
Collaborator Role for restricted access to Gitpod
Organization owners can now invite individuals as Collaborators to an organization with restricted access to only start workspaces. Collaborators cannot access any other organization resources like usage, members, or projects. To change the role of a member to a Collaborator, visit the members page in your organization.
See Members for more.
Restrict the Workspace classes available in your Gitpod Organization
Organization owners can now restrict the workspace classes that are available to their organization. Restricting workspace classes can be useful for preventing unexpected costs, or simply for removing workspace classes which are not useful in a specific organization’s context. Members of the organization will then no longer see the workspace class as an option in the various Gitpod interfaces.
See Workspace Classes and Organization Policies for more.
Take Gitpod to your local command line
Workspaces that include all the tools developers need to start work and become ready-to-code are even more accessible and flexible, with the new Gitpod CLI for personal workspace management.
For developers you can now start and manage workspaces directly from your terminal, composing with your other favorite command-line utilities, and writing custom scripts.
For platform engineers you can now incorporate the CLI into your own internal developer platform to bring ready-to-code workspaces to your developers through deeper integrations.
Please note: The Gitpod CLI is an additional CLI to the existing CLI (
gp
) that is available in all Gitpod workspaces. In future these two experiences will be aligned.
Getting Started
To get started, install the CLI with the following command:
brew install gitpod-io/tap/gitpod
Everything installed? Let’s login and start using the CLI to create and manage workspaces.
Login to your Gitpod host
Using browser-based or token-based authentication:
gitpod login
to login to Gitpod.gitpod login --host="yourcompany.gitpod.cloud"
for Gitpod Enterprise.gitpod login --token <access-token>
to authenticate with an Access Token.
Note: Access tokens are generated from your User Settings in the Gitpod dashboard.
Tip: Use
gitpod whoami
to see your authenticated organization, host, etc.
Create and open a workspace in your editor
gitpod workspace create https://github.com/gitpod-io/empty --open
Or, create and open a workspace with SSH
gitpod workspace create https://github.com/gitpod-io/empty --ssh
Tip: Use
--editor
to override your default editor selection. Usegitpod workspace list-editors
to see a list of possible editor options.
Managing workspaces
There’s a lot more you can do with the Gitpod CLI including listing and deleting workspaces. We suggest you explore the CLI using the help pages. Start by typing gitpod
to start exploring.
See Gitpod CLI for more.
Frequently Asked Questions
Can the CLI be used in automation? Yes. You can install and use the Gitpod CLI in CI pipelines, bash scripts or other automation by logging in via access token based authentication.
Does this mean Gitpod now has two CLIs? Gitpod will continue to support the gp
CLI within Gitpod workspaces alongside this new Gitpod CLI. The gp
CLI will now be referred to as the “workspace CLI”. We intend to merge these two CLIs in future, but not today.
How does this new Gitpod CLI relate to the existing ‘Local Companion’? The Local Companion tool will now no longer be supported by Gitpod. Since we originally announced the Local Companion, we have since introduced other features which allow you to achieve similar behaviors previously offered by the Local Companion. See the Local Companion documentation for more.
Is the CLI compatible with all Gitpod IDEs and editors? Yes. The CLI allows you to open workspaces directly through SSH, the Browser Terminal, VS Code Desktop and Browser, or with any of the JetBrains IDEs.
You can now specify the exact SCM hosts in your Gitpod browser extension settings
We recently updated the browser extension to allow self-hosted source control management (SCM) like Bitbucket and GitLab. We implemented this change by updating the browser extension to run on all hosts, which caused concern for some of our users. We heard your feedback, and have now updated the extension so that you can customize the hosts where the Gitpod browser extension should run. The latest browser extension version enables (by default) the following hosts: github.com
, gitlab.com
and bitbucket.org
. You can now also to opt-in to enable additional hosts, such as a self-hosted SCM. Here’s what you need to know:
- Users who already have the extension installed - Any previously allowed hosts will persist, including those who allowed all websites. You can now update the opt-in hosts in your browser extension settings.
- Users who do not have the extension installed - Install the extension as normal, and opt-in to enable any relevant SCM hosts, if self-hosted support is required.
For more, see the browser extension documentation.
Local Companion (as an SSH connection method) for VS Code Desktop is now retired
Over the past few months we have continued to introduce more stable and reliable methods of connecting to workspaces via SSH. The previously supported method of establishing an SSH connection using the Local Companion app is now retired. No action is required by users, VS Code will automatically switch to the new connection method. For troubleshooting, consult our guide.
Please ensure that your Gitpod VS Code Extension, Remote SSH extension and VS Code is up-to-date. You can learn more about these connection methods in connecting to VS Code Desktop.
Please note: This deprecation does not apply to the Local Companion App.
Blazing fast workspace starts are now easier than ever, with simplified default settings for prebuilds
Enabling prebuilds to increase the performance of workspace starts should be simple. With prebuilds enabled you unlock more of the developer velocity potential of Cloud Development Environments for your organization.
To make prebuilds simpler and easier to use, we’ve drastically simplified the default prebuild settings. We’ve removed the previous settings for “incremental prebuilds”, “use last successful prebuild” and “cancel prebuild on outdated commits” and instead created a set of simpler and more intuitive defaults that just work™.
If you do need more advanced fine-tuning of your prebuild settings, you can also now filter when your prebuilds are triggered across all of your git providers (GitHub, GitLab and Bitbucket) through project settings.
Simplified default prebuild settings
The previous prebuild settings for “incremental prebuilds”, “use last successful prebuild” and “cancel prebuild on outdated commits” have now been removed and simplified. By default, all prebuilds:
- Skip
20
commits by default (if no previous setting was applied) - Search the past 100 commits for a successful prebuild to base a workspace on
- No longer prevent users from accessing workspaces if a prebuild is executing
These settings should work well for most projects out-of-the-box, without the need to apply additional filters. By increasing the Commit Interval you can balance freshness of prebuilds against the frequency of their execution.
Note: These setting defaults apply to all new and existing projects automatically.
Branch filters for prebuilds on project settings
The improved prebuild defaults should work well for most projects. However, if your project requires more fine-tuning of when prebuilds are triggered, the following prebuild settings are now available for all git integrations:
- All branches (the default setting)
- Default branch only (e.g. main)
- Only the branches specified (via glob pattern)
Previously only the GitHub integration could filter prebuilds—configured through the .gitpod.yml
. All other providers, e.g. (GitLab and Bitbucket) ran prebuilds on every commit push, with limited control.
Prebuild settings in the
.gitpod.yml
are deprecated. All existing.gitpod.yml
settings will apply until prebuilds are manually enabled in project settings.
See configuring Prebuilds via .gitpod.yml for archived documentation.
The way init
tasks work is changing, here’s what you need to know:
When you open a workspace and Gitpod finds an existing prebuild for an older commit, Gitpod will start the workspace and then run the init
steps from the .gitpod.yml
again on top of the existing prebuild. Gitpod will only use prebuilds that have an identical .gitpod.yml
as your current commit. This new behavior works best for you when your init
steps:
- Can be executed repeatedly, while always producing the same end-state in the file system for a given reposiotry state.
- Execute quickly when executed the second time (e.g. process changes incrementally).
For more, see Repositories and Prebuilds.
Start workspaces faster with the Gitpod Browser Extension v2
The Gitpod browser extension has now been updated with the following changes:
- Start new workspaces faster - To save time, the default browser extension action will open your workspaces using either your preferences for the repository, or your user settings. To override this behavior and choose your settings manually, you can use the “Open with options…” secondary option on the Gitpod button.
- Support for Self-Hosted Bitbucket and GitLab - The browser extension is now compatible with both Bitbucket Datacenter and GitLab Self-hosted installations. No special steps are required: with the extension installed navigate to your Bitbucket or GitLab instance to see the Gitpod button appear within the interface.
Getting Started:
- Update or install the extension - If you do not have the extension already installed, you can download it from the Chrome Web Store or the Firefox Add-ons page. If you have already had the extension installed your browser will automatically update it.
- Update the host setting (optional) - For Gitpod Dedicated customers you can update your extension host setting by clicking the Gitpod icon in your browser bar and adding your Dedicated installation URL e.g.
your-company.gitpod.cloud
.
Important: If you already had the browser extension installed, you may have to re-enable the extension and accept new permissions. Why? We removed host name restrictions to allow for self-hosted SCM support.
For more, see the browser extension documentation.
Set a default Workspace Image for your Gitpod Organization
With Gitpod you can now set a workspace image across your Organization. Previously, Gitpod would use the default workspace-full
image when starting new workspace where there was no image
setting added in the .gitpod.yml
. Setting the default image is useful when you want to create a default workspace experience out-of-the-box for users in your Gitpod Organization without needing to create a .gitpod.yml
in every repository.
Please note:
- The Organization workspace image setting is only a default and the workspace image can still be overwritten at the repository level by adding a workspace image reference into the repositories
.gitpod.yml
file. - Authentication for the images is based on what the Gitpod installation can access. For Gitpod Cloud users, only public images are currently supported. For Gitpod Dedicated, the authentication is inherited from the installation. For instance, if you are using ECR private registry support that will work with the Organization setting.
- Only Organization owners can update the setting. All Organization members can view the setting.
Getting started
- Ensure you are the Owner of the relevant Gitpod Organization (see Members).
- Navigate to the Organization settings page.
- Navigate to the “Workspace Image” section to update the workspace image reference.
- To test, start a new workspace based on a repository without a workspace image.
See Workspace Image for more.
Gitpod Dedicated expands regional availability
Gitpod Dedicated now supports three additional AWS regions.
New AWS Regions:
- eu-west-2 (London)
- eu-west-3 (Paris)
- sa-east-1 (Sao Paulo)
Comprehensive list of currently supported regions
Why It Matters:
These added regions allow for instances to be positioned closer to users, resulting in reduced latency. Additionally, this update allows a broader range of companies to meet data residency requirements that mandate instances and data to be situated in specific regions.
Get started: Interested in leveraging Gitpod Dedicated or looking to have Gitpod in a region not listed here? Contact our Sales team to discuss your options.
Instead of trying to quit vim, just close the tab
With Gitpod you now have a new editor option for your workspaces: a terminal in the browser.
The terminal in the browser is good for full-time coding with Vim or Emacs, or simply making quick edits. A minimalistic, flexible experience to enhance your productivity using the tools that work best for you.
Customise the browser terminal with your own dotfiles or connect via SSH for added flexibility.
Getting started
- Select the terminal as the editor when you start a workspace (try gitpod.new for a blank workspace)
- You can also Set the browser terminal as your default editor in your user preferences.
See Browser Terminal for more.
Secretless Authorization (Using OIDC)
With Gitpod you can use OIDC to connect Gitpod workspaces to cloud providers or third parties such as AWS, Azure, GCP, or secret management services like Vault. Using OIDC integration eliminates the need to manually distribute access credentials, secrets, and other key material via other methods such as environment variables.
Use gp idp token
in any workspace (works in .gitpod.yml
and with prebuilds) to retrieve the workspace JWT token for exchange with the OIDC supporting 3rd party.
Getting started
The following shows how you can connect AWS to a Gitpod Cloud workspace. Steps can vary based on the 3rd party you are integrating and the domain of your Gitpod installation, see the documentation below for details.
- Setup Gitpod as an AWS Identity Provider (Using
https://api.gitpod.io/idp
as the Audience). - Create an AWS role with permissions to perform
sts:AssumeRoleWithWebIdentity
. - Update your
.gitpod.yml
to exchange your workspace JWT token for an access token.
gp idp login aws --role-arn <your-iam-role-arn>
aws secretsmanager get-secret-value --secret-id database_connection_string
See Workspace OIDC and the AWS Integration Guide for more.
Workspaces forward ports using the HTTPS protocol
In Gitpod, you can now expose ports from your workspace running with HTTPS.
Previously, HTTPS ports exposed in a workspace would show a “port not found” page when accessed. You can configure the port protocol either in your gitpod.yml or via the Gitpod CLI.
Configuring a port protocol in .gitpod.yml
To ensure a port is always configured with a specific protocol you can update the ports
definition block in .gitpod.yml
as below. Updating your .gitpod.yml
is the preferred approach to using the gp
CLI (see below), as the .gitpod.yml
is declarative and ensures workspaces are created repeatably.
ports:
- name: Frontend Application
port: 3000
protocol: https
Dynamically updating port protocols with gp
You can dynamically change the protocol of a port using the gp ports protocol
command.
For example, gp ports protocol 3000:https
will change port 3000
to use https
.
Or, gp ports protocol 3000:http
will change port 3000
to use http
. By default, ports are set as HTTP.
See configuring ports, Gitpod CLI gitpod.yml for more.
New Workspace Creation Page ✨
We’ve enabled the ability to select the organization, editor, and workspace class used when opening a workspace. Giving you the ability to:
- Select which organization will be billed.
- Change editor and scale resources per workspace.
- Be certain about how many credits per hour will be consumed.
We look forward to hearing your feedback! github.com/gitpod-io/gitpod/issues/17215
Validate your .gitpod.yml without committing ! 🤘
TL;DR; - You can now validate a Gitpod configuration—both the .gitpod.yml
and the workspace image—by running gp validate
without needing to restart, leave your workspace, or commit your configuration.
- With
gp validate
can now validate a configuration within the workspace without committing. This works in a very similar way to a regular Gitpod workspace start, allowing you to catch configuration mistakes earlier. - Using
gp validate --prebuild
you can create run a workspace just as a Prebuild would, which makes it easier to debug a Prebuild configuration by re-creating the exact state inside a running workspace.
The power of a CDE comes with a well-defined configuration. Because, when your workspace is configured, you can make use of ephemeral workspaces, multi-track development and other benefits of developing in the cloud.
To update a configuration, you would commit your .gitpod.yml
and start a new workspace. This process would delay the time to finding out a configuration was incorrect, and in the mean time pollute your source control with commits like: ”updates”, ”next”, ”please work!”, ”please work this time” — yeah, we know how it feels!
Which is why we are “shifting left” and bringing errors, validation and suggestions closer to when you are actually developing on and iterating on your configuration. The new Gitpod command gp validate
allows you to do exactly this: validate your configuration changes without committing, or leaving your workspace!
gp validate
is included in every workspace. It works by creating a “workspace within your workspace” using Docker. The command mounts your /workspace
directory, and pulls through all necessary information such as environment variables. By building a workspace within your existing workspace, we can heavily cache changes as Docker layers, making the update cycle to your configuration ⚡️ super, super fast ⚡️.
For more, see configuring workspaces.
FAQs
Does gp validate
apply it’s changes to the currently opened workspace?
The gp validate
command creates a workspace within your current workspace so you can quickly try our your configuration changes without committing or needing to do a full workspace restart. You do still need to commit and start a new workspace to apply the changes to your current (and future) workspaces. However, committing your configuration should now be more of a formality, as your configuration now be validated.
Does gp validate
apply to all files and configurations in the workspace?
The gp validate
command is compatible with .gitpod.yml
and your workspace base image, whether a Dockerfile in the current workspace, or referencing an image hosted elsewhere. The workspace that gp validate
creates shares the file system with the parent workspace, meaning all files and folders are copied into that workspace. This is especially useful when you install a tool, and want to execute or experiment with that tool immediately.
Workspace Images OS Update and Breaking Changes
On April 3rd, Gitpod will upgrade their workspace images to utilize the latest Long Term Support (LTS) version of Ubuntu, which is Ubuntu 22.04.2
(codenamed “Jammy Jellyfish”). As this is a significant release, there are some breaking changes that you should take into account. In case you encounter any problems with your workspaces as a result of this update, kindly submit an issue in the workspace-images repository.
What should you do
Consider which docker image tag is right for your team and repo(s).
Options to consider:
- Continue using the
latest
tag. New workspace starts after the release will use Jammy. - Test Jammy before it is released using tag
2023-03-24-02-48-18
. - Continue using Focal even after the release using tag
2023-01-16-03-31-28
. Switch to Jammy at your leisure, after you’ve had more time to do testing. - Use a custom base image, and continue using Focal for a longer period of time.
Breaking changes
- All maintained images have been updated from Focal to Jammy [1][2] at hub.docker.com/u/gitpod.
gitpod/workspace-ruby-2
is deprecated and will not be updated; Ruby 2.7 is EOL March 31, 2023.- Upgraded
gitpod/workspace-mongodb
to mongo v6. v5 doesn’t support OpenSSL 3, OpenSSL 3 comes out of the box with Jammy. - Updated
gitpod/workspace-node-lts
from Node 16 to Node 18, and also ingitpod/workspace-full
. - Updated
gitpod/workspace-node
from Node 18 to Node 19. - Installed Python 3.9 in
gitpod/workspace-yugabytedb*
, changing itsbase
ref fromfull
. Refer to its dockerfile for background
Fixes
- Bumped Rust to 1.67.1
- Bumped Ruby patch versions for 3.0, 3.1, 3.2
- Overrode OpenSSL for Ruby 3.0 to support Jammy
- Bump Ruby in
gitpod/workspace-full
from 3.1 to 3.2 - Bump Python in
gitpod/workspace-full
from Python 3.8 to 3.11 - Bump
nvm
version from 0.39.0 to 0.39.3
New features
- Use asdf version manager in
gitpod/workspace-elixir
to more easily manage erlang and elixir versions
FAQs
Is Gitpod still maintaining support for Focal in its images?
No. Please consider the above options to handle the update.
What else should I consider as part of the upgrade?
The GNU C Library (glibc) varies between Focal and Jammy.
OpenSSL varies between Focal and Jammy.
Both led to some of the breaking changes (above). Therefore, this may impact you and your team, depending on your related workloads.
Organizational Policy For Workspace Sharing 🔒
To give you more control over who has access to your development environments with Gitpod, Organization Owners can now restrict workspace sharing for workspaces created within their Organization using an Organizational Policy. Disabling workspace sharing prevents any user running a workspace in that organization from sharing their workspace with others.
To disable workspace sharing in your organization, go to settings.
For more information see:
FAQs
What happens to previously shared workspaces?
Workspaces can stop sharing at any time, regardless of policy set. Access for workspaces shared before the policy is set will remain until workspace sharing is stopped for that specific workspace.
Does this always prevent the repository from being shared in a workspace?
Restricting workspace sharing only applies to workspaces that belong to the Organization that has the policy applied. Workspaces created in other organizations inherit policies related to that Organization.
Introducing Flexible Timeouts 🥳 !
You can now set your workspace timeout up to 24 hours using the command line, direct in your favorite editor or IDE or configure a global default! Setting a configurable timeout is useful if you’re working on a long running task, need to leave your workspace open for a while and then revisit it, or whilst collaborating or sharing previews with others.
To try out this feature, type: gp timeout set 1h
to set the timeout for the currently running workspace to 1 hour. Or, go to your user preferences to set the default value for all future timeouts.
FAQs
Does this work for free users?
Only users on paid plan can set custom timeouts.
Can timeout defaults be restricted by an organisation owner or administrator?
Not currently.
January Changelog
Welcome to the January 2023 edition of the Gitpod Changelog!
Key Highlights
- Introducing Gitpod Enterprise
- Prebuild Workspace Class
- Workspace Images OS and Node versions update
- Start new workspace with more options
- Improvements to reliability
- RSS Feed for Gitpod Blog
Introducing Gitpod Enterprise
Gitpod Enterprise is our new enterprise cloud product - a secure installation of Gitpod managed by us for you. Gitpod exists to remove friction from the developer experience, and the best way to do that is with a managed product in the cloud. We no longer actively support self hosting Gitpod.
To read more, see Introducing Gitpod Enterprise
Prebuild Workspace Class
Prebuilds do a lot of work downloading dependencies, building projects, and getting everything ready so you are Always ready to code. Prebuilds often need more resources and power than the average workspace. Now you can configure different workspace classes for your project prebuilds. Check out your project settings for more details.
Workspace Images OS and Node versions update
On February 28th, Gitpod workspace images will be upgraded to use Ubuntu 22.04.1 LTS (Jammy Jellyfish). Additionally, gitpod/workspace-node
and gitpod/workspace-node-lts
workspace images will be upgraded to use Node 19.0.0 and Node 18.13.0, respectively.
If you’d like to continue using the current OS and Node versions, you may pin the workspace image version by changing the tag from latest
to 2023-01-16-03-31-28
(e.g. gitpod/workspace-node-lts:2023-01-16-03-31-28
) in your .gitpod.yml
or Dockerfile
.
Start new workspace with more options
Now you can start a new workspace with more options. You can choose the IDE, the workspace class, and any context url. 🎉
Improvements to reliability
Reliability improvements tend to go unnoticed. No news is good news. But we want to change that.
After countless improvements during the last months, our systems’ reliability show significant improvements according to both our internal metrics and direct customer feedback. 😎
RSS Feed for Gitpod Blog
We now have an RSS feed for the Gitpod blog. You can subscribe to it here: https://www.gitpod.io/blog/rss.xml. So you can now follow the latest news from the Gitpod blog in your favorite RSS reader. 📄😎
Fixes and improvements
Dashboard
- #16050 - Teams are now called organizations
- #15586 - Fix image build logs not showing in the dashboard if the build is delayed.
- #15567 - Support start-with-options URL, for prompting users about the preferred IDE and workspace class when opening a fresh workspace.
- #15288 - Allow setting workspace class for prebuilds
- #15139 - Add versions of all the supported IDEs to the Preferences page
JetBrains
- #15971 - Added support to JetBrains Gateway v2023.1
- #15527 - Fixed an issue which caused Gitpod Terminals to be terminated when closing JetBrains Client.
- #15270 - Update JetBrains IDE images to most recent stable version.
- #15240 - Update Stable JetBrains IDE images to 2022.3
Gitpod CLI
- #15815 - A new CLI command
gp timeout set
allows to set the workspace timeout to arbitrary durations. - #15638 - New command:
gp rebuild
Workspace
- #15553 - Fixed an issue where oom scores for workspace processes were not applied correctly
- #15475 - No failures even if a large number of workspaces are launched at once
- #15216 - Fix issue that prevented a few stopped workspaces from being restarted
- #15262 - Fix bug where workspaces sporadically landed on an unhealthy node
- #14071 - Don’t trigger heartbeat on all ssh connections. Only for pty sessions.
- #14498 - The processes in the workspace are given up to 3 minutes after receiving SIGTERM.
- #15053, #15262 - Fix bug where workspaces sporadically landed on an unhealthy node
Workspace Images
- #1006 - Python 3.7, 3.8, 3.9, 3.10 using their latest releases
- #1005 - Add ruby-3.2 image update ruby-3 image from 3.1.2 to 3.2.0
- #1003 - Create image for python 3.11
Documentation
- #3145 - Document Incremental Prebuilds and Incremental Workspaces
Fixes and improvements
- #16070 - Removed org slugs
- #15854 - Improvements and bug fixes to the Projects list page on the dashboard. Sorting of projects on that view is now alphanumeric instead of by activity.
- #15728 - New
.gitpod.yml
default template - #15754 - Allow renaming teams
- #15724 - Add new
gp docs
command to the gitpod cli - #15648 - Menu Options for Usage, Feedback & Help in Gitpod’s JetBrains Gateway Plugin
- #15503 - Customised example repositories on the basis of selected IDE options
- #15371 - Update beta notice for the JetBrains integration
- #15367 - Replace prebuild message emoji
- #15364 - Replace prebuild duration message emoji
- #15350 - Show team usage tab only to team owners
- #15316 - Projects can now be deleted from the corresponding Settings page for that project.
- #15253 - Expired Personal Access Tokens exclamation indicator now has a tooltip w/ the full expiration date so you can see exactly when it expired.
- #15247 - Remove beta and early access labels for Teams, Projects, and Billing
- #15255 - Quote Gitpod prices as excluding VAT.
- #15084 - Fixes an issue with modals not displaying properly on smaller screens.
- #15092 - Disable upgrades of fixed-price monthly plans for individuals and teams who have pay-as-you-go enabled
- #15147 - Always allow running new prebuilds, regardless of any previous prebuild state
- #15107 - Update spacing in token regeneration modal
- #15025 - Replace “usage-based” with “pay-as-you-go” in user and team billing pages.
- #15026 - Disable running prebuilds without a project + disable the deprecated ‘#prebuild/’ URL prefix
- #3314 - Gitpod Teams are Gitpod Organization now
- #3306 - RSS Feed for Gitpod Blogs
- #3302 - Add November community highlights to our website
- #3287 - Add December community highlights to our website
- #3081 - Add documentation for personal access tokens
November Gitpod Release 2022
Welcome to the November 2022 edition of the Gitpod Changelog!
Key highlights
- Prebuilds require a project
- CLion and Rider are now out in beta! 🎉
- Configure JetBrains IDE Settings across workspaces
- Reliable VS Code extensions: Gitpod now hosting an Open VSX Mirror!
- Manage workspace ports without needing to leave your JetBrains UI
- Reduced IDE startup time & Custom Shells [Breaking Change]
Prebuilds require a project
In the past, it was possible to trigger prebuilds by prefixing the repository URL with gitpod.io/#prebuild/
. This mechanism has been turned off, because projects provide much better visibility into your prebuilds.
Use the following steps to enable prebuilds on your repository:
- Create a repository for the repository.
- Define the prebuild steps in an
init
task in your gitpod.yml.
Since prebuilds are included in all our metered pay-as-you-go plans, configuring prebuild settings in your project should help with managing prebuild usage.
CLion and Rider are now out in beta! 🎉
- First we announced IntelliJ IDEA, PyCharm, GoLand, and PhpStorm
- Then it was the turn of RubyMine and WebStorm
Today—as part of our official partnership with JetBrains—we “complete the set” of JetBrains IDEs that integrate with Gitpod via JetBrains Gateway. Gitpod now has first-class IDE integration support for both Rider and CLion! 🤘
Getting started with CLion or Rider:
- Install JetBrains Gateway - With the JetBrains Gateway and Gitpod plugin you can create and manage your latest 20 Gitpod workspaces.
- Install the Gitpod plugin - Open JetBrains Gateway and you’ll see the Gitpod logo on the main page. Click “install” to install the Gitpod plugin for JetBrains Gateway.
- Update your Gitpod preferences - Select CLion or Rider on the Gitpod preferences page which will set the IDE as your default for future workspace starts.
- Start (or restart) your workspace - Either start a workspace directly from within JetBrains Gateway via the Gitpod plugin OR open a new workspace directly in Gitpod where on workspace start you will be prompted to open CLion or Rider for that workspace.
Configure JetBrains IDE Settings across workspaces
You can now configure your IDE settings at the project and user level. At the Project level, you can use your Workspace Image or commit settings to Git. At the user level, you can now configure settings by leveraging Dotfiles.
A common question we get from Gitpod users is ”how can I configure JetBrains IDE settings so that they’re saved across workspaces”. Without some way to sync IDE settings, you are missing out on fully embracing the power of Gitpod, ephemeral workspaces and cloud development environments.
For an example, see IntelliJ IDEA for how to configure IDE settings.
See your favorite JetBrains IDE page for more.
Reliable VS Code extensions: Gitpod now hosting an Open VSX Mirror!
Gitpod uses the Open VSX registry both for VS Code Extensions when using the VS Code in the browser integration, and when combined with Gitpod VS Code Settings Sync. In the unfortunate case that the main Open VSX registry was unavailable or unresponsive, regrettably Gitpod users could be exposed to downtime and see extensions failing to load in Gitpod workspaces. Whilst Gitpod has caching in place for Open VSX extensions, some extensions could still fail to fetch, causing disruption. To mitigate the issue, Gitpod is now running a full mirror of Open VSX, fully operated by Gitpod, allowing us to drastically improve the availability of Open VSX delivered extensions. 🎉
Nothing should prevent you from being “Ready To Code” with Gitpod.
Manage workspace ports without needing to leave your JetBrains UI
You can now view ports both in your JetBrains terminal, and in the JetBrains backend control center.
- From the backend control center - In addition to performing many Gitpod actions from the JetBrains backend performance center you can now also view and manage your ports. See which ports are being forwarded or exposed. You can also add, remove and open URLs for your workspace ports without leaving the JetBrains UI.
- From within the terminals view - You can now also see, and manage your ports from the terminal view direct in the JetBrains IDE, allowing you to manage any ports related to the current running terminal process all without leaving the terminal window in your IDE.
Running your IDE on your desktop means that all your ports are automatically forwarded, so you can use your localhost
URL as usual. You can also manage ports from any IDE or Gitpod interface using the Gitpod CLI. For example, try running gp ports list
in any workspace to see a list of your workspaces running ports.
Reduced IDE startup time & Custom Shells [Breaking Change]
If you don’t use custom shells such as zsh
or fish
, you just need to know that we made some changes to speed up the IDE startup time! 🎉
If you use a custom shell, and you rely on bash profile to configure your workspace, continue reading..
In an effort to speed-up the IDE startup time, we made some changes to how we launch IDEs inside workspaces. Previously, we would automatically source interactive login bash shell’s profile, but it was a side-effect of our method of launching the IDE. We now changed this behaviur and Gitpod uses the shell configured by the user via the SHELL
env var. If you use a custom shell but you’re relying on configurations specified in bash profile, you might need to update your configuration, check out Configure a custom shell for examples.
If you have feedback about using custom shells within Gitpod, we’d love t hear it, leave your thoughts in #10105.
Fixes and improvements
Dashboard
- #14763 - Fix ‘Go to Dashboard’ buttons on StartWorkspace
- #14515 - Usage view allows for arbitrary date ranges
- #14535 - Workspace classes can be set in the project settings
- #14557 - Fix rollout behavior of Usage-Based Pricing
- #14461 - New project setting to start workspaces based on the last successful prebuild.
Prebuilds
- #15026 - Disable prebuilds without a project and disable the ‘#prebuild/’ URL prefix
JetBrains
- #14916 - JetBrains: Start JB backend with the interactive login shell.
- #14886 - Update JetBrains IDE images to most recent stable version.
- #14817 - Update JetBrains IDE images to most recent stable version.
- #14524 - JetBrains: Add Rider and CLion IDEs in Beta
- #14787 - Update JetBrains IDE images to most recent stable version.
- #14656 - Fixed an issue preventing opening prebuilt Maven projects properly
- #14566 - Preconfigured global settings on Host.
- #14356 - In JetBrains EAP IDEs, users now have the option to copy the URL from the terminal’s ports context menu.
Gitpod CLI
- #14630 - Display helper for unknown subcommands
Workspace
- #14259 - Fix errors associated with running docker-compose with lots of containers
- #14067 - Disable git checkout hooks when starting a workspace
- #14111 - Improved IDE startup time
Fixes and improvements
- #15025 - Replace “usage-based” with “pay-as-you-go” in user and team billing pages.
- #15016 - Update new team page layout
- #15017 - Update beta label on teams, projects, and usage
- #14937 - Update access tokens menu order
- #14853 - Truncate branch name on prebuilds page
- #14827 - Update usage period date format
- #14828 - Revert removing the workspace download feature
- #14761 - Show not-served ports in gp-cli
ports
command, browser Ports view and desktop ExposedPorts view - #14720 - Update workspace download menu style
- #14650 - Don’t swallow supervisor exit error
- #14421 - Gitlab webhooks: play nice, don’t respond with code 401.
- #12805 - Display the team names which block upgrade to the UBP free tier
November Self-Hosted Release
We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it in our documentation. More details on this release can be found on GitHub.
If you are on a paid Self-Hosted plan, this release will be promoted to your release channel in one week.
For feedback, please raise an issue or chat with us.
Fixes and improvements
A full list of changes can be found in the release notes on GitHub.
October Gitpod Release 2022
Welcome to the October 2022 edition of the Gitpod Changelog!
Key highlights
- Even more power! ⚡ Try large workspaces with pay-as-you-go 🎉
- Start workspaces based on existing prebuilds ⚡️
- RubyMine and Webstorm IDEs now in beta 🚀
- New “exposed ports” view in VS Code Desktop 🔌
- Ports sorting now based on your gitpod.yml definition ⏬
- Easily find information about your workspace with
gp info
ℹ️ - VS Code ports view is now responsive ⏩
- Projects now only created under teams, not personal accounts ⚠️
- Using private workspace images (Alpha) 🔐
Even more power! ⚡ Try large workspaces with pay-as-you-go 🎉
Important: Prices and terms are subject to change.
With pay-as-you-go you get early access to workspace classes, allowing you to customize your workspace resources. To get access to pay-as-you-go either for teams or individual users, please contact us.
How does pay-as-you-go work?
- Gitpod usage is measured in credits, based on how long your workspaces run, and the resources consumed by different workspace classes. Metered usage also includes prebuilds.
- Individual users receive 500 free credits per month on the free plan, these credits are equivalent to 50 Standard workspace hours or 25 Large workspace hours.
- For users who upgrade to the personal paid plan at €/$ 9.00 per month, workspace usage allowance increases to 1000 credits.
- The standard pay-as-you-go rate for paid users, and for teams, is €/$ 0.036 per credit.
- Existing paid plans need to be cancelled for pay-as-you-go billing to work.
I want early access!
Start workspaces based on existing prebuilds ⚡️
Start a new workspace based on an existing prebuild
You can now start workspaces using existing prebuilds. This helps when you have a repo with many commits, so you’re not left waiting for the latest prebuild to finish. To get started, select a prebuild from your project prebuild list, and click ”New Workspace (with this prebuild)”
JetBrains RubyMine and WebStorm IDEs now in beta 🚀
We are continuing to expand support for JetBrains IDEs as part of our official partnership with JetBrains.
See the RubyMine & WebStorm announcement for more.
New “exposed ports” view in VS Code Desktop 🔌
To give you all the power of Gitpod, we’ve added a new tab, EXPOSED PORTS, which gives you additional functionality in addition to the regular ports view of Remote - SSH, like port visibility (public/private).
Due to constraints with Remote - SSH extension, we cannot extend the default VS Code ports view.
Ports sorting now based on your gitpod.yml definition ⏬
Ports shown in all Gitpod clients are now ordered based on:
- The order of the ports definition in the
.gitpod.yml
- All other ports are numerically sorted in ascending order.
This change applies to all of VS Code, JetBrains IDEs, SSH and the Gitpod CLI.
Example output of gp ports list
:
| PORT | STATUS | URL | NAME & DESCRIPTION |
| ----- | -------------- | ------------------------------ | ------------------ |
| 3000 | open (public) | https://3000-repo...gitpod.io | Web Server Preview |
| 5900 | open (private) | https://5900-repo...gitpod.io | Postgres Database |
| 5555 | open (private) | https://5555-repo...gitpod.io | |
| 36341 | open (private) | https://36341-repo...gitpod.io | |
See ports documentation for more.
Easily find information about your workspace with gp info
ℹ️
You can now display information about the current workspace (such as the workspace ID and URL) and also the workspace class, using the new command from Gitpod CLI called gp info
.
Example output:
Workspace ID : gitpodio-gitpod-4q1200dvfcf
Instance ID : 8a6188a3-4c7f-49fe-aa4d-db968c11e183
Workspace class : Large: Up to 8 vCPU, 16GB memory, 50GB disk
Workspace URL : https://gitpodio-gitpod-4q1200dvfcf.ws-eu67.gitpod.io
Cluster host : ws-eu67.gitpod.io
See the Gitpod CLI reference page for more.
Default environment variables will soon be deprecated, please update all scripts to use
gp info --json
.
VS Code ports view is now responsive ⏩
The ports view in VS Code is now responsive depending on the ports view width. The view defaults to the bottom VS Code navigation bar, however, the ports view can be drag-and-dropped to the sidebar if you prefer. You can access all port actions as normal on all views. In larger views, more information about your ports is shown.
For feedback let us know on the ports experience GitHub issue.
Projects now only created under teams, not personal accounts ⚠️
- You can no longer create Gitpod Projects under personal accounts.
- All projects must now be created as part of a team.
- Existing personal projects will continue to work.
Using private workspace images is now in alpha
Did you know that you can use a private Docker image with Gitpod? Private Docker image support for workspace images has been possible for some time, however it was an undocumented feature. We’ve now updated our documentation so that you can more easily give try out the feature. As the feature is currently alpha, please raise an issue for any feedback.
Fixes and improvements
Dashboard
- #14054 - Update usage-based billing balance used progress indicator height
- #14056 - Port 3000 not showing if no
.gitpod.yml
in project - #13744 - Prevent removing the owners of a team if the team size is 1 (or less)
- #13621 - Fix rendering Personal/Team billing menu entries
- #13414 - Deprecation of the ability to create projects under an individual account for new users.
- #13538 - Update “Open Source” plan name to “Free” plan
Docs
- #2683 - Add Azure single-cluster guide
- #2919 - Add an example for installing docker in a custom workspace image
- #2908 - Instruct users to ensure they have Tailscale 1.32 or later
- #2886 - New section on configuring a custom Dockerfile with non-gitpod base image
Gitpod CLI
- #14040 - Bugfix: avoid failure on
ports list
when port is not exposed - #13788 - Display sorted ports with both
gp-cli
and VS Code BrowserPortsView
- #13607 -
gp top
table output updated to matchgp info
JetBrains
- #13990 - Update JetBrains Backend Plugin to work with EAP IDEs v223.7126
- #14182 - Fix ‘gp open’ command to open files in JetBrains Client instead of the backend IDE
- #13966 - Fixed the “Learn More” button behavior from JetBrains Gateway home screen.
- #13836 - Update GoLand IDE image to version 222.4345.24.
- #13747 - Fixed auto-port-forwarding on JetBrains EAP IDEs
- #13797 - Update PyCharm IDE image to version 222.4345.23.
- #13758 - Update RubyMine IDE image to version 222.4345.14.
- #13757 - Update WebStorm IDE image to version 222.4345.14.
- #13759 - Update PhpStorm IDE image to version 222.4345.15.
- #13642 - Update IntelliJ IDEA IDE image to version 222.4345.14.
VS Code
VS Code Browser
- #13838 - Make the VS Code PORTS view responsive
- #14102 - Fixes default location of the Ports view
- #13844 - Fix the PORTS view address opening twice in some browsers
VS Code Desktop
- #26 - Add
Install Local Extensions
command to explicitly install local extensions. On connection try to install local extensions but quietly without notifications.
Workspace
- #13495 - All running processes receive a SIGTERM when a workspace shuts down.
- #13268 - Show an error if the workspace’s persistent volume is smaller than the restore volume snapshot
Workspace Images
- #956 - Use tailscale 1.32 or later and avoid DNS issues
- #953 - Update
brew
layer to get recent versions of all available homebrew packages
Fixes and improvements
- #14238 - Deactivate team scope selector on personal usage
- #14081 - Show warning for inactive projects and allow to resume prebuilds again.
- #13831 - Reliably close Workspaces which fail to start for whatever reason
- #13801 - Implement a ‘Use Last Successful Prebuild’ workspace creation mode
- #13664 - Enable the protected secrets by default
- #13768 - Add support for opening specific prebuilds
- #13822 - Support multi-line environment variables in SSH
- #13745 - Fix branch context for Bitbucket Server
- #2975 - Moves this release back to 2022-10-27
- #2959 - Add October 2022 self-hosted release note
- #2951 - Documented private Docker registries support
- #2966 - Fixes typo and capitalization in SCM names
October Self-Hosted Release
We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it in our documentation. More details on this release can be found on GitHub.
If you are on a paid Self-Hosted plan, this release will be promoted to your release channel in one week.
For feedback, please raise an issue or chat with us.
Fixes and improvements
A full list of changes can be found in the release notes on GitHub.
September Self-Hosted Release
We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it in our documentation. More details on this release can be found on GitHub.
If you are on a paid Self-Hosted plan, this release will be promoted to your release channel in one week.
For feedback, please raise an issue or chat with us.
Security
This release includes security fixes addressing information leakage in logs; see the security announcement log for more information.
2022.09.2 hotfix (published on 21.7.2022)
This hotfix includes:
- #13934 Fix for an issue where secrets could end up in logs because the installer was logging the env var object. For more information, see the security announcement log
- #13959 This fix adds a checkbox to enable the HTTP proxy settings. Proxy settings were sometimes being incorrectly applied before this. Now, the values are still taken from the KOTS CLI input variables, but will not be applied until the option is configured in the UI.
2022.09.1 hotfix (published on 14.7.2022)
#13821 This hotfix includes a change to fix the regression caused by protected_secrets
(see security announcement log for more information) when working with self-signed certs.
Highlights
Preflight checks on the Gitpod configuration
#12015 We know that some of you are using config patches to configure additional aspects of Gitpod, such as the resources that workspaces use. Up until now, there was no validation on these patches and thus it was difficult to debug if there was an issue with them. This has changed now - there is a preflight check that validates these (and the Gitpod configuration as a whole), and then informs you where to look to find any errors.
Additional safeguards during updates
#13215 During updates, we recommend that you do not have any workspaces running to prevent data loss (see update guide). There is now a preflight check that checks for running workspaces before you deploy and fails if it finds any running ones. If an update is deployed anyways, running workspaces will be stopped for you. Note that users will see their workspaces stopped arbitrarily.
Breaking changes
- Single Cluster Reference Architecture changes:
- Regular workspaces and headless workspaces are isolated to separate node pools to help avoid noisy neighbor issues between the two and guarantee maximum performance for workspaces
- Workspace Services (such as
ws-manager
) are deployed to the services nodepool to prevent potential service degradation from highws-daemon
memory use. - We’ve increased the default node size to 16 core / 64 GB nodes. This is to allow for more workspaces per node, and avoid the scenario where there is just one workspace per node. We’ve also added documentation to detail our recommendations around workspace resources.
Fixes and improvements
#12196 The KOTS installer script is used to generate a config file out of the values inserted into the KOTS UI. We’ve refactored large parts of it to turn it from a bash script into a part of the installer image. This improves reliability and predictability for you and maintainability for us. It also allows us to call this during preflight checks, enabling us to provide the preflight checks for config patches mentioned above.
A full list of changes can be found in the release notes on GitHub.
September Gitpod Release 2022
Welcome to the September edition of the Gitpod Changelog!
Key highlights
- JetBrains Backend Control Center - Gitpod workspace actions
- JetBrains Backend Control Center - Workspace Classes
- JetBrains Reconnect With Open Windows
- New Ports View in VS Code
- SSH Gateway default for Self-Hosted VS Code Desktop Users
- Configurable core dump behavior
- Faster startup times for large repositories
- Fixes and improvements
JetBrains Backend Control Center - Gitpod workspace actions
Caption: The Backend Control Center in JetBrains showing various Gitpod workspace actions
If you’re a Gitpod VS Code user, you know that in the command palette you can do things like:
- Stop your workspace
- Open the Gitpod dashboard
- Open in VS Code Desktop
…and much more.
However, for JetBrains users, there was no way to access these common Gitpod commands without leaving the workspace. Or worse, opening your workspace using VS Code, rather than your preferred JetBrains IDE. It’s important that all the Gitpod editors and IDEs have a first-class experience for our users, no matter their preference, and our Jetbrains IDEs are no exception.
But now, we’ve added all of the Gitpod workspace actions you could do in VS Code into JetBrains.
You can now access these commands through:
- The Backend Control Center in JetBrains
- Or via the JetBrains IDE search menu
That means from within a JetBrains IDE you can directly:
- Open the Gitpod Dashboard
- Open your workspace context
- Open your user settings
- Manage workspace access control
- Go to the Gitpod documentation
- Report an issue on GitHub
- Follow Gitpod on Twitter
- Access our community server on Discord
- Upgrade your Gitpod subscription
- Stop your workspace
- Extend your workspace timeout
- Share your a snapshot of your workspace
All from the comfort of your IDE.
JetBrains Backend Control Center - Workspace Classes
Caption: The Backend Control Center in JetBrains showing workspace class information (e.g. 6 vCPU, 12GB memory)
Did you know that when you’re working with JetBrains IDEs in Gitpod you can monitor the performance of your workspace in real-time via the JetBrains Backend Control Center? This feature is useful when your workspace isn’t performing as you’d expect and you want to gather more information. In addition to our recent additions of Workspace CPU
and Workspace Memory
we’ve now added the actual workspace class to the information shown in the control center.
… but why? When you work in a cloud developer environment, you should have the flexibility to choose the right performance profile for your project. Recently we’ve been working to bring to Gitpod a feature we call “Workspaces Classes” #8261. With Workspaces Classes you’ll be able to select workspace specifications that better match your use case. For example, you will be able to get more powerful workspaces to run larger Java projects and IntelliJ.
So since we needed somewhere to show you this Workspace Class information, you can now find it in the JetBrains performance center.
Tip: You can run
gp top
to see performance info no matter the IDE or editor you’re using.
JetBrains Reconnect With Open Windows
Previously, with JetBrains if you tried to open your workspace twice, the Gitpod JetBrains Gateway plugin would allow you, sometimes leading to odd behaviors or bugs, since JetBrains Gateway is designed to only allow one window to open. Now, when you try to open an already opened window with JetBrains Gateway, you’ll get a prompt to remind you that the workspace is already opened.
New Ports View in VS Code
Caption: The new VS Code Browser ports view, shown at the bottom of VS Code alongside the terminals and output tabs
You might have seen in our last changelog that we mentioned a new ports view being added to VS Code (in the browser). At that time we were rolling out the feature to only subsets of our Gitpod users to see how users responded. However, after some good feedback from you (our users) we have pushed the feature out to all users! 🥳
We introduced the new ports view as we wanted to align our experiences on VS Code Desktop with VS Code Browser. We know lots of users like to use Gitpod in the browser sometimes for “smaller changes” like reviewing pull requests. But for more “deep work” many users opt for VS Code Desktop. However and wherever you choose to code, Gitpod will make that as much a comfortable and familiar experience as you’re used to.
SSH Gateway default for Self-Hosted VS Code Desktop Users
We have previously shared about how we updated the underlying connection method of VS Code Desktop to Gitpod for our new SSH Gateway approach. The feature was first released defaulted off for all users. We have since enabled this SSH access method for all users of gitpod.io, and now we’ve enabled the approach for all VS Code Desktop users of Gitpod everywhere, no matter which installation they’re using.
Configurable core dump behavior
Debugging applications in Gitpod that are written with C++, Rust, or Python just got easier.
We’ve added a new coreDump
configuration property to the .gitpod.yml
file, allowing you to configure your workspace core dump behavior. You can enable/disable core dumps, or set soft and hard limits for them. For information on how to configure this property, check out the core dump property of the .gitpod.yml
Faster startup times for large repositories
Are you working with a large git repository? You want to hear about this.
We have changed how files are fetched from git into Gitpod on workspace start, to make your experience faster. In our testing of the changes, we observed differences from around 2m30s down to 40s. If you’re using large repositories with Gitpod, give it a try and let us know about your experience 🚀
Fixes and improvements
- #13318 - Keep the last selected team selected
- #13402 - [server] Fix for the inability to delete teams that were not subscribed to usage based pricing
- #13438 - Fix missing port in parsed clone URL.
- #13205 - JetBrains: VM options to install plugins
- #12445 - Support for storing VS Code edit sessions in sync server
- #13295 - Avoid second prebuild been triggered on same commit.
- #13296 - Fail prebuild if image build fails.
- #13186 - Restrict reuse of phone numbers for verification
- #13203 - [server]: Add a liveness probe which fails when the nodejs event loop lag exceeds a certain threshold
- #13080 - JetBrains Gateway: Avoid 30 seconds delay when connecting to a workspace using an expired token
- #13161 - Admin dashboard now has pagination
- #13108 - Fix reading .gitpod.yml for self-managed GHE instances.
- #13065 - Added a usage view that displays past workspace sessions on individual and team accounts.
- #13084 - Update GoLand IDE image to version 222.4167.25.
- #13057 - improved automated code configuration service for
go
- #13001 - Update GitLab API library, which fixes paginated API requests.
- #13033 - Update PhpStorm IDE image to version 222.4167.33.
- #13032 - Update PyCharm IDE image to version 222.4167.33.
- #12670 - Dismiss Usage Limit notifications automatically.
- #12994 - Update IntelliJ IDEA IDE image to version 222.4167.29.
- #12412 - Add beta notice and label on usage
- #12852 - Add link to support on phone verification
- #12833 - Improve fetching repositories loading state
- #12771 - Show personal Usage page.
- #12621 - JetBrains IDEs now have actions related to Gitpod, which can be accessed via Control Center and via the Search Menu.
- #12669 - Reword “Spending Limit” to “Usage Limit”
- #12568 - JetBrains: Provide workspace class info in Backend Control Center
- #12232 - Fixed JetBrains connection loop when connecting twice to the same workspace
August Gitpod Release 2022
Welcome to the August edition of the Gitpod Changelog.
Key highlights:
- JetBrains now supports multiple task Terminals
- JetBrains now respects configured Java SDK (JDK) versions
- View Resource Consumption in JetBrains Backend Control Center
- Sync Local VS Code extensions
- VS Code Desktop reduced popups when opening
- All VS Code Desktop users on SaaS are now using SSH Gateway! 🎉
gp tasks list
shows your current tasks (as defined in the .gitpod.yml)gp tasks stop
stops running tasks that (as defined in the .gitpod.yml)- Improved OpenSSH compatibility and support for sha256/sha512
The following features are also accessible for users running the “latest” IDE or editor preference:
- New ports explorer in VS Code Browser - Aligning the port interface with VS Code Desktop.
Improvements for JetBrains IDEs
We are continuing to make progress with the JetBrains and Gitpod integration #7956 as part of our ongoing partnership with JetBrains. Whilst most of our efforts are mostly towards IntelliJ IDEA, a lot of the improvements we are making will still apply to our other supported JetBrains IDEs.
JetBrains now supports multiple task Terminals
A key part of “Gitpodifying” a project is adding any necessary tasks, such as starting servers or database to your .gitpod.yml. One advantage of declaring these processes in your .gitpod.yml
configuration is that your commands are picked up by the IDE or editor and show on workspace start.
Previously, JetBrains with Gitpod only showed a single terminal, meaning that users needed to use gp tasks
to interact with running terminals. Due to some improvements for JetBrains Remote Development that we are able to leverage, you can now see all of your terminals inside the IDE as you also can with VS Code.
JetBrains now respects configured Java SDK (JDK) versions
Previously, when opening a Java Workspace with JetBrains, the Gitpod IDE would select the latest Java SDK (JDK) version as the default.
This was problematic when we recently updated the Gitpod workspace-full
image, to include both Java 11 and 17, which many users rely upon. When having multiple JDK versions, JetBrains would default to using the latest JDK version, which in the case of the workspace-full
image was 17, and not 11, causing a minor regression. Now, Gitpod respects configured JDK versions in locations such as the PATH
and JAVA_HOME
.
JetBrains IDEs now picking up the correct SDK version by default
View Resource Consumption in JetBrains Backend Control Center
When using a Gitpod workspace you might experience performance issues caused by an application using more resources than expected, or due to resource consumption in adjacent containers on the node. Whatever the reason, you may want to investigate what’s going on within your workspace.
We’ve now extended the JetBrains Backend Control Center with two additional bits of information about your workspace: Workspace CPU
and Workspace Memory
. The additional performance information shown in the control center is for the node that your workspace is running on, and not the workspace itself. This information is also the same that can be found from running the command gp top
in your workspace.
Viewing the workspace and node performance in the Backend Control Center
Improvements for VS Code Desktop
We have been continuing to invest in our desktop editor experiences, including VS Code #7184, with an emphasis on removing any barriers or friction in getting the VS Code editor open with a Gitpod workspace, establishing a stable connection via SSH, and improving the experience of restarting a timed out workspace.
Sync Local VS Code extensions
The underlying Microsoft VS Code - Remote SSH extension that powers the Gitpod VS Code Desktop integration does not automatically install local user extensions on remote machines, such as a Gitpod workspace. For users, because VS Code - Remote SSH does not automatically install local extensions, that means you’ll have to manually click “install” for each local extensions on every Gitpod workspace start. Installing extensions manually is cumbersome, especially when you have many extensions to install and is a barrier to utilising Gitpod ephemeral workspaces.
In an upcoming release, Gitpod will prompt you to enable VS Code Setting Sync with Gitpod, which will allow Gitpod to retrieve local extensions and automatically install them in your workspace. If for any reason you want to disable syncing of local extensions, you can do so via the gitpod.remote.syncExtension
VS Code settings. If you have any feedback or thoughts, please add it to the GitHub issue: #7906.
Prompt to enable Setting Sync with Gitpod to sync local VS Code extensions
VS Code Desktop reduced popups when opening
Many users love Gitpod for how simple it can make working with your projects. However, for VS Code Desktop there were some cases where you needed to respond to specific popups when opening your workspace, for instance accepting the SSH fingerprint of the workspace, or accepting the browser redirect when opening a workspace.
The number of prompts you are now shown when opening VS Code Desktop is reduced.
You should see one browser redirect prompt (one for VS Code Desktop and one for JetBrains Gateway), marking “always allow” will suppress all future prompts. SSH fingerprints are also now automatically added to your known_hosts
if you’re using SSH Gateway approach to opening VS Code Desktop.
Using the SSH Gateway approach for VS Code Desktop means no more SSH fingerprint prompts
For more information, check out our dedicated documentation for optimising VS Code Desktop.
All VS Code Desktop users on SaaS are now using SSH Gateway! 🎉
We have now completed a migration of all VS Code Desktop users on SaaS to our new SSH Gateway approach. This change brings improved stability, smoother restarting of workspaces, and more.
To get setup, we recommend you upload an SSH key to Gitpod. For full details on why we made this change to our SSH approach for VS Code Desktop, please check out our blog post VS Code Desktop and SSH explained.
If you cannot use the new approach for any reason, please reach out via the GitHub issue #7452.
Improvements for the Gitpod CLI (gp
)
Over the last few months we’ve been making lots of updates to the Gitpod CLI (gp
). Because the gp
command-line-interface is bundled inside of all Gitpod workspaces, gp
acts as a common way to run workspace actions regardless of what editor or IDE you’re using Gitpod with, whether that’s JetBrains, VS Code or directly via SSH.
Let’s say that you’re documenting your Gitpod setup, rather than detailing actions directly how to take some action in each of the Gitpod supported IDEs & editors, you can share gp
commands knowing that the experience will be consistent across all workspace editing experiences.
gp tasks list
shows your current tasks (as defined in the .gitpod.yml)
The gp tasks list
command allows you to list any running commands that are defined in your .gitpod.yml
. If you want, you can even attach to a given task using gp tasks attach
which brings that current task into the foreground of your terminal. However, since there are situations where it might not be as easy to figure out which terminal you’re currently viewing, that’s why we now highlight your current task to make life a little easier for you
gp tasks stop
stops running tasks that (as defined in the .gitpod.yml)
You can now run gp tasks stop
to stop running tasks that have been defined in your .gitpod.yml
. You can either stop a single task with gp tasks stop <id>
, or terminate all tasks by running gp tasks stop --all
.
See the gp
Command Line Interface documentation for more.
Improvements for SSH connections to Gitpod
The SSH protocol is the primary method of connection to Gitpod workspaces for JetBrains IDEs, VS Code Desktop and users who directly SSH into Gitpod for editing, or working with their code. We’ve been working to ensure that Gitpod has a wide range of support for different SSH clients and SSH key versions.
Improved OpenSSH compatibility and support for sha256/sha512
Previously, Gitpod did not support OpenSSH clients >v8.8, nor did Gitpod support RSA sha256/sha512. For users using VS Code Desktop with the SSH Gateway approach, this could mean that in some cases users could not leverage SSH access to Gitpod due to incompatible keys or OpenSSH client’s, however this issue should now be resolved.
Fixes and improvements
- #12468 - Local Preview: Check and exit if M1 Mac
- #12116 - Gitpod CLI: New command
gp tasks stop
- #11255 - Prevent abuse by limiting rate at which network connections can be made by a workspace
- #12258 - Added phone number verification in SaaS, to help mitigate abuse.
- #12367 - Improve reliability of image build starts
- #12315 - Prevent divide by zero error in workspace info service
- #12288 - SSH-Gateway: Support rsa sha256/sha512 algorithm
- #12096 - Update spending limit modal on workspace start
- #12234 - Truncate project environment variable name
- #12163 - JetBrains IDEs will use the default Java SDK version when there’s no explicit configuration for it yet.
- #12028 - Fixed a rare case in which prebuilds terminated successfully but were shown as failed
- #12280 - Update docker compose from v2.8.0 to v2.10.0
- #12159 - JetBrains: Display Workspace CPU/Memory usage in Backend Control Center.JetBrains: Workspaces created from repositories with tasks defined on .gitpod.yml will start with one terminal opened for each task.
- #12139 - Mark workspaces’ whose image builds failed as `stopped
- #12082 - Enable allowing redirect to Desktop IDEs for all workspaces.
- #12053 - JetBrains: Display Workspace CPU/Memory usage in Backend Control Center
- #12052 - Gitpod CLI: Highlight current task in gp tasks list
- #11993 - Fixes entering of colons in host on Git Integration page.
- #11576 - Add Spending Limit Reached modal on workspace creation.
- #10199 - Migrate AlertBox component instances to Alert component
- #11434 - Local Preview: Provide information about next steps when exited
- #11570 - Fix broken prebuild trigger for GHE.
- #11768 - Display an alert on signup if a user cannot login because their license does not cover for that additional seat
August Self-Hosted Release
We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it from scratch in our documentation. More details on this release can be found on GitHub.
If you are on a paid Self-Hosted plan, this release will be promoted to your release channel in one week.
For feedback, please raise an issue or chat with us.
Feature highlights
Automatic backups
We’ve added the ability to back up your Gitpod application config (no workspace or database data is backed up!) via the KOTS Installation UI under the “snapshots” tab. You can even configure automatically scheduled backups. You can learn more in our backup and restore guide.
Configure additional registry credentials to use (base) workspace images from private registries
You can now use workspace images that are stored in private registries different from the main registry configured for Gitpod in your gitpod.yml and as an installation-wide default. This is useful when, for example, you want to pull private base images from one registry and then store the built images in another. For more information visit the relevant guide.
Breaking changes
- 11954: remove custom labels from the pod selector labels. This removes this limitation so this is a long-term improvement. The impact of this should be handled transparently for you by the KOTS installer.
- 12336: Removal of PodSecurityPolicies. These were deprecated from Kubernetes 1.21 and removed from 1.25. This allows Gitpod to run on Kubernetes 1.25+, which is scheduled for imminent release. If you have PodSecurityPolicies enabled in your cluster, we suggest you disable them as soon as possible.
Please refer to the 2022.08 upgrade guide in the documentation for details.
Fixes and improvements
A full list of changes can be found in the release notes on GitHub.
New ports explorer, changelog view, and connection improvements for VS Code
Users of the latest release could notice that we were working on improvements to VS Code Browser and Desktop. Now they are available in stable release as well via VS Code settings. Key highlights are:
- Connection improvements for VS Code Desktop to bring stability and performance.
- New ports explorer in VS Code Browser to align interface with VS Code Desktop.
- Latest changelog view in VS Code to access the latest changelog directly from VS Code Browser or Desktop.
You can enable
Latest Release
in your preferences and try the latest updates as soon as they are available.
Connection improvements for VS Code Desktop
We developed a new SSH connection mode for VS Code Desktop which brings stability and performance improvements.
This mode can be enabled by setting gitpod.remote.useLocalApp
to false
in VS Code settings and will be enabled by default in future releases.
You can learn more about new the approach in its announcement blog post. If you’re short of time:
- Connection has improved stability, with fewer disconnections
- Approach doesn’t overwrite the
remote.SSH.configFile
- No additional binary downloads required or background processes
- Fewer requests from VS Code to accept the SSH fingerprint
- Improved operating system support via OpenSSH
New ports explorer in VS Code Browser
We developed a new ports explorer in VS Code Browser to align the interface with VS Code Desktop.
You can enable, or disable it via the gitpod.experimental.portsView.enabled
in VS Code settings.
Give the feature a try and we’d love to hear your feedback.
Latest changelog view in VS Code
The new VS Code command Gitpod: Show Release Notes
let you access latest changelog directly from VS Code Browser or Desktop.
Fixes and improvements
gp
has now a newtimeout
namespace letting you to show and extend timeout of a running workspace.- #11642 - [local-preview] Add separated anonymous telemetry
- #11592 - [dashboard] Replace workspace search alert
- #11652 - [dashboard] Fix persistence of checkbox values on settings page
- #11698 - [kots]: put the “run” collectors into the active namespace
- #11630 - [server] fix: new project widget broken if ‘null’ item(s) received from gh api
- #11543 - [server] Send error message on 401 errors
- #10731 - [.gitpod.yml generator] Use ‘pnpm’ package manager when there is a pnpm-lock.yaml file or the package.json specifies it
- #11491 - Check the following in cgroup v1/v2Eliminate dockerd rootless mode in cgroup v2
- #11604 - Update docker compose to v2.7.0
July Self-Hosted Release
We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it from scratch in our documentation. More details on this release can be found on GitHub.
If you are on a paid Self-Hosted plan, this release will be promoted to your release channel in one week.
For feedback, please raise an issue or chat with us.
Feature highlights
Here are the highlights of what is included in this new version of Gitpod Self-Hosted:
- Auto-cancel pending or running prebuilds on the same branch when new commits are pushed
- Upload your public SSH keys to access your workspace
Further, a lot has been improved on the documentation side of Gitpod Self-Hosted, specifically around operating Gitpod:
- How to backup and restore Gitpod
- Business continuity and disaster recovery considerations with Gitpod
- We’ve also restructured the Self-Hosted section in our documentation to have a clearer separation of concerns around the intent of the documentation.
Breaking changes
There are minor breaking changes regarding how you configure workspace resource limits and workspace image defaults. Please refer to the 2022.07 upgrade guide in the documentation for details.
Fixes and improvements
You can now configure the service type of the proxy service in the installation UI - you do not need to upload a
.yaml
file as a config patch anymore to configure this. However, having it in the config patch will still work until December.We’ve improved the time to deploy an update by removing the need to restart the message queue every time we deploy. This has the side benefit of reducing the risk of running workspaces misbehaving during an update. For more information, see the related issue.
A full list of changes can be found in the release notes on GitHub.
Bring your own workspace SSH keys
SSH (secure shell) is a critical protocol for remote development. Both JetBrains IDEs and the VS Code editor use SSH as their remote development foundation. So, a big focus at Gitpod has been on improving performance and usability for connecting using SSH.
Which is why today we’re excited to announce that in Gitpod you can now upload your own public keys to access your workspace. In addition, we’ve also removed the requirement for a mandatory public key to be available when access Gitpod using SSH with an Access Token. With SSH public key upload you can now:
- Re-connect to workspaces without needing to go back to the Gitpod dashboard.
- Benefit from improved security when accessing your workspace with a private key.
See the announcement post for details on the use-cases, benefits and how to get started using your own key pair with Gitpod today.
Roadmap updates
JetBrains - Roadmap issue: #7956 Beta
Fixes and improvements
Gitpod Core
- #11409 - Improve Git Integration validation by testing if host is reachable.
- #11400 - Switch to http/1.1 for gitlab.com repositories
- #11341 - [local-preview] show
DOMAIN
in the output - #11237 - [kots]: add node CPU/memory check tests to workspace node only
- #11253 - Requests on ws-proxy won’t contain the port anymore on the “X-Forwarded-Host” header. It will contain only the host. If you need the port, you can get it from the “X-Forwarded-Port” header.
- #11208 - Users can see their billable sessions.
- #11205 - Minor fixes to the old Team Subscription UI
- #11192 - Make prebuild logs responsive for small viewports
- #11232 - Fix an issue that was causing the workspace to frequently timeout when using a JetBrains IDE.
- #11268 - [installer]: add test for customization of proxy service
Gitpod VS Code Browser
- #379 - Fix
.gitpod.yml
ports.onOpen
not working on workspace startup - #378 - Remove heartbeat in gitpod-remote VS Code plugin
Gitpod VS Code Desktop
Auto-cancel prebuilds on outdated commits
During development, sometimes a number of commits occur within a short period of time, which can trigger and queue multiple prebuilds for the same branch.
Gitpod will now auto-cancel pending or running prebuilds on the same branch when new commits are pushed, efficiently processing the queue and making sure workspaces always use prebuilds with the latest commits.
Auto-cancellation has been enabled by default for all projects, but you can disable this behavior in project settings.
Roadmap updates
JetBrains - Roadmap issue: #7956 Beta
Fixes and improvements
- #11083 - Fix the start-workspace flow for when a prebuild got auto-cancelled
- #11074 - Fix prebuild permissions
- #11072 - Resolve performance degradation issue by changing ws-proxy to not use the target host when serving workspace port route
- #11026 - Improve reliability of log streaming for image builds and prebuilds
- #10836 - Provide endpoint that allows retrieving information about the workspace from within the workspace
- #10696 - Prebuild status is shown under the logs when starting a workspace.
- #10962 - Automatically cancel outdated prebuilds (i.e. new commits are pushed on a branch). This behavior can be disabled in the project’s settings.
- #10952 - Update docker compose to v2.6.1
- #10882, #10727 - Fix prebuilds stuck in
queued
indefinitely
June Self-Hosted Release
We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it from scratch in our documentation. More details on this release can be found in GitHub.
If you are on a paid Self-Hosted plan, this release will be promoted to your release channel in one week.
For feedback, please raise an issue or chat with us.
New way to try out Gitpod: Local Preview (alpha)
You can now try out Gitpod Self-Hosted without having to spin up a Kubernetes cluster - via a simple docker run
command. This will spin up Gitpod locally on your machine and enable you to experience what developing on Gitpod is like. Note that currently, only Linux-based systems are supported (Windows and Mac(Intel) are being worked on) and that unfortunately prebuilds will not work. You can read up on how to get going in the Local Preview Guide. Local preview is still in alpha, so we would appreciate any feedback you may have!
More flexibility regarding registries for airgapped environments
If you are using Gitpod in an airgapped environment you can now specify the container registry you want to use to store workspace images that Gitpod builds for you. By default, it will use an in-cluster registry. Previously, it would always use the same registry that is used during installation to download the images related to Gitpod.
Fixes and improvements
- We have added a
customer_id
field to the telemetry that is sent from a self-hosted instance. This helps us map an installation to a customer for support purposes. Note that this field is not being populated for users using the community plan and is only relevant to those on a professional plan.
A full list of changes can be found in the release notes on GitHub.
Grouping of inactive workspaces
Did you notice any changes in your workspaces list? Inactive workspaces are now grouped below the active workspaces and also allow users to clean up (mass delete) all inactive workspaces, see relevant pull request
Feedback is welcome, feel free to raise an issue or chat with us.
Roadmap updates
Command Line Interface (gp
)
Fixes and improvements
- #10450 - Added action to delete all inactive workspaces
- #10704 - SSH access no longer requires a private SSH key (removing forced password prompt)
- #10676 - Added action to delete all inactive workspaces
- #10357 - Fix hanging “Prebuild in Progress” page.
- #10175 - Allow customize VMOptions for JetBrains backend server, by setting
INTELLIJ_VMOPTIONS
(also GoLand/PyCharm/PhpStorm) environment variable - #10562 - Add
GITPOD_WORKSPACE_CLASS
environment variable to workspaces to allow easier identification of the workspace class - #10352 - Fix: Don’t skip prebuilds if .gitpod.yml has a ‘before’ task but no ‘init’ task
Gitpod dashboard improvements
We have made some design changes to the navbar at the top of the Gitpod dashboard. It now includes an always-visible link to your workspaces on the right, and offers better color accessibility.
The team/personal selector at the top left takes you directly to your own projects, or to the projects for the selected team. If you would prefer the team/personal selection to be preserved when you visit the workspaces list, please upvote Gitpod issue #10496.
Always ready to code 🚀
Roadmap updates
JetBrains - Roadmap issue: #7956 Beta
- #10107 - [JetBrains] Show notification when port becomes available
GP CLI
- #10388 - Gitpod CLI has a new command to list the ports from the workspace: gp ports list
SSH copy/paste - Roadmap issue: #7713
- #10291 - SSH copy/paste connections now support remote port forward
Fixes and improvements
- #10469 - Check docker-compose download
- #10458 - Update docker compose to v2.6.0
- #10442 - Revert ”[baseserver] Change default metrics port to 9502 to not clash with kube-rbac-proxy”
- #10414 - Improve workspace failure error messages
- #10413 - [supervisor] improve error message around user group and uid
- #10395 - ws-daemon: Apply the xfs limit in stages.
- #10394 - dashboard: single quote connect via ssh connection string
- #10229 - Change
/workspace
files default permissions from 0750 to 0755 - #10377 - Fixed an issue on JetBrains Gateway, preventing the workspace list from being displayed when a workspace had been created from a detached commit instead of a branch.
- #10346 - [registry-facade] Return content directly from IPFS
- #10356 - Reduce cpu and memory consumption of agent-smith
- #9475 - [experimental] add support for backing up and restoring workspace’s persistent volume claim via snapshot volume.
- #10071 - Feedback form under error messages on login and starting workspaces.
- #9491 - Correctly enforce the parallel workspace limit
- #10297 - Feedback form only shows for SaaS gitpod-io users.
- #10343 - [installer] Command line flag to configure strict config parsing
- #10364 - [content-service] Improve restoration of extended attributes
- #10290 - [experimental] add a metric to track volume snapshot time
- #10177 - JetBrains Gateway: The “Connect” button now gets disabled while a JetBrains Client is connected to the workspace.
- #10280 - [initializer] Fix issue with publicly signed SCM’s on a self-signed Gitpod instance
May Self-Hosted Release
We’ve released a new version of Self-Hosted Gitpod. Update instructions can be found in our update guide. You can read more about how to install it from scratch in our documentation. More details on this release can be found in GitHub.
For feedback, please raise an issue or chat with us.
New License tab in the admin panel
You can now see details about the license used by your installation, how many seats it has left, and the features your license includes. You can navigate to this page by going to the admin dashboard (top right corner of the Gitpod dashboard, which requires you to be an admin user) and selecting License
in the navigation menu.
Fixes and improvements
A full list of changes can be found in the release notes on GitHub.
Feedback widget for dashboard
Users are more likely to provide feedback, the easier we make it for them.
Inspired by the feedback form for Gitpod docs pages, we’ve added a similar Feedback feature in the Gitpod dashboard.
One click is enough to tell us how you feel, or write a quick note, all without leaving the page.
Roadmap updates
Public API - Roadmap issue: #7900 Alpha
Preferences
Fixes and improvements
- #10154 - [server] Skip GitHub App prebuilds when the repository has no prebuild task(s) or .gitpod.yml
- #10061 - Users can send feedback from the Dashboard.
- #9976 - Avoid prebuilding repositories were no workspaces were started recently.
- #10031 - Fix credential errors when json key is used as secret in image-builder-mk3
- #10058 - [code] Update VS Code to 1.67.0
- #8041 - Implement a new Team billing where Team Owners can conveniently manage a paid plan for their Team
- #10034 - [ws-manager-bridge] Fix cluster role binding to scrape metrics
- #10042 - Fix prebuild updates
- #10053 - [prebuild] fix incorrect handling of failed prebuilds
- #10012 - [ws-daemon] fix some workspaces fail to shutdown correctly if git operation was interrupted due to workspace termination
- #9862 - Add
disableWorkspaceGarbageCollection
experimental installer config flag - #9867 - Add
webapp.server.blockedRepositories
experimental installer config flag - #10020 - [common-go] Add file watcher, [registry-facade] Refactor watch of configuration file[ws-daemon], refactor watch of configuration file
- #9995 - [ws-daemon] Remove stray IO limiter warnings
- #9492 - Remove stargz snapshotter from image build
- #10094 - Fix conflicting auth selection for image-builder-bob
- #10127 - [installer] Use installation shortname when constructing ws-manager URL templates
- #10114 - eccomp notify: correction of system call name in the log.
- #10082 - [ws-daemon] add log entry when ready probe fails
VS Code Desktop Settings Sync
Gitpod is built to be flexible. It’s important that our users can develop with the tools that make sense for their current task and use the tools they are most comfortable with. We “integrate, don’t dictate”. This design principle extends also to our IDE and editor integrations where we have multiple options in the browser and on desktop both VS Code and JetBrains (also see: our partnership with JetBrains).
We encourage Gitpod users to use one workspace per task, move their development configurations to code, and embrace ephemerality to really get the most out of Gitpod. However, those users who choose to swap between VS Code Desktop and VS Code in the browser for editing code will have noticed that their VS Code settings (themes, plugins, and fonts, etc) weren’t kept in sync.
But since we know just how important it is for our users to have their setups and configurations just as they like them, we’re excited to let you know that VS Code settings sync now works between VS Code Desktop and the browser in Gitpod
Note: VS Code browser settings are already synced by default.
To enable VS Code settings sync on your desktop:
- Open your Gitpod workspace in VS Code Desktop
- Use the command palette to select “Settings Sync: Enable signing in with Gitpod”
- Restart your VS Code Desktop
- Resolve any settings conflicts between your browser and desktop
And you’re set! All your theme, plugins, and other settings will be synced in real-time and be reflected also when you’re working in VS Code in the browser.
Check out the VS Code settings sync documentation for more details.
Fixes and improvements
- #8248 - Add user environment variable name length and value length validation in settings UI modal.
- #9831 - Add
staticMessagebusPassword
config flag to use a fixed message bus password in the installer - #9823 - Change icon spacing in license page
- #9803 - [ws-manager] fix sometimes workspaces fail with backup not found error
- #9654 - fix account deletion failing on bad DB state
- #9795 - Make sure the server mounts the github app secret when an app is specified in the installer
- #9793 - Add
disableDbMigration
config flag to the installer to disable db migrations - #9788 - Allow setting
ide-proxy
andopenvsx-proxy
service annotations via the installer. - #9773 - Allow setting
proxy
service annotations via the installer. - #9756 - Make
runDbDeleter
for the server configurable via the installer - #9764 - Allow
proxy
service to configure a static IP via the installer - #9786 - Use a special domain name for SSH Gateway
- #9727 - Fix readiness probe issue in registry-facace when configured registry address contains a port
- #9738 - Use link component class for the editor selection modal
- #9760 - Allow
ws-manager-bridge
service to skip registering itself as a workspace, via the installer. - #9343 - [dashboard] add license tab to the admin dashboard
- #9589 - Refactor backups
- #9699 - [docker-up] Update docker compose to 2.5.0
- #9708 - [image-builder-bob] Update buildkit to v0.10.2
- #9635 - [registry-facade] Adjust IPFS client Add options
- #9732 - [content-service] Fix backup restoration
- #9768 - [ws-manager] Reduce readiness probe initialDelaySeconds
- #9778 - [image-builder] Improve error handling (no more “hostname required”)
- #9213 - [supervisor]: Remove slirp4netns
- #9706 - [supervisor]: Improve IDE readiness probe
- #9432 - Prompt first-time users to choose their default IDE
- #9731 - [kots]: automatically enable shiftfs support if cluster supports it
- #9741 - [kots]: improve installer job failure recovery
- #9701 - [kots] support s3 backend in incluster registry
- #9614 - Improved security by removing unneeded privileges from the server component.
- #9613 - Support custom CA certs for SCM systems
- #9622 - [dashboard] Disable search indexing of all web app pages
- #9545 - Allow resource requests and limits for each component to be configurable through the installer
- #9269 - [devx]: Activated “format on save” for TypeScript and JavaScript
- #9630 - Allow
disableDynamicAuthProviderLogin
,enableLocalApp
anddefaultBaseImageRegistryWhitelist
server config to be configurable via the installer - #9717 - Allow chargebee payment config to be specified via the installer for SaaS installations.
- #9718 - [KOTS]: configure blockNewUsers
April Self-Hosted Release
We’ve released a new version of Self-Hosted Gitpod. You can read more on how to install it in our documentation. More details on this release can be found in GitHub.
For feedback, please raise an issue or chat with us.
Fixes and improvements
Self-signed certificates (beta)
You can now use self-signed certificates (certificates that are not signed by a known public certificate authority) for your self-hosted Gitpod installation. This is especially useful if you want to run Gitpod in a corporate environment that uses a corporate certificate authority. You can find out more about self-signed certs in our TLS configuration guide.
Note: Self-signed certs are currently not supported on Google Cloud Platform (GKE) because you cannot get containerd to trust other certificates without being restarted.
Support for installing Gitpod in air gapped Environments
We’ve made it easier to install Gitpod in air gapped environments (an environment that is isolated to and from the internet). You can now get everything that you need to install Gitpod in a single bundle that you can then install into your air-gapped environment. You can learn more about installing in air gapped environments in our documentation.
Improved Documentation
We’ve been working on our documentation which now includes a revamped installation guide and a more detailed explanation of requirements Gitpod has on the cluster it runs on, as well as which components are needed to support it.
A full list of changes can be found on GitHub.
Support for Bitbucket Server
Gitpod now works with repositories on your own instance of Bitbucket Server. To set this up, please follow our 2-step guide in the documentation.
For feedback, please use the dedicated feedback issue or chat with us.
Fixes and improvements
- #9438 - [ws-manager] fix a bug when opening workspace you would be signed out from git and not able to do git commands
- #9493 - [ws-daemon] Check blkio throttle exists
- #9488 - fix a dashboard bug where you might end up on a workspace without having access to it
- #9135 - Connect to self-managed Bitbucket Server in Git Integration modal.
- #9460 - fix and improve validation of user environment variables
- #9455 - [kots]: add an installation status pod
- #9462 - [server] Optimization: Map GitHub API repositories during pagination, not after
- #9458 - [kots]: move dropImageRepo config to when using local registry
- #9231 - Allow integrating with ‘github.com’ without a GitHub App
- #9445 - Allow to configure JB plugins on repo level per a product, i.e. specific for IntelliJ or GoLand.
- #9328 - [ws-daemon] Remove warning when cpu.stat does not exist
- #9338 - [registry-facade] Do not log warning from local store already exist error
- #9360 - [docker-up] Add docker-compose binary
- #9366 - Automatically block users that are running blacklisted workloads
- #9382 - Revert ”[ws-daemon] Fix CPU limit annotation”
- #9355 - [ws-manager] add metrics to track initialize and finalize of workspaces
- #9358 - [ws-proxy] Do not allow ACME challenge to be processed by workspaces to ensure no one can register TLS for gitpod.io through letsencrypt
- #9356 - [docker-up] Set the MTU using ceth0 value
- #9309 - [ws-daemon] Only limit storage device classes
- #9335 - Make image-builder available through ws-manager
- #9390 - ws-daemon: align to decide if cgroup v2 to fix cgroup v2 with fuse
- #9428 - Add I/O limit plugin for cgroup v1
- #9437 - [ws-daemon] Refactor configuration of I/O limits
- #9155 - [kots]: enable use of a local registry
- #9427 - Allow workspace timeouts to be extended when a user has workspaces in different regions.
- #9446 - fixed a bug around email address rendering
- #9443 - JetBrains IDEs now start with a terminal opened, displaying an introductory message about Gitpod CLI.
- #9385 - re-enables blocklisting of email domains
- #9409 - block abusers based on email domain suffixes
- #9361 - [werft] Improve findFreeHostPorts speed
- #9404 - Fixed a bug where IO limits were not applied to the workspace
- #9219 - Stop running prebuilds for projects that did not start a workspace in the last 10+ weeks
- #9094 - [installer] Disable
definitely-gp
by default - #9381 - Update code to 1.66.2
- #9367 - Update OpenSSH to v9.0
SSH directly into workspaces
As of today, in Gitpod you can now get access to a Gitpod workspace directly via SSH with a one-liner copy/paste from the Gitpod dashboard. All you have to do is visit the Gitpod dashboard, click the more actions menu at the right-hand side of your workspace list, copy/paste the SSH command into a terminal, and voila!
Choice and flexibility for developers to choose the right tool for the job is essential. Currently, for editing your code with Gitpod, you can use VS Code in the browser, VS Code on desktop, and using JetBrains IDE’s via JetBrains Gateway. Adding copy/paste SSH support makes it easier to work directly in your terminal, or for those times you need to hop into a Gitpod workspace. To use this feature, please follow our guide our documentation
Fixes and improvements
- #9007 - Ensure uncommitted changes are displayed in dashboard when workspace was restored from backup
- #9212 - Use veth instead of slirp4netns without affecting the supervisor
- #9082 - Add custom CA cert support to Gitpod services
- #9185 - Update code to 1.66.1
- #8955 - Use a pair of veths instead of slirp4netns
- #9003 - upport direct connect workspace via ssh command
- #8783 - Display warning message when users choose latest IDEUpdate IDE choose preferences UI
- #9051 - [dashboard] Implement a PaymentContext and use it to hide payment features when payment is disabled
- #9152 - Transformer for MySQL BIGINT type to JS number
- #8630 - Allow to configure JetBrains plugins in .gitpod.yml
- #8841 - Prebuild Detail view buttons are based on Prebuild status, instead of WorkspaceInstance
- #8970 - [dashboard] It’s now even easier to contribute: set a couple variables once, contribute for as long as you like.
- #9108 - Bitbucket Server: implements token validation for Git operations.
- #9191 - [ws-manager-bridge] Skip stale prebuild events.
- #9218 - installer: make shortname configurable
- #9233 - [ws-manager-bridge] Fix statusVersion comparison.
- #9200 - [registry-facade] Fix IPFS/Redis validation
- #9186 - [image-builder-bob] Update buildkit to v0.10.1
- #9162 - [registry-facade] Revert removal of DisableKeepAlives[registry-facade] Check redis connection on start[registry-facade] Separate Redis manifest cache from IPFS[registry-facade] Check if the keys exist and use MULTI[registry-facade] Use sync.Pool as bufferInclude error in probe log
- #9176 - [ws-proxy] Deny HTTP ACME challenges
- #8576 - Allow setting custom workspace timeouts in the Gitpod Installer for self-hosted installations.
- #9004 - Fixed one frame running phase when starting workspaceFixed IDE options display incorrectly when restarting the workspaceFixed stopped workspace does not work again if it started in another place
- #9159 - [kots]: update the logo
- #9115 - Store WorkspaceInstance.status_version in d_b_prebuild_workspace and count prebuild stale events
- #9121 - [gitpod-db] Don’t consider garbage-collected prebuilds as potential bases for incremental prebuilds
- #8831 - Remove Prebuild action and log view from Project Settings view
- #9116 - ws-manager-bridge skips stale prebuild events
- #9081 - Add custom CA cert support to workspaces
- #9106 - [registry-facade] Configure credentials for Redis Sentinel
- #9125 - Added requirements to KOTS installation
- #9083 - [kots]: add a kernel version check to the preflights
- #9046 - Fixes missing login providers for Gitpod Self-Hosted.
- #9052 - [dashboard] Fix Settings menu colors in Dark theme
- #9045 - [dashboard] Remove prebuild error message from prebuild log view
- #8896 - Adding support for Projects and Prebuilds for Bitbucket Server.
- #9109 - Fixes incremental prebuilds by choosing the right prebuild base.
- #8824 - [server] For GitLab projects without an owner avatar, fall back to the namespace avatar, or generate the default GitLab avatar
- #8805 - Dashboard reports prebuild status consistently between list view and detail view.
- #9104 - [installer] Fix registry facade env variables for IPFS and redis
- #8769 - Enable the use of fuse device on cgroup v2 systems
- #9005 - Experimental IPFS support for cluster-local image caching
- #9063 - Improve workspace startup time through improved manifest assembly
- #9039 - Removed leftover workspace size limit which could prevent backups from being created.
- #9060 - [kots]: add distribution check to the KOTS preflights
- #8962 - [KOTS]: extract images from the Installer and put in the additionalImages array
- #8940 - Add workspace branch & creation timespan column for Gitpod Jetbrains Gateway plugin workspace panel
- #8941 - [image-bob-builder] Add support for stargz
- #8917 - JetBrains Gateway EAP version is now supported.
docker run --privileged
You can now run privileged containers in Gitpod!
# example
docker run --privileged -it busybox sh
Prior to the fix, users were getting an error, and it prevented them from running privileged workloads.
The host file system, in this case, is your Gitpod workspace. Don’t worry, it’s ephemeral!
Fixes and improvements
- #8459 - Made the
gitpod.io/cpuLimit
annotation work again - #8918 - [ws-proxy] Configure kube-rbac
- #8845 - Update buildkit to v0.10.0
- #8941 - [image-bob-builder] Add support for stargz
- #8878 - fix findPrebuildsWithWorkpace query
- #8875 - Remove truncation and overflow team invitation URL
- #8772 - Update team deletion confirmation modal
- #8890 - Added a new root cmd to Gitpod CLI. The tasks cmd allows listing tasks and attaching to them.
- #8914 - Add sudo permission to custom images, force NOPASSWD
- #8867 - [kots]: configure werft build command
- #8683 - Added first draft of a public API
- #8857 - [KOTS]: add recommended preflights
- #8892 - [kots]: escape golang template variables for Helm resources
- #8844 - [kots] Add a pre-flight check for `cert-manager
- #8835 - Rerunning prebuilds direct to the prebuild logs view, and rerunning is not allowed from the /prebuilds page.
- #8821 - fix missing index on Workspace (id, deleted)
- #8825 - [server] Improve GitHub Enterprise avatars handling
- #8854 - fix broken image builds
- #8858 - [gitpod-db] add index on
workspaceDB.Type
Column - #8871 - [kots]: remove wait-for-jobs
- #8870 - [kots]: remove GCP DNS resolver
- #8827 - Allow use of the —privileged flag with docker.
- #8837 - [installer]: allow for minified config YAML
- #8785 - [kots] Remove
cert-manager
from the Gitpod package - #8808 - [loadgen] Update benchmark images
- #8742 - Enable egress metrics for agent-smith
- #8822 - [kots]: removed the cert-manager issuers
- #8491 - [kots]: use Helm for the Installer job
- #8721 - Document ClusterService rpcs and messages
- #8699 - Clarified wording of “timeout” feature on the settings/plans page
- #8718 - ws-manager-bridge logs WorkspaceStatus events
- #8644 - Fix setting sync limit failure in some cases
- #8793 - fix caching of GitHub server-server queries
- #8593 - Make the licensing match what’s advertised
- #8770 - [kubecdl] Fix server name pattern
- #8741 - Update code to 1.65.2
Support for GitHub Enterprise Server
Gitpod now works with public, private, or internal repositories on your own instance of GitHub Enterprise (GHE). To set this up, please follow our 2-step guide in the documentation.
For feedback, please use the dedicated feedback issue or chat with us.
Fixes and improvements
- #8533 - Update k8s go dependencies to v1.23.4Update prometheus to v1.12.1 CVE-2022-21698Update containerd to v1.6.0
- #8578 - Support user-modifiable cgroupv2 structure
- #8583 - Remove unused pod labels
- #8580 - [installer] Registry facade should not use a port from node ports range
- #8555 - Add docker images for gpctl and kubecdl
- #8590 - Update the docs for cgroup v2
- #8471 - Support cpu limiting using cgroup v2
- #8629 - Disable cache reclaim when cgroup v2
- #8550 - Add support for private registries
- #8632 - Admins cannot search empty strings or partial matches on workspace search.
- #8574 - Support GitHub Enterprise
- #8689 - [kots]: create dev channels in KOTS and formalise the release process
- #8568 - Rate-limit workspace prebuilds to 50 per minute (rolling-window) by default, configurable through config.
- #8633 - [kots]: make the self-hosted cert more explicitly selectable
- #8486 - improve robustness of startWorkspaceimprove feedback for errors during cluster selectionimprove monitoring for cluster selection errors
- #8547 - [installer]: add annotation to make DB resources restart if changes
- #8622 - [installer] Add network policy for registry-facade access to coredns
- #8562 - Fix user detail bug that fetches all workspaces.
- #8558 - [dashboard] Don’t always print ‘Connecting to workspace logs…’ (it’s somewhat misleading)
- #8546 - Link to privacy policy from login page
- #8395 - [kots]: add the KOTS installation manifests
- #8503 - Free text search on workspace admin dashboard is not enabled anymore.
- #8363 - Remove ghost from the codebase
- #8477 - Renamed
danger-use-unsupported-config
flag in the installer to `use-experimental-config - #8527 - [installer]: correct the stored config to include apiVersion
- #8519 - Try harder to update workspace annotation to prevent workspace from being marked as failed erroneously.
- #7831 - Git Integrations UI – improve handling of host name.
- #8428 - Deal with when cpu.cfs_quota_us is negative
- #8435 - Docker in workspaces now allows mapping the user id of a container user to the workspace gitpod user
- #8463 - Improve handling of an error when pod fails to start due to out of memory error on the node
- #8460 - [installer]: remove jaeger operator from the config
- #8402 - Admins can find teams, see team details, and change a team member’s role.
- #8211 - Add Replicated as a Gitpod license evaluator
- #8330 - Improve error handling for workspace cluster register & updateShow all admission constraints for workspace cluster list
- #8307 - Add max lifetime timeout for a workspace
- #8389 - [installer] Ensure multiple ws-proxy replicas are scheduled in different nodes
- #8401 - Make
-c
optional in installer, while allowing the passed config to be flexible - #8373 - Show correct admin telemetry settings during first visit
- #8376 - Remove Jaeger operator
- #8266 - Make Open VSX upstream URL configurable in the installer for air-gap installations
- #8380 - Pre-populate Cmd+O modal and sort suggested context URLs by most-recently-used first
Making snapshots safer for sharing
Gitpod now restricts access to workspaces opened with snapshot URLs.
Users must have access to the git repository in the snapshot, in order to open it.
If a snapshot URL user does not have read access to the repo, Gitpod will now show an error message. Previously, any logged-in Gitpod user could open snapshot URLs for any workspace.
This change matches what happens when users open a new workspace on a private repository, using a prefixed context url. The change also helps to prevent leakage of sensitive or proprietary files via snapshots. To learn more about collaboration and sharing, please have a look at our documentation
Breaking change
This change may impact you if you are intentionally sharing a private repository using a snapshot, say for an interview.
Workarounds
- Use a public repository instead of a private one.
- Invite users to the private repository (or to the team on the org) as collaborators.
- Share a running workspace instead of a snapshot URL.
Feedback
As always, please contact Gitpod if you have any feedback to share with us.
Open in Gitpod
It’s even easier now to open a repository in a new Gitpod workspace.
Type cmd+O (ctrl-O on Windows) while on any page in the dashboard at gitpod.io.
This will pop up an input where you can paste a context URL for a git repository, and immediately open a workspace, just like you are used to with the gitpod.io/#
prefix.
Instead of pasting a URL, you can start typing the name of a repository, and Gitpod will suggest repositories from recent workspaces, as well as from your connected git provider. Even our popular example template repositories can be opened this way.
Always ready to code 🚀
Fixes and improvements
- #8234 - Add stress test for mount proc
- #7523 - messagebus: remove cross-cluster dependency
- #8275 - Update the usage of nsinsider.
- #8288 - [installer] Installer does not set default nameserver settings for workspaces anymore
- #8289 - Improve handling of “Out of Memory” error when starting up workspaces
- #8067 - [server]: Add
totalUsers
,totalWorkspaces
, andtotalInstances
fields to telemetry data - #8270 - [self-hosted] Skip MinIO client configuration in the MinIO container because it breaks air-gap installations.
- #8086 - Bitbucket Server: Authorize with Bitbucket Server 7.20 and start workspaces.
- #8227 - [server] Disable
perMessageDeflate
on websockets
New workspace images built with Dazzle v2
By default, your Gitpod workspaces are based on a Docker image called gitpod/workspace-full
. It contains all sorts of tools, SDKs and languages you may need — so you are ready-to-code with no friction.
What if you were only interested in Rust though, or Node.js LTS? You could create a custom Dockerfile, tell Gitpod about it and all would be fine. It would even be pretty simple to do.
At Gitpod, we are all about removing friction and frequently ask ourselves, “How can we improve?“. So we came up with an even easier solution. We are now in a position to create much more fine-grained workspace images!
To start this next era, we recently built a whole bunch of new images with Dazzle v2. Dazzle is a Docker/OCI image builder and its goal is to build independent layers where a change to one layer does not invalidate the ones sitting “above” it.
Compared to the previous version of Dazzle, the new v2 is about 5x faster, more reliable and less hacky 🔨.
Here is a list of what you can use today:
gitpod/workspace-c
gitpod/workspace-clojure
gitpod/workspace-go
gitpod/workspace-node
gitpod/workspace-node-lts
gitpod/workspace-python
gitpod/workspace-ruby-2
gitpod/workspace-ruby-3
gitpod/workspace-rust
For an up-to-date list of available images, please refer to this list.
In your .gitpod.yml
, all you need to do is add the following line:
image: gitpod/workspace-xyz
As if this wasn’t exciting enough, this new solution lays the foundation for some very cool features you will be able to leverage directly to create custom images for your workspaces.
To tease this a bit more, imagine a future where you can pick & choose which tools you’d like to install in your workspace and Gitpod will automagically provide them to you at lightspeed, or thereabouts.
We are interested in your feedback and suggestions, please let us know in our dedicated feedback issue or chat with us.
Fixes and improvements
- #8119 - Added support for Git LFS during content init
- #8134 - Enable id check for seccomp notify
- #8139 - Improved workspace memory-pressure eviction resilience
- #8161 - Add workspace start request debug logging to ws-manager
- #8179 - A bit of improvements to cache_reclaim
- #8132 - [GitHub] Fix the user account picked for a prebuild.
- #8143 - Update code to 1.64.2
- #8112 - Autofix: upgrade-nvm-tools
- #8099 - fix dashboard contextURL handling
- #7569 - Support private dotfiles repo
- #8100 - Make
ContextURL.parseToURL
support the newly-acceptedgit@[host]:[user]/[repo].git
format - #8036 - Refactor dynamic CPU limiting to provide fairer scheduling.
- #8093 - Fix wrong token selection if multiple found for a profile.
- #7715 - [server][dashboard] Improve ‘New Workspace’ modal with a search input, keyboard navigation, and a new context URL suggestion API
- #7833 - Fix Bitbucket push event handling
- #8073 - configure basic rate-limiting for `startWorkspace
- #7727 - [installer]: add jaeger sampling options to the tracing object
- #7923 - Improved in-transit security of user environment variables
- #7968 - Fix missing status updates for prebuilds.
- #7940 - reduce idle DB load on SH installations
- #7978 - [gitlab] user-scoped env vars can now be filtered for nested repos on Gitlab
- #7882 - Admins can do a text search for projects and their associated prebuilds.
- #7951 - [server] Support ‘git@[host]:[user]/[repo].git’ format in context URLs
- #7839 - [installer]: put component ownership under webapp/workspace teams
- #7926 - [wa-manager] Refactor connectToWorkspaceDaemon helper
Project-level environment variables
It’s time to bring environment variables to Projects, and with that to Prebuilds as well!
Environment variables can now be set for individual Projects, which automatically makes them available when Gitpod runs a Prebuild for your project.
By default, these environment variables are not accessible in workspaces. You can, if you desire so, make them available in workspaces too. However, keep in mind that if you do so, anyone who starts a Gitpod workspace for your project will see the value of these environment variables.
To get started, make sure you have created a project at gitpod.io/new. You will then be able to visit its Settings page, where you find a new Variables section.
We are interested in your feedback and suggestions, please let us know in our dedicated feedback issue or chat with us.
Fixes and improvements
- #7895 - werft run github -j .werft/clean-up-werft-build-nodes.yaml -f
- #7873 - [Installer]: release 2022.01
- #7769 - [installer] Add missing kube-rbac-proxy container in ws-manager deployment
- #7774 - [installer] Do not start binaries in verbose mode
- #7362 - - Refactor JB integration to connect over SSH instead of CWM links.- Provide Gitpod integration in JB Gateway.
- #7732 - [Dashboard]: add send telemetry to admin settings
- #7801 - [installer]: add namespace to validate cluster command
- #7837 - Fix “token not found” issues.
- #7430 - Remove ws-scheduler component
- #7760 - Support heartbeats from SSH sessions
- #7591 - [server]: Create installation admin controller
- #7752 - [installer] Fix invalid tag name for image build template
- #7302 - [dashboard] Error messages on workspace creation when the repository is not found, will now also display the name of the repository
- #7753 - Improved feedback when content initialisation fails
- #7514 - Autofix: upgrade-nvm-tools
- #7730 - [installation-telemetry]: log data sent to Segment
- #7472 - [ws-manager] Improve workspaces PodAffinity
- #7657 - Make proc mounts more reliable which affects parallel Docker container startup
- #7623 - [installer] Fix ws-daemon image pull policy
- #7656 - [installer] Fix lifecycle PostStart label update
- #7670 - [installer] Fix registry-facade ClusterRoleBinding name
- #7660 - [installer] Switch default log level to info
- #7687 - [installer] Telemetry should not run in workspace clusters
- #7633 - Admin users can download the account statement.
- #7295 - Introduce Project-level environment variables
- #7659 - [dashboard] Don’t offer to add common email domains as a verified student domains in Admin
- #7625 - [installer] Fix mysql image pull policy
- #7642 - [Installer]: remove the deprecated TypeORM migration command
Dotfiles support in Beta
Happy new year from us at Gitpod 🥂!
We kick off 2022 with the availability of dotfiles support for anyone - currently in Beta.
If you are already familiar with dotfiles, configure it in your Gitpod preferences. All we need is a URL to your dotfiles repository. We will do the rest whenever you start a new Gitpod workspace. Enjoy 😊.
What are dotfiles, anyway?
You may have seen a .bashrc
file or similar in a Unix environment. Basically, a place for you to configure and customize your shell. The operating system runs commands in these dotfiles automatically. This ensures your environment always has your customizations applied when you start your computer.
Dotfiles allow you to really customize your workflow and hence can increae your productivity significantly. It’s well worth looking into.
With today’s announcement, you can now leverage these exact same files in all your Gitpod workspaces! This removes one more friction for anyone who’s been on the fence as to whether or not cloud-based developer environments are worth exploring. Invest an hour today, you may like what you find. Start at gitpod.io/preferences.
Please try it out and share your experience with us and the Gitpod community. You can learn more about Dotfiles in the documentation.
We are interested in your feedback and suggestions, please let us know in our dedicated feedback issue or chat with us.
Fixes and improvements
- #7387 - Provide SLSA/in-toto provenance for the build
- #7606 - Removed “workspaces” from projects and teams and have a single global workspaces list, that shows all my workspaces.Made the single “workspaces” list the default landing place in the dashboard.
- #7504 - The GraphQL API has been removed
- #7241 - Route users to Discord for support
- #7503 - [installation-telemetry]: initial commit plus installer setup
- #7535 - [GitHub] Optionally prevent merging pull requests when prebuilds fail.
- #7578 - Add bottom padding for Projects, Branches, and Prebuilds pages
- #7596 - [installer] Adjust rabbitmq helm chart probes configuration
- #7156 - [Installer]: simplify container image mirroring
- #7508 - [installer]: use a pointer deref if the ssh gateway secret does not exist
- #7391 - Use repository org and name for workspace ids.
- #7512 - [ws-manager] Adjust probe InitialDelaySeconds
- #7510 - [installer] Adjust default MySQL value
- #7463 - Adds analytic tracking to git commands requiring the git credential manager (remote-facing commands)
- #7511 - [installer] Adjust mysql helm chart probes configuration
Self-managed k3s on GCP
Gitpod’s services run on Kubernetes and are what you would consider a “classic cloud-native application”. When you start a workspace for your project, we also run that on Kubernetes, but the requirements are very different from what Gitpod services need.
To run your workspaces, we deeply integrate with the Kernel, the container runtime and the Kubernetes control plane.
Up until recently, everything above ran on Google Cloud’s Kubernetes Engine (GKE). This continues to be the case for Gitpod’s services, but we moved user workspaces to self-managed k3s on GCP.
In short, this move brings better performance that will benefit your daily work, but also gets us closer to upstream and provides us with more flexibility. It is a foundation we put in place to build upon in the weeks and months to come!
Before you decide to follow our lead though, please see our CTO Chris’ in-depth explanation of benefits, gotchas and overall details of this migration.
Fixes and improvements
- #7312 - Profile of the user who already added a project is linked.
- #7177 - Allow auth provider secrets to be passed in via a secret
- #7012 - Allow setting a name and a description for each port on .gitpod.yml
- #7354 - Fix Team Workspace Success Criteria dashboard
- #7107 - [installer]: update docker-registry to allow for pod security policy application
- #6827 - 1. [installer] Add a namespace for the cert-manager self-signing issuer so it can be uninstalled using the configmap.2. [installer] Set EnableLocalApp to true by default.
- #7206 - [installer]: correct the starts_with validation on the config
- #7200 - [installer]: separate server and IDE components
- #7163 - Improved start page when a GitHub app is not installed.
JetBrains desktop available in beta
Gitpod currently has IntelliJ, GoLand, PhpStorm and PyCharm released in beta. The rest of the JetBrains IDE’s are all coming to Gitpod very soon, watch this space!
Previously, when you loaded a new Gitpod workspace, you would find yourself in a VS Code Browser experience. Using a browser editor like VS Code Browser is the main way Gitpod can get you “ready to code” instantly.
However, whilst we know that VS Code is the most widely adopted editor on the market (which is why we started with VS Code), Gitpod is not only built for VS Code users!
Gitpod is for teams, and companies of all shapes and sizes. We’re here to support, and integrate with as many of the different developer workflows used in modern software development. After all, it’s your dev environment, so you should be able to set it up your way.
And that’s why today, we’re happy to share that JetBrains desktop is now in beta!
You can get started using the JetBrains IDE’s today by: heading over to your Gitpod preferences page, enabling your favourite JetBrains desktop IDE’s, and restarting any running workspaces. The next time you start a workspace, you’ll be prompted about which editor to use: VS Code Browser, VS Code Desktop, or your preferred JetBrains IDE. However, even when you open a Gitpod workspace with a desktop editor, you still get the ease and developer experience of using VS Code Browser to edit and work on the same workspace and code at the same time, they’re entirely synced.
Work on your desktop if you like, share your workspace if you like, the choice is yours! To keep an eye on which editors we support at any given time, check the editors docs.
We are interested in your feedback and suggestions, please let us know in our dedicated feedback issue or chat with us.
Fixes and improvements
- #7004 - Add PyCharm desktop IDE.
- #6847 - The “Your Workspace is Ready” page for desktop IDEs now has “Stop Workspace” and “Go to Dashboard” actions.
- #6721 - When a user deletes their account, own projects will be deleted and made available to be added again.
- #6671 - Add VS Code Desktop in the preferences to always open your workspace in VS Code Desktop
- #6747 - [dashboard] Change default color theme from Light → System
- #6713 - Allow all team members to cancel a team prebuild
- #6505 - Open up JetBrains desktop IDE feature (BETA) for all users
- #6546 - Prebuilds can run for GitLab subgroup projects.
- #6464 - Switch to shallow git clone and add unshallow feature
- #6144 - make “snapshots” more reliable
Self-Hosted
- #6621 - Allow use of external container registry
- #6606 - Add support for GCP CloudSQL
- #6543 - Make the installer updatable
Gitpod Self-Hosted installers
If you prefer to install Gitpod in your own environment, we are pleased to announce this process has become a whole lot simpler.
Say hello to make install
🎉!
Yes really, our shiny new installer scripts take care of the heavy lifting while all we ask from you is to configure a file or two (depending on your hosting provider) and you’re up and running in no time.
Get started today with installer guides for:
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Microsoft Azure Kubernetes Service (AKS)
Please let us know what you think via Twitter @gitpod or chat with us at https://www.gitpod.io/chat.
Fixes and improvements
- #6652 - Bitbucket-only users get an error message now on New Project page
- #6775 - make DB layer more robust against odd DB values
- #6847 - The “Your Workspace is Ready” page for desktop IDEs now has “Stop Workspace” and “Go to Dashboard” actions.
- #6031 - add
GIT_AUTHOR_EMAIL
to the environment variables mentioned in account settings - #6883 - [dashboard][server] Make all project slugs unique within a team or user account by adding a unique suffix
- #6702 - Add container registry and database secret checks
- #6716 - Configure and validate the external database
- #6753 - [installer]: fix the auth provider config
- #6682 - [gpctl] Support forceful cluster de-registration
- #6760 - [installer]: fix jaeger operator misconfiguration
- #6733 - [ws-daemon] Fix resource leak during proc mounts
- #6745 - Configure Azure blob storage for installer
- #6860 - [image-builder] Fix authentication issues with external registries
- #6862 - Apply node affinities to components
- #6870 - [ws-proxy] Improve TLS default configuration
- #6893 - Set internal certs to 90 day duration
- #6892 - Change Minio to forked version
Improved workspace startup times
Speeeed 🚀! When you start a new workspace, we changed how we clone your repository. Going forward, we have a two step approach:
- Clone the most recent commit only (with the
depth=1
git flag) - About ten seconds later, we start to fetch 20 additional commits
Thanks to this, we let you start your work sooner while we fetch a few more commits. You can find the details of this change in the #6464 pull request.
Please let us know what you think via Twitter @gitpod or chat with us at https://www.gitpod.io/chat.
Fixes and improvements
- #6582 - Update VS Code Web to 1.62.0
- #6462 - [ws-proxy] Decouple ws-proxy from ws-manager
- #6546 - Prebuilds can run for GitLab subgroup projects.
- #6577 - Preserve team scope in dashboard
- #6505 - Open up JetBrains desktop IDE feature (BETA) for all users
- #6636 - GCP object storage bugfixes
- #6621 - Allow use of external container registry
- #6606 - Add support for GCP CloudSQL
- #6591 - Create config map to allow uninstallation of app
- #6144 - make “snapshots” more reliable
- #6376 - New GitLab projects will have a slugified Project url
- #6584 - allow img-builder ingress from server
Tailscale on Gitpod
With the availability of Tailscale support, you can connect Gitpod workspaces to other resources & services needed. Think of a database hosted behind a corporate firewall or in your on-prem data center.
Equally exciting is the possibility to connect multiple Gitpod workspaces with each other. Imagine a project with microservices which all have their own git repository. Configure Tailscale in each repository and once you start workspaces, the individual services will be able to communicate with each other.
You can learn more about this topic in our Network Bridging documentation. Alternatively, we have a template repository with the required configuration you can apply to your own projects.
Please let us know what you think via Twitter @gitpod or chat with us at https://www.gitpod.io/chat.
Fixes and improvements
- #5865 - Make it possible to cancel pending or running Prebuilds
- #6273 - Deleted team’s name can be reused.
- #6312 -
/admin
: Improve performance of workspace queries - #6048 - Replace /workspaces → /projects as default landing page for both users and teams
- #6038 - Truncate workspace context in the workspace deletion modal
- #6409 - Experimental support for
CAP_NET_ADMIN
in workspaces - #6234 - Validate the cluster is in a state for Gitpod to be installed to
- #6265 - Installation config validation
- #6338 - Automated workspace deployment framework and design proposal and prelim checkin for workspace cluster creation
- #6453 - [ws-manager]: Add check for IdeImage not being present in the spec
- #6348 - Switch from dropbear to OpenSSH
- #6389 - Always enable the New Workspace button on the Configuration Page.
Introducing Teams and Projects
Up until today, you must have felt at times that your Gitpod dashboard is a pretty empty place 😔. All you had, besides settings and stuff, was a list of your active workspaces (not even old ones without changing the filter - yep yep, we fixed that too 😉).
We are so stoked to announce Teams & Projects (& Prebuilds) available in beta 🎉
To get started right away, gitpod.io/new.
Teams
You can now create teams (as many as you want) and invite your co-workers, friends & family to collaborate on your projects.
Projects
Remember .gitpod.yml
, checked in to your project’s root directory? It’s still the first place we look for Gitpod configuration, but when you create a project in the Gitpod dashboard, we now do our best to be smart and suggest a sensible default configuration for your project (insert something something machine learning - jk, there’s no magic).
Bonus - Prebuilds 🤩
Nobody asked me, but if they had I would have said the announcement should have been Teams, Projects & Prebuilds 😅. How come?
For the first time ever, we now show you each and every prebuild we run for your project! Check the status, view the logs or trigger new prebuilds from within the dashboard.
When you use the new onboarding workflow at gitpod.io/new, we help you kick off your first prebuild. With prebuilds, Gitpod builds your dev environment for each change you push to your repository. This means, when you’re ready to open a new workspace, it’ll already have all init start tasks executed.
You can learn more in the docs.
Expect more updates to all this over time. For now we’d love to hear about your experience. Please let us know in the feedback issue, contact us via Twitter @gitpod or chat with us at https://www.gitpod.io/chat.
Fixes and improvements
- #6171 - Enable setting of DB username with DB_USERNAME envvar
- #6185 - Add ‘New Workspace’ context menu option to all Projects cards
- #6187 - [projects] Fix Project card bottom row layout
- #6074 - Truncate commit message on branches and prebuilds
- #5802 - Update Kubernetes dependencies to v0.22.2Update controller-runtime to v0.10.1
- #6158 - Fix: Ensures that string-based env values defined in
.gitpod.yml
are not set with enclosing quotation marks. - #6090 - [image-builder-mk3] Fix image build error “did not produce a workspace image”
- #6218 - [ws-manager] Introduce stoppedByRequest annotation marking workspaces explicitly stopped using a
StopWorkspace
call - #6164 - Add admission constraints to support fine-grained cluster selection
- #6107 - Fix re-running a Prebuild with a different out-of-repo configuration
- #6166 - [gitpod-protocol] Adjust typescript GRPC options
- #6163 - Refactor GRPC TLS connection defaults
- #6069 - Allow importing of Helm dependencies
- #6095 - VS Code: Add a Get Started with Gitpod walk-through
Automatic preview page reloads
A small, but mighty improvement to your web application preview. No more manual page refresh when you open the preview before the application’s port is ready.
Gitpod now reloads the page every five seconds, automatically. Once your application listens on a port, the preview will reload and you’re ready to code.
Please let us know what you think via Twitter @gitpod or chat with us at https://www.gitpod.io/chat.
Fixes and improvements
- #5836 - Make it possible to re-trigger failed or timed out Prebuilds
- #5640 - [Teams & Projects] Ask for authorization when viewing a project of a provider without connection
- #5967 - [teams] Fix joining teams from different DB region
- #5572 - Refactor integration tests using sigs.k8s.io/e2e-framework
- #5935 - [dashboard] fix accumulating websocket connections
- #5897 - [workspace] Make the workspace stopping mechanism more deterministic
- #5918 - [prebuilds] fix prebuild logs with multiple tasks
- #5693 - [image-builder] Include environment variables in the built workspace image
- #5920 - [db] add missing index `d_b_prebuild_workspace.buildWorkspaceId
- #5899 - fix log format for meta components
- #5787 - improve websocket reconnection handling in the frontend
VS Code Desktop support
It’s here 🎉! Starting today, you can access Gitpod workspaces right from your locally installed VS Code - we call it “VS Code Desktop Support”. Yep, that’s right - keep your local settings1 and benefit from Gitpod’s high-spec servers & automated prebuilds. As you would expect, your code continues to stay in an ephemeral Gitpod workspace which keeps each of your projects nicely isolated from one another.
To get started, all it takes is two steps:
- Start a new Gitpod workspace (learn how in the docs).
- Open the command palette ( ), type “Open in VS Code” and hit .
This opens your local VS Code, connects to the Gitpod workspace and let’s you develop, test & debug your application as if it was running locally.
We continue to enhance this feature, but for now we’d love to hear about your experience. Please let us know in the feedback issue, contact us via Twitter @gitpod or chat with us at https://www.gitpod.io/chat.
If you are already familiar with the Local Companion app we announced in June, note that VS Code Desktop Support is built on top of it and you can continue to use the Local Companion app independently of VS Code.
1 may I add, yes this also means you get to keep your keyboard shortcuts just the way you prefer them. You know, Ctrl/Cmd + W to close an editor tab 😉.
Fixes and improvements
- #5511 - Breaking Change: Remove Theia settings and point to Code image
- #5633 - Update code to 1.60.0
- #4997 - OpenVSX proxy cache
- #5568 - GitLab users who have not completed the auth process on GitLab will be notified with an error message
- #5362 - [gitlab] Accept ’#’ sign in branches / context URLs
- #5180 - [docker-up] Update docker-compose and slirp4netns
- #5513 - [code] Add open dashboard menu option to home menu
- #5456 - vscode desktop on windows
Faster workspace startup times
A key metric we deeply care about at Gitpod (and I’m sure you do, too) is workspace startup time. In a world where you create and dispose of workspaces many times per day, the last thing you want is waiting for a workspace to start 🐌.
In this release, we made significant progress in lowering startup times 🏎. What initially may sound like complex changes turned out to be a +4 -4
pull request (#4847). Yay simplicity!
To give you an idea of the magnitute of improvement we’re talking about, here’s a before / after comparison with 30 workspaces started twice:
Before | Now |
---|---|
Did you pay close attention to the y-axis? From between 20 to 60 seconds down to 5 to 20 seconds!
Great work team, let’s shift our focus to other features. These improvements are certainly worth celebrating 🎂, but we’re hungry to drop these times by at least the same magnitude once or twice more! Team, finish your cake and get back to work 😉.
Please do let us know if you notice any differences with your project startup times. You can find us at www.gitpod.io/chat.
Fixes and improvements
- #4844 - Provide better feedback when gitpod.yml is invalid
- #4816 - [gp] env: handle multi-word values without quotes
- #4813 - [server] Handle releases/tag/
in GitHub context parser - #4743 - [code] confirm sharing
- #4738 - [code] serve each webview from own origin
- #4734 - [#4699] Handle error situations around /headless-logs endpoint
- #4115 - [server] store separate email used for commits (GitHub and GitLab). Thanks to @philschatz.
Gitpod Self-Hosted
We released 0.10.0
and updated the documentation to match. Head over to the docs for getting started.
Introducing the Gitpod Local Companion app
As of today, you can access your Gitpod workspace from your local environment 🎉!
Why does this matter? Imagine you start a development server for your web application in Gitpod. You can preview that online at a https://nnnn-x.y.gitpod.io URL, where “nnnn” is the port your dev server listens on. Sometimes though, development features such as live reloading may not be compatible with that URL format and rather require something like http://localhost:10000 to communicate with the dev server.
With the Gitpod Local Companion app, localhost URLs can now access your dev server running in a Gitpod workspace. The best part of that: It works with any TCP port. You could run a MySQL database in your Gitpod workspace and access the database with your favourite GUI through localhost:3306.
To learn more and get started today, please see our introduction blog post.
Fixes and improvements
- #4548 - Breaking Change: Make ports configured in
.gitpod.yml
private by default when no value forvisibility
is given (was public). This change is for security reasons. - #4614 - Added a deprecation warning for Theia.
- #4543 - Deprecate
prebuild
task ingitpod.yml
. - #4542 - Remove
ide
task ingitpod.yml
. - #4524 - Remove deprecated
openModes
in `.gitpod.yml. - #4633 - Fix gp open/preview to await till VS Code UI is available.
- #3259 - Support VS Code web extensions which are running in a browser worker, (particularly Vim).
- #2879 - Fix unvalidated redirects (credit: Arif Khan from SaveBreach Team).
- #4580 - Support workspace sharing from VS Code.
- #4627 - Deprecate user uploaded extensions.
- #4560 - Fix out of order typing in terminals.
- #4589 - Add dodo to animals (thanks @a2br!).
- #4287 - Modify the “New Git Integration” experience to align with provider terminology (thanks @jordanhailey!).
- #4401, #4490, #4571 - Implement a new Teams UI in the dashboard (behind a feature flag).
Faster, incremental prebuilds
With prebuilds, Gitpod continuously builds your developer environment so that it is ready-to-code by the time you start a new workspace.
So far, Gitpod started each prebuild from a clean slate. With this latest release, Gitpod now supports incremental prebuilds, which means Gitpod will try to re-use a prebuild from an earlier commit in order to create new prebuilds faster. In short, it now takes less time for your prebuild to be ready after a new commit is pushed to your Git provider.
Note: This is a controlled feature release so that we can measure the performance impact on projects. There is nothing you need to do other than wait and at some point experience quicker prebuild times 🚀.
Fixes and improvements
- #3995 - Implement new Self-Hosted setup flow.
- #4170 - Hide “stopping” & unpinned workspaces from “Active” in the dashboard.
- #4118 - Fix Cross Origin Websocket Access (credit: Joern Schneeweisz from the GitLab Security Research Team).
Hello Dark mode
We heard you and implemented a dashboard dark mode (PR #3901) 🌑! Head over to https://gitpod.io/preferences to pick the light or dark theme. Alternatively, select “System” and let us pick the theme that matches your system settings.
If you have specific feedback related to dark mode, please let us know in our feedback issue #3727 🙏🏻.
Fixes and improvements
- #3940 - Add OAuth2 host check (credit: Joern Schneeweisz from the GitLab Security Research Team).
- #4051 - Ask user for confirmation before deleting an environment variable.
- #4069 - Fix loading Gitpod’s dashboard in Safari less than v14.
- #3830 - Optimize Gitpod’s dashboard to make it lighter and load faster.
- #4018 - Make the Docker daemon in workspaces auto-start when needed by introducing a socket activated ‘sudo docker-up’.
- #3945 - UX: Fix accidental workspace deletion when using the ‘Enter’ key.
- #3938 - Also show environment variables with identical names but different scopes in the dashboard.
- #3866 - Fix quantity type conversion in Team plans.
🍊 Dashboard Redesign
Aligned with our Next Chapter for Gitpod announcement, we reimplemented and redesigned the Gitpod dashboard!
Technical improvements under the hood result in a more performant, snappier dashboard. We would love to hear your feedback and learn how we can provide you with an even better experience. Please provide your comments in our feedback issue #3727 🙏🏻.
Synchronize Theia user settings with VS Code
We recently launched support for VS Code.
If you switch your editor to VS Code, your user settings and extensions configured in Theia will be synchronized with VS Code automatically when you start a new workspace (unless you manually uploaded an extension).
Fixes and improvements
- #3087 - Remove the privileged feature flag.
- #3175 - Fix Env Var context parsing.
- #3177 - [supervisor] Let supervisor fail when first IDE start fails.
- #3182 - [registry-facade] Remove feature flag.
- #3228 - Allow air-gap Gitpod installations.
- Improved workspace startup time in high-load situations.
- Started to adopt the controller framework which will lead to Gitpod producing less load on the Kubernetes API.
Monthly Newsletter
Subscribe to get a summary of what we've shipped over the last month, plus everything you need to know around developer experience.