Skip to content

Gate release image and docs publish workflows via release environment#69465

Open
potiuk wants to merge 1 commit into
apache:mainfrom
potiuk:gate-release-workflows-with-environment
Open

Gate release image and docs publish workflows via release environment#69465
potiuk wants to merge 1 commit into
apache:mainfrom
potiuk:gate-release-workflows-with-environment

Conversation

@potiuk

@potiuk potiuk commented Jul 6, 2026

Copy link
Copy Markdown
Member

Manual, release-process workflows restrict who may trigger them by duplicating a hardcoded release-manager allowlist as an if: contains(fromJSON('[...]'), github.event.sender.login) on the first job. The list drifts across files, only gates the actor (not the secrets consumed), and is easy to get wrong.

This replaces those allowlists in the prod image release (release_dockerhub_image.yml) and docs-to-S3 publish (publish-docs-to-s3.yml) workflows with a dedicated, RM-only release deployment environment referenced by the entry job. Access control and secret scoping then live in one place.

Draft because the release environment must first be created by ASF INFRA with release managers as required reviewers. Until it exists with protection rules, a job referencing it runs ungated — so this must not merge before INFRA sets it up (the issue's open question is exactly what .asf.yaml can express here).

Deliberately not in this PR (tracked in #69460 / the follow-up):

  • update-constraints-on-push.yml — its manual dispatch is added in Allow manual triggering of constraints refresh workflow #69457; convert once that merges.
  • registry-backfill.yml / registry-build.yml — their entry job is a reusable-workflow call, which can't carry environment:; needs a small gating-job restructure.
  • release_single_dockerhub_image.yml DOCKERHUB secret scoping.
  • CI-time secret workflows + re-enabling zizmor secrets-outside-env.

Part of #69460.


Was generative AI tooling used to co-author this PR?
  • Yes — Claude Code (Opus 4.8)

Generated-by: Claude Code (Opus 4.8) following the guidelines

Manual, release-process workflows restrict who may trigger them by
duplicating a hardcoded release-manager allowlist as an `if:` condition
on the first job. The list drifts across files, only gates the actor
(not the secrets the workflow consumes), and is easy to get wrong.

Replace those allowlists in the prod image release and docs-to-S3
publish workflows with a dedicated, RM-only `release` deployment
environment referenced by the entry job. Access control and secret
scoping then live in one place instead of copy-pasted handle lists.

The `release` environment must be created by ASF INFRA with release
managers as required reviewers, so this stays a draft until that is in
place. Converting the remaining release/registry workflows and the
CI-time secret consumers is tracked separately.
@potiuk potiuk marked this pull request as ready for review July 8, 2026 12:09

@bugraoz93 bugraoz93 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great improvement! Should we take any actions as RMs?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants