ci: record releases in Linear, pin and update workflow actions - #300
Conversation
A linear-release job records each PyPI release, gated on a successful publish. It is a separate job because the publish job has no checkout and holds only id-token: write for Trusted Publishing. The release is identified by the tag. publish-to-pypi.yml is SHA-pinned. pypa/gh-action-pypi-publish was on the release/v1 branch ref, which moves on every push, next to the PyPI OIDC token. Other workflows stay on tags. Bumped checkout v7, setup-python v7, cache v6, upload-artifact v7, download-artifact v8. Slack action v4.0.0 needs webhook-type from v2 on. The e2e notification now passes the job's own webhook secret rather than the default one. Codecov v3 disabled: its Node runtime is gone from the runners. Coverage is still computed and printed. Dependabot now covers github-actions alongside pip.
zanjonke
left a comment
zanjonke
left a comment
There was a problem hiding this comment.
Overall looks good. Left some minor comments and questions.
| uses: linear/linear-release-action@0a25abab892a91062ebf42260dbb2ce6277aa205 # v0.16.0 | ||
| with: | ||
| access_key: ${{ secrets.LINEAR_ACCESS_KEY }} | ||
| version: ${{ github.ref_name }} |
There was a problem hiding this comment.
If this step fails nothing will get logged anywhere. For the publish-to-pypi we have a dedicated SLACK webhook.
|
|
||
| steps: | ||
| - uses: actions/checkout@v4 | ||
| - uses: actions/checkout@v7 |
There was a problem hiding this comment.
Same as in plain-forge repo - I think it would be better to stay consistent with pins so as to avoid any discrepancies and catch issues early rather than in the deploy job.
This applies also to all other un-pinned actions.
| # Non-fatal: the package is already published. | ||
| - name: Record release in Linear | ||
| continue-on-error: true | ||
| uses: linear/linear-release-action@0a25abab892a91062ebf42260dbb2ce6277aa205 # v0.16.0 |
There was a problem hiding this comment.
Just leaving a note here. This SHA pins the install script that downloads the binary which is then the linear CLI and not the CLI itself. Which only half solves the security issues.
There was a problem hiding this comment.
Correct. Pinning the action fixes the code that runs, not the binary it downloads at runtime. CLI pinned to version tag now.
The step is non-fatal by design, which also meant a failure was invisible: the job stayed green and nothing was logged. It now checks the step's own outcome, since failure() never fires when continue-on-error swallows the error. Also pins the CLI version the action downloads. Pinning the action alone still left the binary it fetches floating.
Previously only the workflows holding id-token: write were pinned, on the grounds that the rest had a smaller blast radius. That left CI and the publish path running different versions of the same actions, so a bad release would surface in a deploy rather than in a pull request. Pinning everything makes the version CI exercises the version that publishes. Dependabot moves them together.
|
Thanks! All three addressed, please take another look. |
Commented out rather than removed, so re-enabling is a straight uncomment.
2 participants
Records each PyPI release in Linear and puts the workflow actions on one pinning
policy.
linear-releasejob on a successful publish. The release is identified by the tag, not a commit hash.publish-to-pypi.ymlis SHA-pinned.github-actionsalongside pip, so the SHA pins stay patched.