chore: integrate Linear Releases with CI/CD pipeline#141
Conversation
- Add linear-release.yaml workflow for branch-cut release model - Update publish.yaml to mark releases complete in Linear on npm publish - Update RELEASE.md documentation with release branch convention and Linear integration Co-authored-by: Cursor <cursoragent@cursor.com>
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip CodeRabbit can scan for known vulnerabilities in your dependencies using OSV Scanner.OSV Scanner will automatically detect and report security vulnerabilities in your project's dependencies. No additional configuration is required. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThis PR integrates Linear release management into CI/CD: adds a branch-triggered Linear Release workflow, updates the publish workflow to complete releases and post Slack messages with the published version, updates release-it branch rules, and documents the release branch workflow. ChangesLinear Release Integration
Sequence DiagramsequenceDiagram
participant Developer
participant GitRepo as Git Repository
participant LinearReleaseWorkflow as linear-release Workflow
participant LinearAPI as Linear API
participant PublishWorkflow as publish Workflow
Developer->>GitRepo: git push release/X.Y.Z
GitRepo->>LinearReleaseWorkflow: trigger on release/** push
LinearReleaseWorkflow->>LinearAPI: sync release with version X.Y.Z
LinearAPI-->>LinearReleaseWorkflow: release synced
Developer->>PublishWorkflow: trigger publish (latest channel)
PublishWorkflow->>PublishWorkflow: extract version from package.json
PublishWorkflow->>LinearAPI: mark release X.Y.Z complete
LinearAPI-->>PublishWorkflow: release marked complete
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
.github/workflows/publish.yaml (1)
57-57: ⚖️ Poor tradeoffConsider pinning action reference to commit SHA.
Similar to
.github/workflows/linear-release.yaml, this action reference is not pinned to a commit hash. See the comment in that file for security trade-offs.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/publish.yaml at line 57, The workflow currently uses the floating tag "uses: linear/linear-release-action@v0"; update that reference to a specific commit SHA to pin the action for reproducibility and security (replace the "`@v0`" in the uses entry with the corresponding git commit SHA for linear/linear-release-action). Locate the uses line in the publish workflow and change it to the pinned SHA form (e.g., linear/linear-release-action@<commit-sha>), then verify the SHA against the action's repo and update any related documentation or comments to note why the pin was made..github/workflows/linear-release.yaml (3)
13-13: ⚖️ Poor tradeoffConsider pinning action references to commit SHAs.
The static analysis tool flags that actions are not pinned to commit hashes. Pinning to SHAs instead of tags provides stronger supply-chain security by preventing tag manipulation.
Example for
actions/checkout@v4:- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1Note: This requires looking up the current SHA for
v4,v0tags and maintaining them during updates. Consider whether this trade-off aligns with your security requirements.Also applies to: 18-18, 29-29
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/linear-release.yaml at line 13, Replace tag-based GitHub Actions references with pinned commit SHAs for the `uses:` entries to harden the workflow supply chain: locate the `uses: actions/checkout@v4` entry (and the other `uses:` entries flagged on the file) and change each to the corresponding commit SHA for the version you intend to use (e.g., replace `actions/checkout@v4` with `actions/checkout@<commit-sha>`). Retrieve the exact SHAs from the actions' GitHub releases/tags, update the YAML `uses:` values accordingly, and document/update them when bumping versions in the future.
19-19: ⚡ Quick winRemove redundant
github.event_name == 'push'checks.The workflow only triggers on
pushevents (lines 3-4), so checkinggithub.event_name == 'push'in the conditionals is redundant. ThestartsWith(github.ref_name, 'release/')check alone is sufficient to distinguish between main and release branches.♻️ Simplified conditions
- if: github.event_name == 'push' && !startsWith(github.ref_name, 'release/') + if: "!startsWith(github.ref_name, 'release/')"- if: github.event_name == 'push' && startsWith(github.ref_name, 'release/') + if: startsWith(github.ref_name, 'release/')- if: github.event_name == 'push' && startsWith(github.ref_name, 'release/') + if: startsWith(github.ref_name, 'release/')Also applies to: 25-25, 30-30
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/linear-release.yaml at line 19, Remove the redundant "github.event_name == 'push' &&" from the conditional expressions that already run in a push-triggered workflow; replace conditions like "github.event_name == 'push' && !startsWith(github.ref_name, 'release/')" with just "!startsWith(github.ref_name, 'release/')" (and similarly remove the prefix in the other occurrences using startsWith(github.ref_name, 'release/') at the other two condition sites). Locate the three if conditions that combine github.event_name and startsWith(...) and drop the github.event_name == 'push' check so only the startsWith(...) checks remain.
13-15: ⚡ Quick winEvaluate whether to disable credential persistence.
Static analysis warns that
persist-credentialsis not set tofalse. By default, the checkout action persists GitHub credentials that could be accessed by subsequent steps or leaked through artifacts.If the Linear release action doesn't require pushing back to the repository, consider explicitly disabling credential persistence:
- uses: actions/checkout@v4 with: fetch-depth: 0 + persist-credentials: falseThis reduces the risk of credential exposure.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/linear-release.yaml around lines 13 - 15, The checkout step currently uses actions/checkout@v4 without setting persist-credentials; to reduce credential exposure, update the checkout invocation (actions/checkout@v4) to explicitly set persist-credentials: false unless the Linear release workflow needs to push back to the repo or use credentials later — if pushing is required, document and restrict which steps need credentials and consider limiting scope instead.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/linear-release.yaml:
- Line 13: Replace tag-based GitHub Actions references with pinned commit SHAs
for the `uses:` entries to harden the workflow supply chain: locate the `uses:
actions/checkout@v4` entry (and the other `uses:` entries flagged on the file)
and change each to the corresponding commit SHA for the version you intend to
use (e.g., replace `actions/checkout@v4` with `actions/checkout@<commit-sha>`).
Retrieve the exact SHAs from the actions' GitHub releases/tags, update the YAML
`uses:` values accordingly, and document/update them when bumping versions in
the future.
- Line 19: Remove the redundant "github.event_name == 'push' &&" from the
conditional expressions that already run in a push-triggered workflow; replace
conditions like "github.event_name == 'push' && !startsWith(github.ref_name,
'release/')" with just "!startsWith(github.ref_name, 'release/')" (and similarly
remove the prefix in the other occurrences using startsWith(github.ref_name,
'release/') at the other two condition sites). Locate the three if conditions
that combine github.event_name and startsWith(...) and drop the
github.event_name == 'push' check so only the startsWith(...) checks remain.
- Around line 13-15: The checkout step currently uses actions/checkout@v4
without setting persist-credentials; to reduce credential exposure, update the
checkout invocation (actions/checkout@v4) to explicitly set persist-credentials:
false unless the Linear release workflow needs to push back to the repo or use
credentials later — if pushing is required, document and restrict which steps
need credentials and consider limiting scope instead.
In @.github/workflows/publish.yaml:
- Line 57: The workflow currently uses the floating tag "uses:
linear/linear-release-action@v0"; update that reference to a specific commit SHA
to pin the action for reproducibility and security (replace the "`@v0`" in the
uses entry with the corresponding git commit SHA for
linear/linear-release-action). Locate the uses line in the publish workflow and
change it to the pinned SHA form (e.g.,
linear/linear-release-action@<commit-sha>), then verify the SHA against the
action's repo and update any related documentation or comments to note why the
pin was made.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b3904343-8ba2-488c-8b77-e05b20b4a93e
📒 Files selected for processing (3)
.github/workflows/linear-release.yaml.github/workflows/publish.yamlRELEASE.md
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/publish.yaml:
- Line 58: Update the workflow to pin third-party actions to immutable commit
SHAs: replace the uses reference "linear/linear-release-action@v0" with the
specific SHA
"linear/linear-release-action@ad7da502eec3a93dd17e2e249e6c1cd84e3ee588" and
replace "slackapi/slack-github-action@v2" with
"slackapi/slack-github-action@91efab103c0de0a537f72a35f6b8cda0ee76bf0a" so the
actions in the publish workflow are fixed to exact commits rather than floating
tags.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 11dd0d43-c83f-4911-8856-c8a0f6a33a09
📒 Files selected for processing (2)
.github/workflows/publish.yamlRELEASE.md
agoldis
left a comment
agoldis
left a comment
There was a problem hiding this comment.
- please resolve bot comments
- let's enforce the valid branch names in release-it configuration
There's a single bot comment and I don't think we should ping versions with hashes for GH actions, v0 v2 are fine. |
|
@maxigimenez |
agoldis
left a comment
agoldis
left a comment
There was a problem hiding this comment.
@maxigimenez
let's enforce using branch names in `release-
agoldis
deleted the
maxi/eng-543-enable-linear-release-process-for-currentscmd-package
branch
2 participants
Integrate Linear Releases with the currents-mcp release workflow.
Made with Cursor
Summary by CodeRabbit
Chores
Documentation