-
Notifications
You must be signed in to change notification settings - Fork 11
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
Experiment: run base image builds in parallel #120
Conversation
Docker image tag(s) pushed:
Labels added to images:
|
The cost is not a problem, I am happy to bank roll this for now. Thank you for thoroughly investigating all the options! Just one quick question: how would you suggest we manage the tags on Docker Hub? It seems like soon we'd need some kind of policy for cleaning old tags without deleting useful cache accidentally: I can think of someone renaming a couple of build stages for readability without thinking that it would cause cache rebuilding and stale images on Docker Hub. |
Then could you please signup at buildjet.com and add this repository to your account? I'll then remove it from mine. It's not urgent, though.
Hm…I wouldn't care much about cleaning up old tags: that's an open source repo and DockerHub provides unlimited storage for such repos, right? People who use the images would normally only use ones that are either versioned (v1.4, etc.) or belong to their PRs. You might want to put a bit of more info to the overview page, listing all useful tags (for instance, see how Python lists tags in their overview page).
Even if someone does that to the dockerfile, it's not a big deal. We'll lose cache and the build would take +10 extra minutes once (before new caches are populated) and that's it. It's also an easy issue to notice when reviewing a pull request. Again, I wouldn't be worried much about this. |
Done 🤞
Cool.
I listed one tag (v1.4) but I'll need to figure out how to do it more systematically and link to Dockerfiles later.
👍 I am happy to merge this PR once I can verify that an image built like this is fully functional - but for that I need to deal with #119. |
There are 2 changes to the base image build process in this PR:
We can adopt just item 1, or both 1+2, or alternatively we could deploy a GitHub Actions runner on the free Oracle Cloud ARM64 machine, but I'm not sure how much of a speedup that would be. That would be an alternative to the item 2.