Conversation
Reviewer's GuideAdds a new tag-triggered release workflow that reuses the existing Linux and Windows build workflows via workflow_call inputs, and generalizes those build workflows to support both nightly scheduled builds and tagged point releases with appropriate version identifiers and artifact overwrite behavior. File-Level Changes
Assessment against linked issues
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 3 issues, and left some high level feedback:
- Consider enforcing or validating that the tag name (used as
identifier) is in a normalized format (e.g., stripping a leadingvor disallowing other characters) before using it in artifact filenames so you don’t end up with unexpected or inconsistent binary names. - In the release workflow, you might want to add a check that the
pyproject.tomlversion matches the semantic tag being built, and fail early if they diverge, to avoid publishing artifacts whose internal version doesn’t match the release tag.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider enforcing or validating that the tag name (used as `identifier`) is in a normalized format (e.g., stripping a leading `v` or disallowing other characters) before using it in artifact filenames so you don’t end up with unexpected or inconsistent binary names.
- In the release workflow, you might want to add a check that the `pyproject.toml` version matches the semantic tag being built, and fail early if they diverge, to avoid publishing artifacts whose internal version doesn’t match the release tag.
## Individual Comments
### Comment 1
<location path=".github/workflows/mswn.yml" line_range="67" />
<code_context>
retention-days: 2
compression-level: 9
- overwrite: true
+ overwrite: ${{ github.event_name == 'schedule' }}
</code_context>
<issue_to_address>
**issue (bug_risk):** Conditionally disabling artifact overwrites may cause reruns of non-scheduled runs to fail
Tying `overwrite` to `github.event_name == 'schedule'` means `workflow_call` runs (e.g., release for an existing tag) will re-upload an artifact name that already exists with `overwrite: false`, causing `actions/upload-artifact` to fail the job. If reruns for the same tag are expected, keep `overwrite: true` for all events or base the condition on a more stable identifier (e.g., a unique run attempt) instead of the event type.
</issue_to_address>
### Comment 2
<location path=".github/workflows/gnul.yml" line_range="66" />
<code_context>
retention-days: 2
compression-level: 9
- overwrite: true
+ overwrite: ${{ github.event_name == 'schedule' }}
</code_context>
<issue_to_address>
**issue (bug_risk):** Same overwrite condition issue for GNU/Linux artifacts as for Windows
Here we’ll hit the same rerun issue as in the Windows workflow: for release runs triggered via `workflow_call` (e.g. `rlse.yml`), re-running a workflow for the same tag will try to upload `gi-loadouts.gnul` with `overwrite: false`, causing the upload to fail. Please adjust the condition so release reruns can safely overwrite artifacts, and keep the behavior consistent between the workflows.
</issue_to_address>
### Comment 3
<location path=".github/workflows/rlse.yml" line_range="44-49" />
<code_context>
+ - name: Build the source distribution and wheel
+ run: python -m build
+
+ - name: Upload the distribution packages to the GitHub Artifacts
+ uses: actions/upload-artifact@v7
+ with:
+ name: gi-loadouts.pypi
+ path: dist/*
+ compression-level: 9
+
+ ci-rlse:
</code_context>
<issue_to_address>
**suggestion:** PyPI artifact uploads may fail on reruns because overwrite is not enabled
Because this artifact name is constant and `actions/upload-artifact` defaults to `overwrite: false`, reruns for the same tag may fail when the artifact already exists. To align with the binary workflows and keep reruns reliable, set `overwrite: true` on this step.
```suggestion
- name: Upload the distribution packages to the GitHub Artifacts
uses: actions/upload-artifact@v7
with:
name: gi-loadouts.pypi
path: dist/*
compression-level: 9
overwrite: true
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| retention-days: 2 | ||
| compression-level: 9 | ||
| overwrite: true | ||
| overwrite: ${{ github.event_name == 'schedule' }} |
There was a problem hiding this comment.
issue (bug_risk): Conditionally disabling artifact overwrites may cause reruns of non-scheduled runs to fail
Tying overwrite to github.event_name == 'schedule' means workflow_call runs (e.g., release for an existing tag) will re-upload an artifact name that already exists with overwrite: false, causing actions/upload-artifact to fail the job. If reruns for the same tag are expected, keep overwrite: true for all events or base the condition on a more stable identifier (e.g., a unique run attempt) instead of the event type.
| retention-days: 2 | ||
| compression-level: 9 | ||
| overwrite: true | ||
| overwrite: ${{ github.event_name == 'schedule' }} |
There was a problem hiding this comment.
issue (bug_risk): Same overwrite condition issue for GNU/Linux artifacts as for Windows
Here we’ll hit the same rerun issue as in the Windows workflow: for release runs triggered via workflow_call (e.g. rlse.yml), re-running a workflow for the same tag will try to upload gi-loadouts.gnul with overwrite: false, causing the upload to fail. Please adjust the condition so release reruns can safely overwrite artifacts, and keep the behavior consistent between the workflows.
Comment on lines
+44
to
+49
| - name: Upload the distribution packages to the GitHub Artifacts | ||
| uses: actions/upload-artifact@v7 | ||
| with: | ||
| name: gi-loadouts.pypi | ||
| path: dist/* | ||
| compression-level: 9 |
There was a problem hiding this comment.
suggestion: PyPI artifact uploads may fail on reruns because overwrite is not enabled
Because this artifact name is constant and actions/upload-artifact defaults to overwrite: false, reruns for the same tag may fail when the artifact already exists. To align with the binary workflows and keep reruns reliable, set overwrite: true on this step.
Suggested change
| - name: Upload the distribution packages to the GitHub Artifacts | |
| uses: actions/upload-artifact@v7 | |
| with: | |
| name: gi-loadouts.pypi | |
| path: dist/* | |
| compression-level: 9 | |
| - name: Upload the distribution packages to the GitHub Artifacts | |
| uses: actions/upload-artifact@v7 | |
| with: | |
| name: gi-loadouts.pypi | |
| path: dist/* | |
| compression-level: 9 | |
| overwrite: true |
Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com>
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
1 participant
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.
Create separate GitHub Action for generating point releases
Fixes #546
Summary by Sourcery
Introduce a dedicated release workflow that reuses the existing platform build jobs and automates tagged point releases.
Build: