Avoid making users wait for long prebuilds

[shaal]

Is your feature request related to a problem? Please describe

Prebuild on DrupalPod can take 5-20 minutes (assuming it does not fail).
The entire time the prebuild is running, no new workspace can be opened for project work.

Describe the solution you'd like

Use the latest successful prebuild when opening a workspace for a repository.
To start working on a project, users shouldn't wait for a prebuild to complete. Rather, users should open workspaces which have been successfully built by the (previous) latest prebuild.

Describe alternatives you've considered

Additional context

A project like Drupal (which has thousands of contributors worldwide) would be very frustrating if all contributors had to wait after each commit to the repo. Every day, the project gets multiple commits in multiple supported versions (branches).

[Decipher]

I use Gitflow as my primary workflow, it would be nice if it were possible to have a "release branch" prebuild usable by the "main branch" after it is merged, and before the new prebuild has been built.

Alternatively, tag based or commit hash based prebuilds could be used when dealing with multi-branch workflows.

[iQQBot]

Currently you can use skip prebuild by use default image

Prebuild contains everything of workspace include git repo, so if use previous succeed prebuild you were get a old git repo...

[shaal]

Skipping prebuild is not solving the problem at all, because the goal is to get to 'ready to code' state.

It's fine to use older prebuild that was completed successfully. It is similar to working on a branch for a few days while main development branch got further ahead.

[AlexTugarev]

It's fine to use older prebuild that was completed successfully.

@shaal, that's not a general rule. If you open a workspace for a commit A it's just an exception that you'd be happy to get a prebuilt workspace for commit B.

[shaal]

@AlexTugarev I couldn't understand your comment, can you clarify what you meant?

Compared to working with a local environment, a commit can be a Readme file, or a php file, that doesn't change the environment, and by running git checkout main I can get the latest files in the repo. But when there's a lengthy prebuild that takes 15 minutes, it stops everyone from opening new workspaces that whole time.

[AlexTugarev]

@shaal that only applies to interpreted code and static resources. in case a transpiler/compiler is part of the build, it's likely needed to be called again, otherwise the editor and e.g. preview of your app are potentially not in sync.

[shaal]

@AlexTugarev I agree.

But we need to make improvements to the existing process.
It depends which file was change, and how does it affect everyone that waiting to open a new workspace.
Compared to local environment experience, perhaps a very short process of compile needs to run, as oppose to time of full recompile/setup of a clean environment from scratch.

[shaal]

This might be similar to what @Decipher suggested -
In the PR process, as each commit is pushed to that branch, a prebuild is run (while main remains intact).

I would love to be able to complete a prebuild in the PR, prior to merging (and testing) to main and then when tagging a release, not needing a new prebuild because it already ran on the commit itself.

[jldec]

We are investigating possible approaches to this issue. I have renamed it to clarify the desired outcome.

[chuck-confluent]

Maybe it would look like:

1. User launches a workspace and sees there's a prebuild in progress.
2. Text says "Do you want to launch from the previous snapshot instead of waiting for this prebuild? Note that your workspace would not reflect the latest changes. <launch button>"

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[shaal]

Please add meta: never stale label to this issue.

[iQQBot]

You can try increase prebuild , it can enabled in project settings

[shaal]

I tried that. For some reason, when using in DrupalPod, it always re-download Docker images (by ddev).
cc:@janx

[svenefftinge]

This is now available in project settings.