search

jenkins-infra / packer-images

This repository hosts the packer definitions for the Jenkins Infrastructure
MIT License
19 stars 18 forks source link

Enable Auto-Release for these images #283

Open dduportal opened 2 years ago

dduportal commented 2 years ago

Problem: this build takes almost 1 hour to complete. When releasing a new version, we have to build at least 2 times: once on the main branch (which has the build_type variables set to the value staging) triggered by a code push (usually a PR merge) and another time for the release, triggered by the tag creation when publishing the draft "GitHub Release".

We would want to avoid deploy often, and as soon as possible:

timja commented 2 years ago

Isn't it 3?

PR build as well?

dduportal commented 2 years ago

Isn't it 3?

PR build as well?

I exclude this cases for 2 reasons:

timja commented 2 years ago

Trust of a PR build and trust of a "main branch" build are different and for building base OS image like we do in this repo, PR are zero trust

They should be trusted at the point of merge though? i.e the last build?

It's always something we've struggled a bit with, we waste a lot of time rebuilding something that was fine at the point of merge. Not something we've solved at work but something to think about anyway.

You could have multiple PR builds between releases (at least today)

Assuming an up-to-date merge, would be a promotion case on master, if there was an up-to-date build that passed.

dduportal commented 2 years ago

Trust of a PR build and trust of a "main branch" build are different and for building base OS image like we do in this repo, PR are zero trust

They should be trusted at the point of merge though? i.e the last build?

It's always something we've struggled a bit with, we waste a lot of time rebuilding something that was fine at the point of merge. Not something we've solved at work but something to think about anyway.

Yep same. With "simple" Docker images or binaries on tiny projects, no problem.

But here, not only we have VM images (heavy artifacts, not always downloadable so hard to stage: case of AMIs), but also cross-regions replications as part of the build, and a really heterogeneous set of "artifacts publication" (Azure, AWS and now Docker images). That's why the "optimisation" is scoped to a single trust area: main branch and release tags.

You could have multiple PR builds between releases (at least today)

Assuming an up-to-date merge, would be a promotion case on master, if there was an up-to-date build that passed.

yep, assuming is the word that perfectly summarize the problem we had and have on this particular repository :D But it is the only repository of this platform that is that much specific: you are 100% correct on your hypothesis for all the rest of the platform