Org-level Woodpecker secrets + standardized token naming #11
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Move gitea_clone_token, registry_token, attic_token from per-repo secrets to org-level secrets for oleks/*; standardize on REGISTRY_TOKEN as the canonical env name. Includes fixing the latent bug in fastuuid-s390x and onnxruntime-s390x (declare CI_REGISTRY_TOKEN but never remap to REGISTRY_TOKEN before publish). If existing secret values can't be recovered (Woodpecker secrets are write-only), mint fresh Gitea tokens with equivalent scopes.
See Spec/Modern-CI-Target for requirements.
Verified & closing. Org-level Woodpecker secrets + REGISTRY_TOKEN standardization done and proven.
Delivered:
gitea_clone_token,registry_token,attic_token(freshly minted; attic token from sops).REGISTRY_TOKENas the canonical env name.8e94a82, onnxruntime-s390x0fe9cf9(code-correct; note these s390x repos are now no-build per the 2026-07-08 hardware-unavailable directive, so they won't run — the fix stands as correct code / reference).Verification (non-s390x, per the no-s390x-build directive): the
ci-fleet-publishplugin build (v1.0.3, in the oleks org) resolvesREGISTRY_TOKEN: from_secret: registry_tokenin.woodpecker/build-amd64.yaml,build-arm64.yaml, andmanifest.yaml.oleks/ci-scriptshas no repo-level secrets, so thatregistry_tokenresolved to the org-level secret. That build went fully green and pushed the multi-arch image togit.oleks.space/oleks/ci-fleet-publish:v1.0.3/:v1/:latest— proving the orgregistry_tokenworks end-to-end.(The originally-planned fastuuid-s390x green-run verification was cancelled and its tag deleted per the s390x no-build directive; the plugin-build evidence above supersedes it.)