ci: remove holopin.yml from global .github repo#1645
Conversation
|
WalkthroughThis update modifies several GitHub Actions workflow files to upgrade the versions of core actions, including Changes
Estimated code review effort1 (~8 minutes) 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:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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
Documentation and Community
|
What reviewer looks at during PR reviewThe following are ideal points maintainers look for during review. Reviewing these points yourself beforehand can help streamline the review process and reduce time to merge.
|
|
Please retry analysis of this Pull-Request directly on SonarQube Cloud |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (2)
.github/workflows/bounty-program-commands.yml (1)
25-29: Fix theifcondition –'a' || 'b'always evaluates to'a'
github.actor != ('aeworxet' || 'thulieblack')effectively becomesgithub.actor != 'aeworxet', so any calls fromthulieblackare treated as unauthorised.
Rewrite with two explicit comparisons:if: > github.actor != 'aeworxet' && github.actor != 'thulieblack' && startsWith(github.event.comment.body, '/bounty').github/workflows/notify-tsc-members-mention.yml (1)
35-41: Enforce Active Node.js LTS Across All JobsNode 16 is EOL and can expose us to unpatched CVEs. Let’s update each job in
.github/workflows/notify-tsc-members-mention.ymlto use the latest LTS:• File:
.github/workflows/notify-tsc-members-mention.yml
– Lines: 39, 85, 131, 177, 223, 269Apply this diff at each location:
- node-version: 16 + # Use the latest Node.js LTS + node-version: 'lts/*'Please apply the same update to every job in this workflow.
♻️ Duplicate comments (1)
.github/workflows/notify-tsc-members-mention.yml (1)
81-88: Replicate the$TITLEinterpolation fix across all jobsThe same hard-coded
'$TITLE'string appears in every event-specific job.
One-liner search & replace will address them all:rg "sendEmail\('\$\{\{github\.event[^\)]*\}', '\$TITLE'\)" \ --replace "sendEmail('\$1', process.env.TITLE)" -t yaml -NEnsures consistency and prevents false-alert subjects everywhere.
Also applies to: 97-103, 110-120, 127-134, 143-149, 156-166, 173-180, 189-195, 202-212, 219-226, 235-241, 248-258, 265-272, 281-287, 294-304
🧹 Nitpick comments (4)
.github/workflows/release-announcements.yml (2)
18-19: Consider pinningactions/checkout@v4to a SHA
v4is still a floating major tag. Pinning to a specific commit (e.g.actions/[email protected]) offers the same reproducibility you applied to the Slack action.Also applies to: 37-38
40-41:actions/github-scriptupgrade: confirm Node 20 compatibility & pin
v7switches to Node 20. Double-check anyawaitusage for unhandled promise rejections and pin to a specific release/sha to avoid future breakage..github/workflows/automerge-for-humans-add-ready-to-merge-or-do-not-merge-label.yml (1)
29-30: Lockactions/github-scriptto an immutable referenceSame rationale as other workflows: use a tagged release or commit SHA instead of
v7to guard against unexpected updates.Also applies to: 81-82, 103-104
.github/workflows/automerge-orphans.yml (1)
17-20: Security hardening: pin bothcheckoutandgithub-scriptactions
actions/checkout@v4andactions/github-script@v7are floating tags. Pinning them (and keeping them updated via Dependabot) yields deterministic builds and mitigates supply-chain risk.
Good job already pinning the Slack action.Also applies to: 61-62
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
.github/workflows/add-good-first-issue-labels.yml(1 hunks).github/workflows/automerge-for-humans-add-ready-to-merge-or-do-not-merge-label.yml(3 hunks).github/workflows/automerge-for-humans-remove-ready-to-merge-label-on-edit.yml(1 hunks).github/workflows/automerge-orphans.yml(2 hunks).github/workflows/automerge.yml(1 hunks).github/workflows/bounty-program-commands.yml(3 hunks).github/workflows/issues-prs-notifications.yml(3 hunks).github/workflows/notify-tsc-members-mention.yml(13 hunks).github/workflows/please-take-a-look-command.yml(1 hunks).github/workflows/release-announcements.yml(2 hunks).github/workflows/stale-issues-prs.yml(1 hunks).github/workflows/welcome-first-time-contrib.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (6)
📓 Common learnings
Learnt from: derberg
PR: asyncapi/generator#1552
File: .github/workflows/pr-testing-with-test-project.yml:51-69
Timestamp: 2025-05-09T08:24:17.362Z
Learning: In GitHub Actions workflows, don't use job-level `if` conditions for jobs that might be required in branch protection rules. When a job is skipped via job-level conditions, it doesn't appear in the GitHub checks list at all, and if that job is set as required, PRs would be blocked indefinitely. Instead, use step-level conditionals within the job to skip the substantive work while still allowing the job to complete successfully.
Learnt from: derberg
PR: asyncapi/generator#1552
File: .github/workflows/pr-testing-with-test-project.yml:70-84
Timestamp: 2025-05-09T08:25:03.441Z
Learning: When suggesting workflow optimizations in GitHub Actions, be cautious with job-level conditional statements (`if` at the job level). If a job with a job-level conditional is set as a required check in branch protection settings, PRs that don't trigger the job (condition evaluates to false) can never be merged since GitHub would be waiting for a required check that never runs. Using step-level conditionals is often better as the job still completes successfully, satisfying branch protection requirements.
Learnt from: derberg
PR: asyncapi/generator#1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe
3. Messages are defined under a 'messages' container in channels
4. Servers can use a 'host' property
Learnt from: derberg
PR: asyncapi/generator#1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with action property (send/receive) and references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe operations
3. Messages are defined under a 'messages' container in channels
4. The specification decouples operations, channels and messages to improve reusability
5. Servers can use a 'host' property
Learnt from: Adi-204
PR: asyncapi/generator#1557
File: packages/templates/clients/websocket/javascript/components/SendOperation.js:21-21
Timestamp: 2025-05-12T14:57:35.024Z
Learning: In the AsyncAPI generator templates, particularly in the JavaScript WebSocket client, single quotes are used for string literals inside template-generated code (which is itself inside backticks) to preserve template placeholders like ${variable} as literal text in the generated code output.
.github/workflows/welcome-first-time-contrib.yml (2)
Learnt from: derberg
PR: #1552
File: .github/workflows/pr-testing-with-test-project.yml:70-84
Timestamp: 2025-05-09T08:25:03.441Z
Learning: When suggesting workflow optimizations in GitHub Actions, be cautious with job-level conditional statements (if at the job level). If a job with a job-level conditional is set as a required check in branch protection settings, PRs that don't trigger the job (condition evaluates to false) can never be merged since GitHub would be waiting for a required check that never runs. Using step-level conditionals is often better as the job still completes successfully, satisfying branch protection requirements.
Learnt from: derberg
PR: #1552
File: .github/workflows/pr-testing-with-test-project.yml:51-69
Timestamp: 2025-05-09T08:24:17.362Z
Learning: In GitHub Actions workflows, don't use job-level if conditions for jobs that might be required in branch protection rules. When a job is skipped via job-level conditions, it doesn't appear in the GitHub checks list at all, and if that job is set as required, PRs would be blocked indefinitely. Instead, use step-level conditionals within the job to skip the substantive work while still allowing the job to complete successfully.
.github/workflows/please-take-a-look-command.yml (1)
Learnt from: derberg
PR: #1552
File: .github/workflows/pr-testing-with-test-project.yml:70-84
Timestamp: 2025-05-09T08:25:03.441Z
Learning: When suggesting workflow optimizations in GitHub Actions, be cautious with job-level conditional statements (if at the job level). If a job with a job-level conditional is set as a required check in branch protection settings, PRs that don't trigger the job (condition evaluates to false) can never be merged since GitHub would be waiting for a required check that never runs. Using step-level conditionals is often better as the job still completes successfully, satisfying branch protection requirements.
.github/workflows/issues-prs-notifications.yml (1)
Learnt from: derberg
PR: #1552
File: .github/workflows/pr-testing-with-test-project.yml:51-69
Timestamp: 2025-05-09T08:24:17.362Z
Learning: In GitHub Actions workflows, don't use job-level if conditions for jobs that might be required in branch protection rules. When a job is skipped via job-level conditions, it doesn't appear in the GitHub checks list at all, and if that job is set as required, PRs would be blocked indefinitely. Instead, use step-level conditionals within the job to skip the substantive work while still allowing the job to complete successfully.
.github/workflows/release-announcements.yml (1)
Learnt from: derberg
PR: #1552
File: .github/workflows/pr-testing-with-test-project.yml:70-84
Timestamp: 2025-05-09T08:25:03.441Z
Learning: When suggesting workflow optimizations in GitHub Actions, be cautious with job-level conditional statements (if at the job level). If a job with a job-level conditional is set as a required check in branch protection settings, PRs that don't trigger the job (condition evaluates to false) can never be merged since GitHub would be waiting for a required check that never runs. Using step-level conditionals is often better as the job still completes successfully, satisfying branch protection requirements.
.github/workflows/notify-tsc-members-mention.yml (2)
Learnt from: derberg
PR: #1552
File: .github/workflows/pr-testing-with-test-project.yml:70-84
Timestamp: 2025-05-09T08:25:03.441Z
Learning: When suggesting workflow optimizations in GitHub Actions, be cautious with job-level conditional statements (if at the job level). If a job with a job-level conditional is set as a required check in branch protection settings, PRs that don't trigger the job (condition evaluates to false) can never be merged since GitHub would be waiting for a required check that never runs. Using step-level conditionals is often better as the job still completes successfully, satisfying branch protection requirements.
Learnt from: derberg
PR: #1552
File: .github/workflows/pr-testing-with-test-project.yml:51-69
Timestamp: 2025-05-09T08:24:17.362Z
Learning: In GitHub Actions workflows, don't use job-level if conditions for jobs that might be required in branch protection rules. When a job is skipped via job-level conditions, it doesn't appear in the GitHub checks list at all, and if that job is set as required, PRs would be blocked indefinitely. Instead, use step-level conditionals within the job to skip the substantive work while still allowing the job to complete successfully.
🪛 YAMLlint (1.37.1)
.github/workflows/welcome-first-time-contrib.yml
[warning] 20-20: wrong indentation: expected 6 but found 4
(indentation)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: Automerge PR autoapproved by a bot
- GitHub Check: Test generator as dependency with Node 20
- GitHub Check: Test generator as dependency with Node 18
- GitHub Check: Acceptance tests for generated templates
- GitHub Check: Test NodeJS PR - windows-latest
🔇 Additional comments (7)
.github/workflows/stale-issues-prs.yml (1)
16-16: Action version bump looks good – please double-check input compatibility with v9.1.0
actions/stalejumped four major versions (v5 → v9). While pinning to a commit hash is 👌 for supply-chain safety, several inputs were renamed/removed in the v8+ series (e.g.,days-before-stalebecamestale-issue-days-before-stale). None of those new names are used here, so the workflow may silently fall back to defaults and behave differently.Recommend reviewing the v9 docs and, if needed, updating the input names or adding an explicit
debug-only: truedry-run on a fork before merging..github/workflows/add-good-first-issue-labels.yml (1)
17-20: Bumping toactions/github-script@v7– double-check Node 20 compatibility
github-scriptv7 runs on the Node 20 runtime.
Please verify that every script in this step:script: | const areas = …is free from deprecated APIs (e.g.
fs.promises.readdirrecursion options,require('node:')module specifiers) and still works with Octokit ^7 bundled by the action.
If everything passes in CI – great, nothing else to change..github/workflows/please-take-a-look-command.yml (1)
26-30:actions/github-script@v7upgrade requires runtime sanity-checkAs with other workflows, v7 switches to Node 20.
Run this job on a test PR and ensure:
await github.request(prDetailsUrl)still resolves (no TLS/HTTP2 quirks on Node 20).- The reviewer-ping comment is created exactly once.
No code changes expected, but worth validating before relying on it.
.github/workflows/automerge-for-humans-remove-ready-to-merge-label-on-edit.yml (1)
18-21: Confirm scripts remain compatible after upgrading to Node 20No logic changed, but
github-scriptv7 ships Node 20.
Quick regression test: edit a PR title and ensure theready-to-mergelabel is removed as before.
If everything behaves, ✅..github/workflows/automerge.yml (1)
24-30: Upgrade note: Node 20 runtime now used for labeling step
actions/github-script@v7brings Node 20 and Octokit ^7.
The simpleaddLabelscall should survive, yet please monitor the first run for:
- authentication issues with
GH_TOKEN- any rate-limit headers differences
No code changes needed if it passes.
.github/workflows/issues-prs-notifications.yml (1)
29-30: 👍 Good move: Slack action is now pinned to an exact commitLocking
rtCamp/action-slack-notifytoc337…improves determinism and security.
No further issues spotted for these steps.Also applies to: 47-48, 65-66
.github/workflows/notify-tsc-members-mention.yml (1)
51-57: Good move: pinningrtCamp/action-slack-notifyto a commit hashExplicitly pinning to
c337377…guarantees deterministic runs and mitigates “shadow-tag” supply-chain attacks. 👍
| uses: actions/github-script@v7 | ||
| with: |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Pin actions/github-script@v7 to a commit hash to prevent supply-chain drift
All three steps now point at the moving tag v7. Unlike the Slack action (pinned to c337…), this leaves the workflow open to silent behaviour changes if the tag is retagged.
-uses: actions/github-script@v7
+uses: actions/[email protected] # or a full sha, e.g. 8d1756d0e9d2668c6b0a2e4e8e9a0fb7f6c0f0bAlso verify the scripts still run under Node 20 (the runtime bump introduced in v7).
Also applies to: 61-62, 102-103
🏁 Script executed:
#!/bin/bash
# Identify all occurrences of the floating tag in the workflow
grep -R "actions/github-script@v7" -n .github/workflows/bounty-program-commands.ymlLength of output: 210
🏁 Script executed:
#!/bin/bash
# Fetch the latest release tag for actions/github-script from GitHub API
curl -s https://api.github.com/repos/actions/github-script/releases/latest | jq -r '.tag_name'Length of output: 101
🏁 Script executed:
#!/bin/bash
# Retrieve release notes for v7.0.1 to verify Node 20 support
curl -s https://api.github.com/repos/actions/github-script/releases/tags/v7.0.1 | jq -r '.body' | grep -i "Node"Length of output: 110
🏁 Script executed:
#!/bin/bash
# Verify Node.js engine requirements from action.yml and package.json for v7.0.1
echo "Fetching action.yml for actions/[email protected]..."
curl -s https://raw.githubusercontent.com/actions/github-script/v7.0.1/action.yml | sed -n '1,200p' | grep -E "runs-on|node"
echo
echo "Checking engines field in package.json..."
curl -s https://raw.githubusercontent.com/actions/github-script/v7.0.1/package.json | jq '.engines'Length of output: 495
Pin actions/github-script to a fixed v7.0.1 release
To prevent supply-chain drift, update all three steps from the moving v7 tag to the exact v7.0.1 release (or its full SHA). We’ve verified that v7.0.1 uses Node 20 (using: node20 in action.yml and "node": ">=20.0.0 <21.0.0" in package.json), so your workflows will continue to run under Node 20.
• .github/workflows/bounty-program-commands.yml:
– Line 35, 61, 102
- uses: actions/github-script@v7
+ uses: actions/[email protected] # or pin to a full SHA for even stronger immutability🤖 Prompt for AI Agents
In .github/workflows/bounty-program-commands.yml at lines 35, 61, and 102, the
usage of actions/github-script is currently pinned to the floating tag v7.
Update these lines to pin the action to the fixed version v7.0.1 instead of the
moving v7 tag to prevent supply-chain drift and ensure consistent Node 20
runtime environment.
| uses: actions/github-script@v7 | ||
| env: | ||
| CALENDAR_ID: ${{ secrets.CALENDAR_ID }} | ||
| CALENDAR_SERVICE_ACCOUNT: ${{ secrets.CALENDAR_SERVICE_ACCOUNT }} | ||
| MAILCHIMP_API_KEY: ${{ secrets.MAILCHIMP_API_KEY }} | ||
| TITLE: ${{github.event.issue.title}} | ||
| with: | ||
| script: | | ||
| const sendEmail = require('./.github/workflows/scripts/mailchimp/index.js'); | ||
| sendEmail('${{github.event.issue.html_url}}', '${{github.event.issue.title}}'); | ||
| sendEmail('${{github.event.issue.html_url}}', '$TITLE'); | ||
|
|
There was a problem hiding this comment.
$TITLE is never interpolated – will be sent literally
Inside actions/github-script, the second parameter is a JavaScript string. Writing '$TITLE' passes the literal text $TITLE, not the env value.
Use process.env.TITLE or GitHub expression substitution.
- sendEmail('${{github.event.issue.html_url}}', '$TITLE');
+ sendEmail('${{github.event.issue.html_url}}', process.env.TITLE);Apply the same fix to every job that calls sendEmail(...).
Failing to fix this will generate emails with a subject of “$TITLE”.
🤖 Prompt for AI Agents
In .github/workflows/notify-tsc-members-mention.yml around lines 64 to 74, the
string '$TITLE' is passed literally to the sendEmail function instead of the
environment variable value. To fix this, replace '$TITLE' with process.env.TITLE
inside the JavaScript script block so the actual title value is used. Apply this
change to all instances where sendEmail is called with '$TITLE' to ensure the
email subject is correctly set.
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/github-script@v6 | ||
| - uses: actions/github-script@v7 | ||
| with: | ||
| github-token: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
YAML indentation error will break the workflow
steps: is indented 4 spaces; list items must be indented 2 spaces further (6).
Current fragment:
19 steps:
20- - uses: actions/github-script@v7 # ← only 4 spaces
21 with:
Fix:
- - uses: actions/github-script@v7
- with:
- github-token: ${{ secrets.GITHUB_TOKEN }}
+ - uses: actions/github-script@v7
+ with:
+ github-token: ${{ secrets.GITHUB_TOKEN }}Without this, the workflow fails to load (YAMLException: bad indentation).
📝 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.
| runs-on: ubuntu-latest | |
| steps: | |
| - uses: actions/github-script@v6 | |
| - uses: actions/github-script@v7 | |
| with: | |
| github-token: ${{ secrets.GITHUB_TOKEN }} | |
| runs-on: ubuntu-latest | |
| steps: | |
| - uses: actions/github-script@v7 | |
| with: | |
| github-token: ${{ secrets.GITHUB_TOKEN }} |
🧰 Tools
🪛 YAMLlint (1.37.1)
[warning] 20-20: wrong indentation: expected 6 but found 4
(indentation)
🤖 Prompt for AI Agents
In .github/workflows/welcome-first-time-contrib.yml around lines 18 to 22, the
indentation of the steps list is incorrect; the list items under steps should be
indented 2 spaces further than the steps key. Adjust the indentation so that the
dash before "uses" and the following lines are indented 6 spaces instead of 4 to
fix the YAML indentation error and ensure the workflow loads correctly.
|
/rtm |
3 participants
Summary by CodeRabbit
actions/github-script,actions/checkout,actions/setup-node, and Slack notification actions.