Description
Bug description
When Incremental Prebuilds are enabled for a project, new prebuilds will look for a compatible parent prebuild (by looking up the ancestor commits) in order to use it as a base and make the new prebuild faster.
"Compatible" means, among other things, that both the parent and the new prebuild have the exact same set of init
, before
and prebuild
tasks.
If a compatible parent prebuild is found, the new prebuild is started from the older prebuild, and simply runs the init
tasks again:
However, the effective configuration of the new incremental prebuild is copied over from the (parent) prebuild:
This works well for before
, prebuild
and init
tasks (because we check that they are identical when looking for a compatible parent), however, if the command
tasks (or anything else in the config) has changed since the parent prebuild was created, the new incremental prebuild will get an outdated config and GITPOD_TASKS
, and e.g. execute oudated command
tasks on startup (even if the .gitpod.yml
in the repo shows the newer tasks).
This happened to @mads-hartmann in #7456
Steps to reproduce
- Run a full Prebuild for a repository with both an
init
task and acommand
task, then wait for it to be successful - Enable Incremental Prebuilds for that repository
- Push a new commit to the same branch as in 1. that modifies the
command
task, and wait for this new commit to prebuild successfully - Open a workspace based on the new, incremental prebuild
Expected:
- The new
command
task should be run
Observed:
- The old
command
task is executed (or, if the.gitpod.yml
did not have acommand
in 1., nocommand
task is executed at all)
Workspace affected
No response
Expected behavior
No response
Example repository
No response
Anything else?
No response
Metadata
Metadata
Assignees
Type
Projects
Status