October 6, 2023
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.