You rebased my commit and canceled the web-build job half-way through the first time, but we got there in the end. ;-)
If you have concerns about your change affecting other images, tag me on an MR, and I can run docker build somewhere.
I think we’re probably fine for now. But since we aren’t referencing specific image revisions in our jobs, or keeping track of specific builds, it would probably be a good idea in the future to always update the latest images when merging docker-related MRs.
Sorry. I occasionally cancel the jobs after rebase, but only if they are at the first stage (clang-format&co). Perhaps either my brain or gitlab interface glitched.
Switching to tagged images might not be a bad idea, but we would need some automation to help keep them updated and purge old containers. I don’t see that happening soon.
In the meantime, agree, rebuilding all the affected containers is nice.
That said, there is also a problem of build reproducibility. Recently, LLVM took down some of their old apt repos, so we could not rebuild one of the images. On a (usually) more benign side, there are OS packages updates. But besides those rare issues, rebuilding rarely involves more than some CPU-hours, so we should do that.
Switching to tagged images might not be a bad idea, but we would need some automation to help keep them updated and purge old containers. I don’t see that happening soon.
We’ve had discussions along those lines at least twice in previous years. The recommendation to test exclusively against known references has been repeatedly rejected. But consensus eventually allowed that it was pragmatic to tag images by release year when the test environment was necessarily stable, to allow the latest tag to adjust as required by ongoing development.
It isn’t too hard to see these tags in the container registry, but there is does not seem to be a pressing need to purge them, either.
That said, there is also a problem of build reproducibility.
That is sort of my point. We aren’t strongly pinning versions of images or versions of software within images.
For images that need to keep working indefinitely, we need to tag them and stop updating them.
For images that are evolving as latest, the only practical thing we can do to avoid ambiguity is to keep them up-to-date, self-consistent, and consistent with the source recipe. When we depend on latest, we need to be committed to keeping everything working with latest. (If we are unwilling or unable to do that (or if it is inappropriate for some reason), then we need to do better than just using an arbitrary outdated untagged image.)
Hah. Don’t worry. You were just trying to be helpful, and I hadn’t told anyone which job I was watching.
I’ve noticed that it is easy to end up with an un-updated web view of the brand new pipeline, and the web interface happily accepts your “cancel pipeline” click to only cancel the jobs that are still running. I often click on the pipeline to get a new, fresh view, and then I might just cancel a few jobs to cause the dependent jobs to get skipped.