yosifkit
commented
4 weeks ago The current builds of node could work like we have in our repos: https://github.com/docker-library/golang/#:~:text=images%20repository.-,Build,-Status. But we are actively in the process of migrating to a new way of building that is no longer repo job based and so those links would be misleading (or broken) once we move node to the new build system.
The new build system is a bit more complex as there isn't one view of a repo anymore; it is all just architecture based (and complicated by some arches being a Github Actions yml that is triggered by Jenkins). Feel free to explore here: https://doi-janky.infosiftr.net/job/wip/job/new/; it is still a bit in flux.
Rough flow of jobs:
metacalculates what can and needs to buildtrigger-[arch]jobs use that data to make a queue of things to build for that arch and then triggers and waits forbuild-[arch]to build a single image (thus processing its queue)- images are not pushed to
[arch]/[repo]at this stage but to an intermediate staging repo (not really for public consumption, images are tagged by a "build id" and not discoverable by original repo name)
- images are not pushed to
deploy-[arch]coordinates pushing the built images from that staging repo to the arch+repo specific namespace on Docker Hub (amd64/[repo], e.g. https://hub.docker.com/r/amd64/node/)- (unchanged from "old" build system) our
put-sharedjobs (per repo, e.g.node) brings together items pushed to the arch specific namespaces to create the "image index" inlibrary/[repo](e.g. https://hub.docker.com/_/node)
nschonni
Problem
We often have people ask when why images or architectures are missing
Solution
Add a build badge or badges to the Official Images jenkins status of the Node.js jobs
Alternatives to Consider
Maybe having the build badges on the README would be confusing, because that date might end up on the Docker Hub, and maybe pointing to the links from the Issue Template picker might work instead.
/cc @yosifkit @LaurentGoderre