Add action runs when labels are added or removed #18
Conversation
WalkthroughThe pull request modifies the GitHub Actions workflow configuration for health checks. The change expands the trigger conditions for the Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 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: 0
🧹 Nitpick comments (1)
.github/workflows/health-check.yml (1)
10-10: Consider filtering for specific labels to optimize workflow runs.While adding
labeledandunlabeledevents will help with incident monitoring, this trigger will run for all label changes. Since this workflow performs resource-intensive operations (npm install, build, deploy), consider filtering for specific labels to avoid unnecessary runs.- types: [opened, closed, labeled, unlabeled] + types: [opened, closed, labeled, unlabeled] + # Only run on incident label changes + if: | + github.event.label.name == 'incident' || + contains(github.event.issue.labels.*.name, 'incident')
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/health-check.yml(1 hunks)
🔇 Additional comments (1)
.github/workflows/health-check.yml (1)
10-10: Verify alignment with PR objective.The PR objective specifically mentions improving response time for the
incidentlabel. However, the current implementation triggers the workflow for all label changes. Please confirm if this broader scope is intentional.Let's check if the
incidentlabel exists and is actively used:✅ Verification successful
The broader label scope is appropriate for a status page system
While the PR objective mentions improving response time for the
incidentlabel, triggering on all label events is the correct approach for a status page that needs to reflect all issue status changes. Theincidentlabel exists and is actively used (2 issues), but other label changes might also be relevant for the system's overall status representation.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for the existence and usage of the 'incident' label # Expected: Find references to the 'incident' label in issues # Check if the incident label exists and is used in issues gh api graphql -f query=' query($owner:String!, $name:String!) { repository(owner:$owner, name:$name) { labels(first:100) { nodes { name issues { totalCount } } } } }' -F owner=Bullrich -F name=Status-Page | jq '.data.repository.labels.nodes[] | select(.name=="incident")'Length of output: 396
Script:
#!/bin/bash # Check the workflow implementation for label handling cat .github/workflows/health-check.ymlLength of output: 3648
|
The nitpick comment suggests an if statement in the on section. I've checked where I can, and asked ChatGPT to be sure, if statements are not supported there. |
This PR adds two settings to the Github Actions On issues statement. It adds the
labeledandunlabeledissue types.By adding these two, actions are run when a label is added or removed to an issue. This allows faster response time when adding or removing the the
incidentlabel.Summary by CodeRabbit