Prebuilds

Prebuilds help optimize the time to start a workspace by executing any defined installation tasks from the .gitpod.yml in an associated repository asynchronously ahead of time. Gitpod will search the last 100 ancestor commits for a successful prebuild to use as a base for a workspace. Prebuilds work similarly to Continuous Integration (CI) systems by responding to an SCM trigger (e.g. a webhook). For Prebuilds, it helps to be familiar with the following Gitpod features:

  1. Imported repositories
  2. Tasks
  3. .gitpod.yml

Prebuild settings

Commit Interval

To balance frequency of prebuilds with repository activity (e.g. number of commits) you can adjust the number of commits that are skipped between prebuilds. The default is 20.

Filtering Prebuilds

A Prebuild filter allows you to configure when a Prebuild should execute. Prebuild filters help to save costs by not running Prebuilds unnecessarily. You can filter prebuilds in your project settings by:

  1. Enabling (or disabling) Prebuilds entirely
  2. Constraining triggering to push events targeting:
    • all branches (the default setting)
    • the default branch only (e.g. main)
    • any branches specified via glob pattern

Managing Prebuilds

To configure a Prebuild for a repository, you must:

  1. Add an init or before task in the repository’s gitpod.yml.
  2. Import the repository (see Imported Repositories).
  3. Enable Prebuilds in the repository’s settings.

Tip: You can test changes to your tasks and .gitpod.yml directly in your workspace by running the gp validate --prebuild command.

Configuring Prebuilds

A prebuild cannot be executed unless you tell Gitpod explicitly which steps in your .gitpod.yml to run. You can do this by ensuring you have either an init or before task present.

The below example .gitpod.yml shows a repository that will run npm install inside a Prebuild. The command task with npm start is not executed in the Prebuild as it’s assumed to be a long-running process, e.g. a web server.

language icon yml
tasks:
    - init: |
          npm install
    - command: |
          npm start

Enabling prebuilds

To enable prebuilds for a repository:

  1. Select it under /repositories
  2. Under Prebuild settings, flip the switch and optionally, configure them to your liking.

Prebuilds require the user to have SCM permissions to create a webhook. If you do not have these permissions, you will not be able to enable Prebuilds.

When a Prebuild runs successfully, you will see a message similar to the following in your workspace output:

language icon txt
🍊 This task ran as a workspace prebuild
⏱️ Well done on saving 6 minutes

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 and costs.

View prebuilds

You can find a log of past prebuilds of your imported repositories on the /prebuilds page. Additionally, you can also filter for a specific repository or only show prebuilds in a specific state in the dropdowns at the top of the page.

Rerun a Prebuild

Prebuilds can be triggered manually for debugging purposes. To rerun a prebuild:

  1. Select the desired prebuild from the prebuilds list.
  2. Click “Rerun Prebuild”.

Prebuild limitations

Adding Prebuilds requires webhook permissions

Enabling Prebuilds requires the user to have SCM permissions to create a webhook.

Only the /workspace directory is persisted from a Prebuild

Once a Prebuild is completed, a snapshot of the filesystem is taken. However, this snapshot only includes the /workspace directory. Other directories like the home directory are not saved by Prebuilds. To ensure the necessary files are saved, copy them to the /workspace directory before the Prebuild completes, and/or restore those files in your command task.

Prebuilds have a 1 hour time limit

Prebuilds have a timeout of 1 hour. If your before and init tasks combined exceed 1 hour, your Prebuild will be terminated.

Prebuilds are executed as the user who enables them

To pull git information into a workspace, Prebuilds are executed on behalf of the user who created the Prebuild.

Prebuilds are only available to organization members

Even if your repository is public, only members of your Gitpod Organization will have access to its prebuilds. Public contributors to your repository will not be able to use prebuilds at this time.

Frequently Asked Questions (FAQs)

Can I use project environment variables in Prebuilds?

Yes, environment variables that are defined in project settings will be visible in Prebuilds.

Was this helpful?