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:

1. Skip 20 commits by default (if no previous setting was applied)
2. Search the past 100 commits for a successful prebuild to base a workspace on
3. 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:

1. All branches (the default setting)
2. Default branch only (e.g. main)
3. 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:

1. Can be executed repeatedly, while always producing the same end-state in the file system for a given reposiotry state.
2. Execute quickly when executed the second time (e.g. process changes incrementally).

---

For more, see Repositories and Prebuilds.