Check every GitHub release actually shipped a Docker image

I want an app that tells me whether every version we tagged on GitHub actually made it into Docker Hub as a published image. Our build pipeline sometimes fails quietly, and today we only find out when someone tries to pull a version that was never pushed. The app is a reconciliation board I open right after a release goes out, before we tell customers the version is available.

Pairings come first. Let me pair each GitHub repository with its Docker Hub repository once, and save those pairings in the app so they persist between visits. On first load, suggest matches automatically based on name similarity: pull candidate GitHub repositories with List Organization Repositories (and Get a Repository when I point at a specific one), pull candidate Docker Hub repositories with List Repositories in a Namespace, then propose the obvious pairs for me to confirm. Every pairing stays editable, so I can add, change or remove one at any time.

The main view is one row per pairing. On the left the row shows the most recent GitHub releases from List Releases, with the newest full release identified by Get Latest Release. On the right it shows the image tags Docker Hub actually has from List Repository Tags, including when each tag was last pushed. Reading a row left to right should immediately answer one question: did this version ship?

Give every row a clear status. Matched means each release has a corresponding image tag. Missing image means a release exists with no matching tag, and that is the one that bites us, so make it the loudest state and sort it to the top of the board. Untracked image means a tag exists with no release behind it. Lagging means the newest image is older than the newest release. Always show the specific versions involved in a status, not just a colour.

Be smart about naming, because false alarms will make me stop trusting this board. Treat v2.3.0 and 2.3.0 as the same version. Ignore architecture and variant suffixes such as -amd64, -arm64 and -alpine, and ignore a trailing build number, when deciding whether a release and a tag refer to the same version. Make this normalization rule explicit in the interface and let me configure it, so I can match how we actually name things. Exclude draft releases and prereleases from the missing image check by default, since those often skip publishing on purpose, with a setting to include them.

From a problem row I need two actions. Recheck re-runs the comparison live for that pairing, re-reading the tag list and confirming the exact expected tag with Check Repository Tag, so I can see whether a late build finally landed. File a build gap issue opens an issue on the paired GitHub repository with Create an Issue, and the issue body must carry the version, the exact tag name we expected to find, and what was actually found in the registry.

Add an Investigate this gap button on problem rows that starts a background agent. The agent reads the release itself with Get Release by Tag, pulls the full tag list with List Repository Tags, inspects a specific nearby tag with Read Repository Tag when that helps, studies how this repository normally names its tags, and reviews recent registry activity with List Audit Log Events for the namespace to see whether anything was pushed around the time of the release. From that it works out the likely reason the image is missing: the publish job never fired, the push failed, the image went out under a different tag name, or it was pushed and later deleted. One known cause worth checking for is that events triggered by the default GitHub token do not start a new workflow run, so a release created by automation can silently never fire the publish job.

The agent writes a short diagnosis back into the app, stored against that row so it is still there when I come back later, along with when it ran. After writing the diagnosis it offers to open the GitHub issue with that explanation already written up, so I can file a well explained issue in one click instead of retyping the findings.

I mainly open this right after a release goes out and before we tell customers a version is available. So the board should lead with the problem rows, and when everything matched it should make the all clear obvious at a glance.