Skip to content

Adjust behavior of the new "Use Last Successful Prebuild" button #13945

@jankeromnes

Description

@jankeromnes

Is your feature request related to a problem? Please describe

Currently, the Use Last Successful Prebuild does this:

  • Start immediately, based on the last successful (and compatible) prebuild if one is available (i.e. based on an older commit, but it's not too old and the prebuild/init tasks were still the same)
  • Check out the latest commit of the requested branch

This causes the file system (e.g. any compiled artifacts) and the Git state to be slightly inconsistent -- any build you get can be slightly outdated.

Describe the behaviour you'd like

Instead, we have several options:

  1. Check out the older prebuild's original commit instead (simple, consistent, safe, not too surprising, but gives you an older checkout)
  2. Keep the current situation, i.e. load the older prebuild and check out the newer commit (simple, but can cause subtle/surprising issues in your workspace because your build no longer matches your Git state)
  3. Keep checking out the latest commit, and re-run all prebuild tasks again on workspace start (simple, hopefully fast thanks to incremental rebuilds, similar to what Incremental Prebuilds do today -- you get a recent fully-built state somewhat quickly)

From discussions we've had, customers seem to prefer the simplicity, safety and predictability of a.:

  • when launching from a previous prebuild they heavily emphasized that they just wanted the prebuild as-is. They didn’t want us to "get cute" and apply the most current git context or incrementally build. They wanted it to be very clear that they weren’t on the latest commit and wanted control over how, if and when they git pull’d or merged and rebased. They valued starting the workspace in a consistent and reliable state much more than having the latest commit.

Source: #13801 (comment)

Describe alternatives you've considered

Additional context

Metadata

Metadata

Assignees

No one assigned

    Labels

    team: webappIssue belongs to the WebApp team

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions