Repository navigation
semantic release can't push to master - #2358
Conversation
Reviewer's GuideUpdates semantic release to avoid direct master pushes by serializing runs, using an appropriately permissioned GitHub App token, and merging version changes through an automatically created pull request; adds a branch-aware build-version update helper. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 5 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="scripts/update_build_version.sh" line_range="21" />
<code_context>
+fi
+
+DOC_FILE="docs/v3/openapi.json docs/admin/openapi.json"
+sed -i 's|\("version": "\)[^"]*\("\)$|'"\1$VERSION\2|;" $DOC_FILE
+echo $VERSION >VERSION
+echo "$VERSION"
</code_context>
<issue_to_address>
**Tags execute build commands**
When a tag pusher creates a reachable tag containing sed metacharacters and a build invokes this script, `VERSION` comes from the latest reachable Git tag without validation, then is interpolated into a GNU `sed` program without escaping. A tag containing sed syntax can alter that program and use its `e` flag to execute a command on the runner.
Validate the tag-derived version against the expected version format and safely escape it before using it in the `sed` replacement.
</issue_to_address>
### Comment 2
<location path=".github/workflows/semantic-release.yml" line_range="9-11" />
<code_context>
- master
+# one job at a time, concurrent jobs will wait
+concurrency:
+ group: version-inc
+ cancel-in-progress: false
+
jobs:
</code_context>
<issue_to_address>
**Queued release requests are lost**
When multiple master pushes arrive while a run is active and another run is pending, gitHub keeps only one pending run in the concurrency group, so a newer push replaces the queued run. The workflow examines only the surviving run’s latest commit, leaving release directives or automatic version commits on displaced pushes unprocessed and their version increments or tags lost.
Ensure every master push is processed instead of relying on a concurrency group that retains only one pending run.
Also at `.github/workflows/semantic-release.yml:48`.
</issue_to_address>
### Comment 3
<location path=".github/workflows/semantic-release.yml" line_range="65" />
<code_context>
+ VERSION_NEXT=$(./scripts/increment_version.sh ${VERSION} ${RELEASE_TYPE})
+
+ BRANCH="version/${VERSION_NEXT}"
+ BODY=$(printf '%s\n\n%s\n' "${VERSION_NEXT}" "[automatic version update]")
+ git checkout -B "${BRANCH}"
+
</code_context>
<issue_to_address>
**Version PR retries fail**
When another master push arrives before the version PR merges, or the workflow is retried after pushing the branch but before completing PR setup, `VERSION_NEXT` stays the same, and `git checkout -B` creates a different commit on the existing `version/${VERSION_NEXT}` branch. The non-force push is rejected, so the workflow exits without creating or updating the PR.
Reuse or update the existing version branch and PR on subsequent runs instead of pushing a divergent branch.
Also at `.github/workflows/semantic-release.yml:72-73`.
</issue_to_address>
### Comment 4
<location path="scripts/update_build_version.sh" line_range="12-13" />
<code_context>
branches:
- master
+# one job at a time, concurrent jobs will wait
+concurrency:
</code_context>
<issue_to_address>
**Master builds get development versions**
When the script runs on master from a detached checkout, `git rev-parse --abbrev-ref HEAD` returns `HEAD`, so the master check fails and `update_build_version.sh` appends a commit hash instead of incrementing the release version. Master builds receive development-style versions.
Determine whether the checkout is for master without relying on the current branch name in a detached checkout.
</issue_to_address>
### Comment 5
<location path="scripts/update_build_version.sh" line_range="14" />
<code_context>
+BRANCH=$(git rev-parse --abbrev-ref HEAD)
+
+if [[ "$BRANCH" == "master" ]]; then
+ VERSION=$("${SCRIPT_DIR}/increment_version.sh" "$VERSION" "$1")
+else
+ COMMIT=$(git rev-parse --short=7 HEAD)
</code_context>
<issue_to_address>
**Version update aborts without an argument**
When the script runs on master without a release-type argument, with `set -u`, expanding `$1` in `update_build_version.sh` raises an unbound-variable error, so the increment script does not run and the version is not updated.
Pass a default patch release type when `$1` is omitted.
</issue_to_address>Sourcery assessment
Needs a human reviewer. 5 findings to address first, and this grants the release workflow write access to repository contents and pull requests, then uses that authority to create, auto-merge, and tag release changes. If the permission or automation is wrong, it can immediately modify the protected branch or repository history; reverting the workflow cannot undo a merge or tag already created.
Blocking findings: scripts/update_build_version.sh:21, .github/workflows/semantic-release.yml:11, .github/workflows/semantic-release.yml:65, scripts/update_build_version.sh:13, scripts/update_build_version.sh:14
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #2358 +/- ##
==========================================
+ Coverage 58.92% 58.95% +0.03%
==========================================
Files 150 150
Lines 9626 9626
==========================================
+ Hits 5672 5675 +3
+ Misses 3355 3352 -3
Partials 599 599
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Secure Coding Practices Checklist GitHub Link
Secure Coding Checklist
Summary by Sourcery
Make semantic release reliably publish version updates to master while preventing concurrent or duplicate release operations.
Bug Fixes:
Enhancements:
CI: