Repository navigation
Stop a production release when the publish environment has no approval rule - #304
Merged
Merged
Conversation
…l rule GitHub creates an environment that a job names on first use, with no required reviewers and no deployment rules. For a production release the plan job now reads the environment the publish job will run in and stops the release unless it requires a reviewer and limits deployments to selected branches and tags. A maven-release that has its secrets but no approval rule cannot sign and upload unattended, and a missing one stops here instead of after the build. A protected-branches-only policy does not count: releases run on tags, which it would refuse only after the build.
Dependency security scanScanned 24 resolved dependencies, failing on HIGH and above. Result: passed |
Code coverage
Least covered classes (10 shown)
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
For a production release, the plan job now reads the GitHub environment the publish job runs in (
maven-release) and stops the release unless it:Why
GitHub creates an environment a job names on first use, with no protection rules.
maven-releasedoes not exist yet (onlymaven-testdoes), so the first production run creates it unprotected. Once the signing and upload secrets are added to an environment like that, a release signs and uploads with no approval. A protected-branches-only policy is also rejected early: releases run on tags, which that policy refuses only after the build.Dry runs (
target: test) skip the step, so they are not blocked.Verification
environment_problemstests and a CLI test ofcheck-environment.maven-testpasses;maven-releaseis not found, so the step fails with a clear annotation.Not covered (choices for the owner)
GPG_KEY,GPG_KEY_IDandGPG_KEY_PASSWORD, used by master'spublishing.ymltogether withMAVEN_USERNAMEandMAVEN_PASSWORD. Any workflow in this repository can read those without an approval, and neither the environment rules nor this check can stop that. Oncepublishing.ymlis gone from master (the next release merge), delete the five repository secrets so the key lives only inmaven-release.can_admins_bypass),prevent_self_review, and the actual tag patterns are not checked.maven-testalready hasprevent_self_reviewon.🤖 Generated with Claude Code