Tags give the ability to mark specific points in history as being important
-
v0.47.3
5faaab49 · ·v0.47.3 Docker image metadata and MCP Registry reruns now handle the failure modes that appeared in the Claudebox, Codexbox, and Pibox release jobs. - Docker Hub short descriptions now use Docker Hub's 100 UTF-8 byte limit, rather than a character count. Both single-image and multi-image jobs keep whole Unicode characters and reject invalid direct input before authentication. - MCP Registry publishing now reads the exact public version before OIDC login. A matching existing entry is a successful no-op. A different immutable entry fails. A duplicate response is accepted only after the Registry returns the exact expected metadata.
-
v0.47.2
a15f1a2b · ·v0.47.2 Replace third-party Docker Hub metadata, Grype scan, GitHub release, and disk cleanup actions with repository scripts. Docker Hub metadata and GitHub releases now fail on error. Scan, SARIF, and SBOM reporting remain nonblocking.
-
v0.47.1
7359d0c8 · ·v0.47.1 Docker image scans and Docker Hub metadata are reporting work, not release gates. Scanner outages, SARIF upload failures, and Docker Hub metadata outages remain visible without blocking an image push, GitHub Release, or caller jobs. Grype now uses anchore/scan-action v7.4.2.
-
v0.47.0
cca24377 · ·`docker-image-workflow.yml` publishes a downloadable SPDX SBOM for every pushed image as a workflow artifact, alongside the existing registry attestation. - New `sbom` and `sbom-multi` jobs generate an SPDX JSON SBOM from the pushed image with syft and upload one per image to the run's Actions artifacts. That artifact is a plain file reachable from the run page, unlike the `attestations` SBOM, which is attached to the image in the registry and needs registry tooling to read. - New `sbom_artifact` input (boolean, default `true`) toggles the artifact. It is independent of `attestations`; leaving both on produces the registry attestation and the downloadable file. Every current caller starts uploading SBOM artifacts on its next run until it sets `sbom_artifact: false`. - The jobs fetch syft as a pinned release binary (v1.51.0) and verify its tarball against a committed sha256 before running it, so a re-tagged or tampered release cannot execute on the runner. They add no third-party action; the GitHub-owned `actions/upload-artifact` publishes the SBOM. - The SBOM jobs are best-effort. They do not gate the release, and a generation or upload failure does not fail an otherwise-green run.
-
v0.46.0
445321cd · ·Reverts the `actions: read` grant added in v0.45.0 on `code-workflow.yml`'s `Code` job. A reusable-workflow job may only request permissions the calling job grants, so declaring `actions: read` made every caller that does not grant it an invalid workflow ("nested job 'code' is requesting actions: read, but is only allowed actions: none"). The SARIF upload works without it; on a private repo it leaves a non-fatal "Resource not accessible by integration" annotation, which is the accepted trade for not breaking callers. - The `Code` job requests only `contents: read` and `security-events: write` again. Callers do not need to grant `actions: read`. -
v0.45.0
b495a2d6 · ·`code-workflow.yml` grants `actions: read` on the `Code` job so the SARIF upload can attach its analysis to the workflow run without a "Resource not accessible by integration" annotation on private repositories. - The `Code` job now requests `actions: read` alongside `contents: read` and `security-events: write`. `github/codeql-action/upload-sarif` reads the workflow run to attach the code-scanning analysis; on a private repo that call needs `actions: read` or it 403s (non-fatal, but it leaves a warning annotation). Callers that upload SARIF from a private repo must also grant `actions: read` on the calling job.
-
v0.44.0
a3f69a99 · ·v0.44.0 issue-pull.yml now keeps confidential GitLab issues confidential when it relays them to public GitHub repositories. - A confidential source issue becomes a generic GitHub issue that links back to GitLab. It omits the source title, author, body, attachments, and reply contents. Source replies become generic bot comments with the same boundary. - If an already-relayed public source issue becomes confidential, the next run replaces its copied title/body and removes only this workflow's old bot replies. Human GitHub comments remain untouched.
-
v0.43.0
5a2aeb7b · ·v0.43.0 issue-pull.yml now mirrors source issue replies, not just issue state. - Imported issues and replies link to the source author's forge profile and to the original issue or reply. Existing mirrored content is updated in place. Hidden source markers keep the mapping stable without an external database, so repeated runs do not duplicate replies and interrupted runs resume safely. - Root-relative Markdown links, including GitLab `/uploads/...` attachments, now resolve against the source forge instead of GitHub after mirroring. - GitLab installations that restrict anonymous note reads now document the required `gitlab_token` with `api` scope. Issue and state synchronization still fall back to anonymous reads when available. - The README now documents every callable workflow, including the deprecated `make-checks.yml` caller, and its inputs/defaults match the workflow files.
-
-
-
-
-
-
v0.41.1
9ba7532c · ·reusable-github-workflows v0.41.1 — classify missing OpenClaw extensions as package errors
-
-
v0.40.1
c13b6568 · ·reusable-github-workflows v0.40.1 — README catch-up for v0.40.0 The imported-by outcome table still called a cross-check disagreement a hard error, which v0.40.0 replaced with a warning that renders 'unknown'. No row fails the job now, and the README says so. No workflow changed.
-
v0.40.0
eb790928 · ·reusable-github-workflows v0.40.0 — a bad importers page keeps the other badges The importers scrape-drift check exited 1, discarding coverage, version and license badges that had already rendered, and reddening the run. It now warns and renders 'unknown', matching what the fetch-failed and no-section cases already did. A drifted scrape still never prints a number.
-
v0.39.0
5c79e171 · ·reusable-github-workflows v0.39.0 — mirror/archive skip dependabot Dependabot runs get no repository secrets, so the mirror and archive jobs failed on every dependency bump. Every job in git-mirror.yml and archive.yml now skips when the actor is dependabot or the branch is a dependabot/ branch. This was the only remaining source of red on dependabot branches across the fleet; the test pipelines already pass there. Callers ride @master, so no caller edit is needed. Also corrects the README's max_new_items_per_day default from 10 to 5.
-
v0.38.4
a1a85029 · ·v0.38.4 — the README described the behaviour v0.38.3 replaced It still claimed a fetch failure or a missing section fails the job, one release after both became warnings that render 'unknown'. That paragraph is the one explaining why the badge can be trusted, so it is a bad place to be stale. Now a table of the three outcomes, plus why the third warns rather than fails. The release gate also asserts the README mentions 'unknown' when the workflow can render it — narrow on purpose, since a grep cannot police prose.
-
v0.38.3
1ca90fb9 · ·v0.38.3 — a zero-importer module is a state, not a failure The badge was written against one page shape and failed the whole badges job on the two others pkg.go.dev serves: a module nothing imports (which says 'No known importers' and gives no count) and one not yet crawled (no section at all). Because the job is all-or-nothing, that took coverage/version/license down too. Three outcomes now: a countable page renders the cross-checked number, no known importers renders 0, anything else renders 'unknown' in grey with a warning. Unknown is still never rendered as 0 — 'nothing imports this' and 'I could not tell' are different facts, and on a schedule the second printed as the first would overwrite a real count.