-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove 'warm' build steps from the template pipelines #1223
Conversation
|
- label: 🧖♀️ Warm Prod | ||
command: ':' | ||
key: warm-prod | ||
plugins: | ||
- *aws-sm | ||
- *private-npm | ||
- *docker-ecr-cache |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intent here was to bake the Docker build image and upload it to ECR once, rather than doing it twice on Test & Lint
and Build & Package
. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah in my team's repo we call the step build cache
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes of course that is still valid.
How about serialising the two steps, so it gets done only once - putting the shortest step first (which I think will be Build & Package
)? Or am I just wrong, and the warm step should remain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If both run at the same time there would be a chance we would get a cache miss right? The build cache step takes a little while
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By "serialise" I meant adding a dependency so that one step always runs after the other, so no chance of a cache miss
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not to mention it might fail while quicker while running both lint and build at the same time = faster feedback
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am investigating / gathering stats.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, as of the new build vCurrent strategy it looks like each step has to do the pull image step, so the question is whether that pull image step is quicker than running the commands on a single step?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice if we could somehow lock the ecr cache plugin to only run once per build at a time, then the first one that runs will build + the others will pull once it's finished pushing the image, no need for a warm step. Though I suppose this wouldn't actually save any time (the agent would just have to idle), right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This definitely helps in UI repos, given the UI images are typically alot bigger.
It takes on average 1 min 30 seconds to pull the image on one of our UI repos so moving all the commands to the single step has sped it up a bit
Per the discussion, this isn't the right change. Sam made a better change by updating the docker-ecr-cache plugin and using the new |
Remove 'warm' build steps from the template pipelines, because they don't have any effect in the new
vCurrent
build agent queues.These queues don't run steps on the same EC2 instance so there is warming, pre-launching or other time-saved, only an uneccessary cost to run these.
This change does not change Skuba functionality, nor the build-compile of Skuba iteself.