Check upstream weekly, rebuild monthly and scan the published image

[mihow]

Summary

This image is only useful if it keeps up with its upstream sources and does not quietly collect known vulnerabilities. Until now, every version bump and every rebuild was a manual job that someone had to remember. This pull request automates the noticing and the preparation, and leaves the decision with a person.

Every Monday a workflow checks whether the server or client fork has published a new release, or whether the Go or Alpine base images have a newer patch. If so, it builds the image, runs the smoke test, and opens a pull request with an old/new table and links to the release notes. If nothing upstream has changed but the published image is more than 30 days old, it proposes a rebuild of the same release instead, so a rebuild happens about once a month. Every Tuesday, and after every publish, a second workflow scans the published image with Trivy and fails visibly when there are fixable critical or high findings. They also appear under the Security tab.

What stays manual: reviewing and merging the update pull request, which is still what publishes the image, updating the digest pins in the repositories that consume it, and deciding what to do about scan findings that upstream has not fixed yet.

Each build now also gets an immutable tag, <release>-r<revision>, so a rebuild of the same release never overwrites what someone has pinned.

Stacked on #1 (it reuses the smoke test added there). Please merge #1 first.

List of Changes

Change (what it does)	How	Notes
1. Every build gets a tag that never moves, such as RELEASE.2026-09-16T00-00-00Z-r1. The release tag and latest still move to the newest build.	IMAGE_REVISION in versions.env. The build workflow pushes all three tags, skips publishing if the revision tag already exists, and prints the pin line with the revision tag and digest.	README "Using the image" now recommends pinning -rN@sha256:….
2. Maintainers can see locally what an update would change.	scripts/check_upstream.py, standard-library Python. It reads the GitHub and Docker Hub APIs, dereferences annotated tags, reads the go directive from both go.mod files, and chooses Go and Alpine patches.	It stops with an error if a pinned release tag now points to a different commit.
3. New upstream releases and base-image patches turn into a ready-to-review pull request, tested before it is opened. Stale images get a monthly rebuild.	update.yml, weekly plus manual dispatch with force_rebuild and rebuild_if_older_than_days inputs. It builds linux/amd64 and runs test/smoke.sh, then opens a PR on update/versions with peter-evans/create-pull-request.	PRs opened with the default GITHUB_TOKEN do not run the normal PR build, which is why the build runs inline. An optional UPDATE_PR_TOKEN secret enables the normal checks too.
4. Known vulnerabilities in the published image fail a run and show up under the Security tab.	scan.yml, weekly, on demand, and after each successful publish from main. Trivy is pinned by commit (v0.36.0). It produces a SARIF upload plus a table that fails on CRITICAL or HIGH findings that have a fix.	Trivy reads the Go modules compiled into both binaries, which is the main signal for this image.
5. The README explains what runs when and what a person needs to do.	New "Keeping the image up to date" section. "Bumping versions" now points at the script.

Testing

• I ran the script locally against the current pins. It reports no change: there are no new releases since RELEASE.2026-09-16T00-00-00Z, and golang:1.27.1-alpine3.24 and alpine:3.24.2 are the newest patches. --force-rebuild proposes r2. A one-day age threshold proposes a rebuild, because the published tag is two days old. A moved tag, an unknown repository and a GitHub rate limit each exit non-zero with a clear message.
• Both workflows ran on this branch from a temporary push trigger. That commit was removed before review, because manual dispatch only works once a workflow file is on main.
  • The update workflow with a forced rebuild built the image, passed the smoke test, and opened Rebuild RELEASE.2026-09-16T00-00-00Z as r2 #2 ("Rebuild RELEASE.2026-09-16T00-00-00Z as r2"). As expected with the default token, Rebuild RELEASE.2026-09-16T00-00-00Z as r2 #2 shows no PR checks. Rebuild RELEASE.2026-09-16T00-00-00Z as r2 #2 targets this branch and only exists as a demonstration; it should be closed, not merged.
  • The scan of insectai/minio:latest passed with zero fixable CRITICAL or HIGH findings. Trivy detected Alpine 3.24.2 and both Go binaries. The SARIF upload appears in code scanning.
• I could not test the scan's "after every publish" trigger from a branch, because that trigger only fires from the default branch.
• actionlint reports no issues.

Worth discussing

The runtime stage of the Dockerfile only copies files onto the pinned RUNTIME_IMAGE. It has no package upgrade step. So a time-based rebuild with unchanged pins produces essentially the same image. The rebuilds that change anything are the ones triggered by a newer Go or Alpine patch, which the check detects independently of the image's age. If a rebuild should also pick up Alpine package fixes published between Alpine patch releases, the runtime stage needs apk upgrade. That would require QEMU emulation for the arm64 build. Alternatively, the 30-day rebuild could be dropped.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FA1nFdyB4WmWTw4syt89Yz