ci(scripts): stop the visibility gate from blocking every release - #2304
Conversation
The first release run after the gate landed failed: Docker Hub answers 403 on PATCH /repositories/<repo>/ because DOCKERHUB_IMAGE_PUSH_TOKEN can push tags but not change repository settings, so the job could neither publish the three private images nor let the pipeline run. Make the gate report instead of block until the credential exists: a strict input (false from the release pipeline, true on manual dispatch) decides whether a failure fails the job, the step emits a warning and a job summary naming every image left private, and the workflow now prefers DOCKERHUB_REPO_ADMIN_TOKEN, an organization access token with repo:admin, falling back to the push token. Flipping strict to true once that secret exists turns this back into a real gate. Co-authored-by: Codesmith <codesmith-bot@users.noreply.github.com>
|
| Library | Current | Latest | Status |
|---|---|---|---|
lib-auth/v3 |
v3.3.0 |
v3.3.0 |
✅ Current |
lib-commons/v6 |
v6.7.0 |
v6.7.0 |
✅ Current |
lib-observability/v2 |
v2.1.1 |
v2.1.1 |
✅ Current |
lib-service-discovery |
v1.1.0 |
v1.1.0 |
✅ Current |
lib-streaming/v2 |
v2.0.0 |
skipped | ⏭️ Skipped — ignore file, expires 2026-08-17 · why? |
✅ 4 current · 🔴 0 needs update · 🕒 0 in grace · ⏭️ 1 skipped ·
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe pull request adds configurable Docker Hub visibility enforcement, repository-admin token support, and unresolved-repository reporting. The release workflow runs the visibility check in non-strict mode. ChangesDocker Hub visibility
Sequence Diagram(s)sequenceDiagram
participant ReleaseWorkflow
participant DockerHubVisibilityWorkflow
participant EnsureDockerHubPublic
participant DockerHub
ReleaseWorkflow->>DockerHubVisibilityWorkflow: Start pre-release check with strict=false
DockerHubVisibilityWorkflow->>EnsureDockerHubPublic: Run with repository-admin token
EnsureDockerHubPublic->>DockerHub: Create or update repository visibility
DockerHub-->>EnsureDockerHubPublic: Return operation result
EnsureDockerHubPublic-->>DockerHubVisibilityWorkflow: Return status and unresolved repositories
DockerHubVisibilityWorkflow-->>ReleaseWorkflow: Continue release or report warning
Possibly related PRs
✨ Finishing Touches✨ Simplify code
Comment |
🔍 PR Validation Summary✅ PR Mergeable — no blocking failures
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/dockerhub-visibility.yml:
- Around line 63-67: Update the “Warn that images are not public” step condition
to use the explicit non-cancelled check together with steps.visibility.outcome
== 'failure', so it runs after strict failures while still appearing for masked
non-strict failures.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: f201f8bb-d7ba-445c-af6b-cc88c388c73a
📒 Files selected for processing (3)
.github/workflows/dockerhub-visibility.yml.github/workflows/release.ymlscripts/ensure-dockerhub-public.sh
Co-authored-by: Codesmith <codesmith-bot@users.noreply.github.com>
Ungoliant Release Diff — ExecutedThe full chaos/fuzz analysis flow ran for this release.
|
Description
The first Release run after #2303 merged failed and skipped
pipeline, so releases ondevelopare blocked right now:Login and the reads worked (it correctly saw
midaz-ledgerpublic and the other three private), so this is not a bug in the check:DOCKERHUB_IMAGE_PUSH_TOKENcan push tags but cannot change repository settings, and Docker Hub answers 403 on thePATCH. A gate that can neither publish the images nor let the pipeline run is strictly worse than no gate, so it should report until the credential exists.strictdecides whether a failure is fatal,falsefrom the release pipeline andtrueon manual dispatch:The rest follows from that: the workflow prefers a new optional
DOCKERHUB_REPO_ADMIN_TOKEN(an organization access token withrepo:admin) and falls back to the push token, a failed check raises a workflow warning, and the script names each unfixed image in the job summary with the reason, calling a 403 what it is rather than a generic HTTP error.Follow-up to actually publish the images
This PR unblocks releases; it does not make the three v4 images public, because no credential in CI can. Someone with owner access has to either flip
midaz-tracer,midaz-tracer-migrationsandmidaz-ledger-migrationsin the Docker Hub UI, or create an organization access token withrepo:admin, store it asDOCKERHUB_REPO_ADMIN_TOKEN, and dispatch Docker Hub Visibility fromdevelop. Once that secret exists,strict: trueinrelease.ymlturns this back into a hard gate so no future image ships private.Type of Change
ci: CI pipeline or workflow changesBreaking Changes
None.
Testing
actionlintandshellcheckclean. The script was re-run against a stubbed Docker Hub reproducing the exact production failure (PATCH→ 403 on two images, success on a third, one already public): it reports each 403 as a missingrepo:admin, writes the summary above, and exits 1; the all-public path exits 0 and writes no summary.Related Issues
Follow-up to #2303. Unblocks the midaz v4 Helm work in LerianStudio/helm#1838.