refactor: support for build concurrency #309
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
shreddedbacon
force-pushed
the
build-concurrency
branch
from
ccf1413 to
6a00878
Compare
shreddedbacon
force-pushed
the
build-concurrency
branch
from
8082c89 to
e83cd8e
Compare
bomoko
approved these changes
Jul 31, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
This refactors the build QoS system to support more builds to run once they have completed the more intensive docker build and push phases of the build process.
This can give the impression of faster builds when there are a lot of builds currently processing. What this allows is for once a build has pushed the images to the registry, it transitions from being a docker build phase to a pre/post rollout phase. This effectively frees up the docker build slot for a new build to come in, up until the total maximum number of builds is reached. What this number is depends on the operator of the cluster and how they determine what they see as an upper limit. A starting point would be double that of the QoS limit, where the default is the same as the QoS limit (effectively no change from current behavior).
Requires changes in uselagoon/build-deploy-tool#390 to properly support this feature (now merged).