ci: [MTG-1528] Add release marker to tasks after release #472
Conversation
andrii-kl
commented
Apr 3, 2025
andrii-kl
commented
- Added a marker to tasks to correspond to the release number.
- Implemented handling for negative scenarios to improve robustness and error management.
- Added processing to handle task names in different cases (upper, lower, mixed).
- Standardized output values to uppercase to avoid errors.
- Added a marker to tasks to correspond to the release number.
- Implemented handling for negative scenarios to improve robustness and error management.
- Added processing to handle task names in different cases (upper, lower, mixed). - Standardized output values to uppercase to avoid errors.
Summary by CodeRabbit
WalkthroughThe changes introduce a new GitHub Actions workflow that triggers on closed pull requests merging into the main branch from branches prefixed with Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant GH as GitHub Actions
participant AS as Artifact Storage
participant LS as linear_update.sh
participant API as Linear API
%% Linear Task Update Workflow
Dev->>GH: Merge PR on main (release/v branch)
GH->>GH: Trigger linear-release-task-info-update workflow
GH->>AS: Download "release-tasks" artifact
GH->>LS: Execute linear_update.sh (pass LINEAR_API_KEY, release tag)
loop For each ticket in .release_tasks
LS->>API: POST release comment for ticket
API-->>LS: Response (success or failure)
end
LS-->>GH: Completion status
sequenceDiagram
participant Dev as Developer
participant GH as GitHub Actions
participant PC as prepare_changelog.sh
participant AS as Artifact Storage
%% Release Preparation Flow
Dev->>GH: Trigger release preparation workflow
GH->>PC: Execute prepare_changelog.sh
PC->>AS: Generate and store .release_tasks artifact
GH->>AS: Upload "release-tasks" artifact for downstream use
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (4)
.github/workflows/linear-release-task-info-update.yml(1 hunks).github/workflows/release-prepare.yml(1 hunks)scripts/release/linear_update.sh(1 hunks)scripts/release/prepare_changelog.sh(1 hunks)
🧰 Additional context used
🪛 Shellcheck (0.10.0)
scripts/release/linear_update.sh
[info] 39-39: Double quote to prevent globbing and word splitting.
(SC2086)
scripts/release/prepare_changelog.sh
[info] 66-66: Use '[:lower:]' to support accents and foreign alphabets.
(SC2018)
[info] 66-66: Use '[:upper:]' to support accents and foreign alphabets.
(SC2019)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: test
🔇 Additional comments (2)
.github/workflows/release-prepare.yml (1)
119-124: Upload Release Tasks Artifact Step
The addition of the "Upload release tasks artifact" step correctly packages the newly created.release_tasksfile as an artifact. This will support downstream processes (such as updating Linear tasks). The implementation looks clear and consistent with the overall workflow..github/workflows/linear-release-task-info-update.yml (1)
28-30: 💡 Verification agent🧩 Analysis chain
Verify Release Tag Value for Linear Update
The workflow invokes./scripts/release/linear_update.shwith the release tag value using${{ github.event.release.tag_name }}. For pull request events, thereleaseproperty typically isn’t populated. Please verify whether this is the intended behavior or if you should instead pass a value such as${{ github.event.pull_request.head.ref }}to ensure that the script receives a valid release tag.
Based on the intended usage, please verify that the workflow is configured to trigger exclusively on release events. If the triggers are defined only under a release event (for example,
on: releaseoron: release: [published]), then passing${{ github.event.release.tag_name }}is entirely appropriate. However, if the workflow is ever triggered by pull request events, thereleaseproperty would indeed be absent.Actionable Note:
- If the workflow is intended only for release events: No change is required. The release tag value is reliably set via
${{ github.event.release.tag_name }}.- If pull_request events are (or will be) used: Update the trigger configuration accordingly and consider passing an alternative reference (such as
${{ github.event.pull_request.head.ref }}) to ensure a valid value is received.
🏁 Script executed:
#!/bin/bash # This script prints the trigger events configured in the workflow file to verify whether it runs on release events alone or if pull_request events are mixed in. echo "Extracting trigger events from .github/workflows/linear-release-task-info-update.yml:" awk '/^on:/{flag=1} flag{print} /^$/ {flag=0}' .github/workflows/linear-release-task-info-update.ymlLength of output: 519
Verify and Update Event Property for Linear Update
Our investigation shows that the workflow in.github/workflows/linear-release-task-info-update.ymlis triggered onpull_request(closed) andworkflow_dispatchevents, meaning thereleaseproperty (and thus${{ github.event.release.tag_name }}) will not be populated during these events. Please confirm your intended behavior. If the update should run on release events, consider modifying the trigger configuration accordingly. Otherwise, if the workflow is meant to run on pull requests or manual triggers, update the argument to use a relevant property such as${{ github.event.pull_request.head.ref }}to ensure that the script receives a valid value.
| # Generate file with list of tasks included this release | ||
| grep -o '[Mm][Tt][Gg]-[0-9]\{4\}' .changelog_content | sort -u | tr 'a-z' 'A-Z' > ".release_tasks" | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Enhance Case Conversion Robustness
In this new segment, you correctly generate a list of release task IDs by filtering .changelog_content. To better support international characters and avoid potential mismatches with accented letters, consider replacing tr 'a-z' 'A-Z' with the POSIX-compliant tr '[:lower:]' '[:upper:]'.
Proposed Diff:
- grep -o '[Mm][Tt][Gg]-[0-9]\{4\}' .changelog_content | sort -u | tr 'a-z' 'A-Z' > ".release_tasks"
+ grep -o '[Mm][Tt][Gg]-[0-9]\{4\}' .changelog_content | sort -u | tr '[:lower:]' '[:upper:]' > ".release_tasks"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Generate file with list of tasks included this release | |
| grep -o '[Mm][Tt][Gg]-[0-9]\{4\}' .changelog_content | sort -u | tr 'a-z' 'A-Z' > ".release_tasks" | |
| # Generate file with list of tasks included this release | |
| grep -o '[Mm][Tt][Gg]-[0-9]\{4\}' .changelog_content | sort -u | tr '[:lower:]' '[:upper:]' > ".release_tasks" |
🧰 Tools
🪛 Shellcheck (0.10.0)
[info] 66-66: Use '[:lower:]' to support accents and foreign alphabets.
(SC2018)
[info] 66-66: Use '[:upper:]' to support accents and foreign alphabets.
(SC2019)
| --data '{ | ||
| "query": "mutation { commentCreate(input: { issueId: \"'"$ISSUE_ID"'\", body: \"The task is part of the release v'$GITHUB_RELEASE_TAG' \" }) { success } }" | ||
| }') |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Improve JSON Payload Construction in curl Command
The current approach for constructing the JSON payload by directly injecting shell variables into the string can lead to word splitting or globbing issues (as highlighted by Shellcheck SC2086). For improved robustness and safety, consider using jq to build the JSON payload so the variables are properly escaped.
Proposed Diff:
- --data '{
- "query": "mutation { commentCreate(input: { issueId: \"'"$ISSUE_ID"'\", body: \"The task is part of the release v'$GITHUB_RELEASE_TAG' \" }) { success } }"
- }'
+ --data "$(jq -n \
+ --arg issue "$ISSUE_ID" \
+ --arg tag "$GITHUB_RELEASE_TAG" \
+ '{ query: "mutation { commentCreate(input: { issueId: \"" + $issue + "\", body: \"The task is part of the release v" + $tag + " \" }) { success } }" }')"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| --data '{ | |
| "query": "mutation { commentCreate(input: { issueId: \"'"$ISSUE_ID"'\", body: \"The task is part of the release v'$GITHUB_RELEASE_TAG' \" }) { success } }" | |
| }') | |
| --data "$(jq -n \ | |
| --arg issue "$ISSUE_ID" \ | |
| --arg tag "$GITHUB_RELEASE_TAG" \ | |
| '{ query: "mutation { commentCreate(input: { issueId: \"" + $issue + "\", body: \"The task is part of the release v" + $tag + " \" }) { success } }" }')" |
🧰 Tools
🪛 Shellcheck (0.10.0)
[info] 39-39: Double quote to prevent globbing and word splitting.
(SC2086)
