Create issue-manager.yml #75
Conversation
Signed-off-by: NxPKG <iconmamundentist@gmail.com>
|
|
Reviewer's Guide by SourceryThis PR adds a new GitHub Actions workflow file that implements automated issue and pull request management. The workflow uses the khulnasoft/issue-manager action to automatically close issues and PRs based on specific conditions and timeframes. No diagrams generated as the changes look simple and do not need a visual representation. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
WalkthroughTwo new GitHub Actions workflows have been added to the repository: 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 (
|
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
PR Code Suggestions ✨Explore these optional code suggestions:
|
There was a problem hiding this comment.
Hey @NxPKG - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟢 General issues: all looks good
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/issue-manager.yml(1 hunks)
🔇 Additional comments (1)
.github/workflows/issue-manager.yml (1)
17-19: LGTM: Permissions follow security best practices
The permissions are appropriately scoped to only what's needed for the issue manager functionality.
| - uses: khulnasoft/issue-manager@0.5.1 | ||
| with: | ||
| token: ${{ secrets.GITHUB_TOKEN }} | ||
| config: > | ||
| { | ||
| "answered": { | ||
| "delay": 864000, | ||
| "message": "Assuming the original need was handled, this will be automatically closed now. But feel free to add more comments or create new issues or PRs." | ||
| }, | ||
| "waiting": { | ||
| "delay": 2628000, | ||
| "message": "As this PR has been waiting for the original user for a while but seems to be inactive, it's now going to be closed. But if there's anyone interested, feel free to create a new PR." | ||
| }, | ||
| "invalid": { | ||
| "delay": 0, | ||
| "message": "This was marked as invalid and will be closed now. If this is an error, please provide additional details." | ||
| } | ||
| } |
There was a problem hiding this comment.
💡 Codebase verification
Missing required labels for issue-manager automation
The repository is missing the "answered" and "waiting" labels that are required for the issue-manager automation to work properly. Only the "invalid" label exists.
- Add the following labels to the repository:
- "answered" - For issues that have been resolved
- "waiting" - For PRs awaiting contributor response
🔗 Analysis chain
Consider adding configuration documentation
The configuration looks good, but consider adding comments to explain:
- The reasoning behind the chosen delay periods
- What criteria determine when issues get labeled as "answered", "waiting", or "invalid"
Example:
config: >
{
+ // Close answered issues after 10 days of inactivity
"answered": {
"delay": 864000,
"message": "Assuming the original need was handled, this will be automatically closed now. But feel free to add more comments or create new issues or PRs."
},Also, verify that these labels exist in the repository:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if required labels exist in the repository
gh label list | grep -E "answered|waiting|invalid"
Length of output: 92
| on: | ||
| schedule: | ||
| - cron: "13 22 * * *" | ||
| issue_comment: | ||
| types: | ||
| - created | ||
| issues: | ||
| types: | ||
| - labeled | ||
| pull_request_target: | ||
| types: | ||
| - labeled | ||
| workflow_dispatch: |
There was a problem hiding this comment.
Security: Review pull_request_target trigger usage
The workflow uses pull_request_target which runs with repository secrets and write permissions in the context of the base repository. This could be dangerous if the workflow checks out and runs code from the PR.
Consider:
- Using
pull_requestinstead if you don't need access to secrets - If
pull_request_targetis necessary, ensure no untrusted code from the PR is checked out or executed
Additionally, consider specifying which labels should trigger the workflow to prevent unnecessary runs:
pull_request_target:
types:
- labeled
+ if: contains(['answered', 'waiting', 'invalid'], github.event.label.name)Committable suggestion skipped: line range outside the PR's diff.
Signed-off-by: NxPKG <iconmamundentist@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (1)
.github/workflows/latest-changes.yml (1)
16-18: Consider pinning Ubuntu versionWhile using
ubuntu-latestworks, consider pinning to a specific version (e.g.,ubuntu-22.04) for better reproducibility and to avoid unexpected changes when the 'latest' tag moves.- runs-on: ubuntu-latest + runs-on: ubuntu-22.04
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/latest-changes.yml(1 hunks)
🔇 Additional comments (1)
.github/workflows/latest-changes.yml (1)
3-14: Review security implications of pull_request_target
While using pull_request_target is appropriate here since we need write permissions, be aware that this trigger runs workflows with repository context. The current configuration is safe because:
- It only triggers on closed PRs
- It's limited to the master branch
- The workflow only uses trusted actions
However, if the workflow is modified in the future to run on different PR states or use untrusted actions, it could pose security risks.
Let's verify other workflows aren't using this trigger unsafely:
✅ Verification successful
Security review of pull_request_target usage is satisfactory
All workflows using pull_request_target are properly secured:
latest-changes.yml: Only runs on closed PRsissue-manager.yml: Only triggers on label events, uses trusted khulnasoft actionadd-comment-from-tag.yml: Only triggers on label events, uses official actionsadd-to-project.yml: Uses official GitHub action- All workflows have appropriate permission restrictions
- All workflows use trusted actions from either GitHub official (
actions/*) or well-known organizations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other workflows using pull_request_target
rg -l "pull_request_target" .github/workflows/
Length of output: 199
Script:
#!/bin/bash
# Check the trigger configurations in workflows using pull_request_target
echo "=== latest-changes.yml ==="
rg "pull_request_target" -A 10 .github/workflows/latest-changes.yml
echo -e "\n=== issue-manager.yml ==="
rg "pull_request_target" -A 10 .github/workflows/issue-manager.yml
echo -e "\n=== add-comment-from-tag.yml ==="
rg "pull_request_target" -A 10 .github/workflows/add-comment-from-tag.yml
echo -e "\n=== add-to-project.yml ==="
rg "pull_request_target" -A 10 .github/workflows/add-to-project.yml
Length of output: 1203
Script:
#!/bin/bash
# Let's check what actions these workflows are using to ensure they're trusted
echo "=== issue-manager.yml actions ==="
rg "uses:" -A 1 .github/workflows/issue-manager.yml
echo -e "\n=== add-comment-from-tag.yml actions ==="
rg "uses:" -A 1 .github/workflows/add-comment-from-tag.yml
echo -e "\n=== add-to-project.yml actions ==="
rg "uses:" -A 1 .github/workflows/add-to-project.yml
Length of output: 673
| - uses: khulnasoft/latest-changes@0.3.2 | ||
| with: | ||
| token: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add configuration for latest-changes action
The latest-changes action supports additional configuration options that might be useful:
path- to specify where to generate the changelogtemplate- to customize the changelog formatlatest-changes-file- to specify the output file
Consider adding these configurations to better control the changelog generation.
- uses: khulnasoft/latest-changes@0.3.2
with:
token: ${{ secrets.GITHUB_TOKEN }}
+ path: CHANGELOG.md
+ latest-changes-file: LATEST_CHANGES.md📝 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.
| - uses: khulnasoft/latest-changes@0.3.2 | |
| with: | |
| token: ${{ secrets.GITHUB_TOKEN }} | |
| - uses: khulnasoft/latest-changes@0.3.2 | |
| with: | |
| token: ${{ secrets.GITHUB_TOKEN }} | |
| path: CHANGELOG.md | |
| latest-changes-file: LATEST_CHANGES.md |
| - uses: actions/checkout@v4 | ||
| with: | ||
| # To allow latest-changes to commit to master | ||
| token: ${{ secrets.ORG_REPO_TOKEN }} | ||
| - uses: khulnasoft/latest-changes@0.3.2 |
There was a problem hiding this comment.
💡 Codebase verification
Token configuration is correct but missing latest-changes configuration
The ORG_REPO_TOKEN usage is consistent across workflows and properly configured for the checkout action to allow commits to master. However, the latest-changes action is missing important configuration parameters:
- No
pathspecified for the changelog file - No
templatedefined for the changelog entries
Required configuration:
- Add
pathparameter to specify where to store the changelog - Add
templateparameter to define the format of entries - Consider adding
date-formatfor consistent timestamps
🔗 Analysis chain
Verify ORG_REPO_TOKEN permissions and availability
The workflow uses ORG_REPO_TOKEN for checkout to allow commits to master. This requires:
- The secret to be properly configured
- Appropriate permissions to commit to master
Let's verify the secret usage across workflows:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for ORG_REPO_TOKEN usage
rg "ORG_REPO_TOKEN" .github/workflows/
Length of output: 555
Script:
#!/bin/bash
# Check latest-changes.yml workflow configuration
cat .github/workflows/latest-changes.yml
Length of output: 566
.github/workflows/issue-manager.yml
Outdated
| - name: Dump GitHub context | ||
| env: | ||
| GITHUB_CONTEXT: ${{ toJson(github) }} | ||
| run: echo "$GITHUB_CONTEXT" |
There was a problem hiding this comment.
Suggestion: Remove or limit debug information to prevent exposure of potentially sensitive data [Security, importance: 9]
| - name: Dump GitHub context | |
| env: | |
| GITHUB_CONTEXT: ${{ toJson(github) }} | |
| run: echo "$GITHUB_CONTEXT" | |
| # Remove the step entirely or replace with specific context variables if needed |
.github/workflows/issue-manager.yml
Outdated
| - name: Dump GitHub context | ||
| env: | ||
| GITHUB_CONTEXT: ${{ toJson(github) }} | ||
| run: echo "$GITHUB_CONTEXT" |
There was a problem hiding this comment.
Suggestion: Remove or limit debug information to prevent exposure of potentially sensitive data [Security, importance: 9]
| - name: Dump GitHub context | |
| env: | |
| GITHUB_CONTEXT: ${{ toJson(github) }} | |
| run: echo "$GITHUB_CONTEXT" | |
| # Remove the step entirely or replace with specific context variables if needed |
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Signed-off-by: NxPKG <iconmamundentist@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
.github/workflows/issue-manager.yml (3)
4-15: Optimize workflow triggers for better resource usageConsider the following improvements:
- The cron schedule (22:13 UTC) seems arbitrary. Consider aligning it with your team's working hours for better response times.
- Add filters to the
issue_commenttrigger to prevent unnecessary workflow runs:issue_comment: types: - created + if: | + !contains(github.event.issue.labels.*.name, 'invalid') && + !contains(github.event.issue.labels.*.name, 'answered')
21-24: Consider adding error handling for repository checkWhile the owner check is good, consider making it more robust:
- if: github.repository_owner == 'khulnasoft' + if: | + github.repository_owner == 'khulnasoft' && + !github.event.repository.archived && + !github.event.repository.forkThis prevents the workflow from running on archived repositories or forks.
33-47: Consider parameterizing delay times and enhancing messages
- Make delay times configurable:
jobs: issue-manager: + inputs: + answered-delay: + description: 'Delay in seconds before closing answered issues' + default: '864000' + waiting-delay: + description: 'Delay in seconds before closing waiting PRs' + default: '2628000' steps: - uses: khulnasoft/issue-manager@0.5.1 with: config: > { "answered": { - "delay": 864000, + "delay": ${{ inputs.answered-delay }},
- Consider adding more context to messages, such as how to reopen if needed.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/issue-manager.yml(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.4)
.github/workflows/issue-manager.yml
28-28: unexpected token "[" while parsing variable access, function call, null, bool, int, float or string. expecting "IDENT", "(", "INTEGER", "FLOAT", "STRING"
(expression)
🔇 Additional comments (1)
.github/workflows/issue-manager.yml (1)
17-19: LGTM! Permissions follow security best practices
The permissions are appropriately scoped to only what's needed for the workflow.
| - name: Dump GitHub context | ||
| env: | ||
| GITHUB_CONTEXT: ${{ toJson(pick(github, ['event_name', 'repository', 'issue.number'])) }} | ||
| run: echo "$GITHUB_CONTEXT" |
There was a problem hiding this comment.
Fix GitHub context filtering syntax
The pick function is not available in GitHub Actions. Use this instead:
- GITHUB_CONTEXT: ${{ toJson(pick(github, ['event_name', 'repository', 'issue.number'])) }}
+ GITHUB_CONTEXT: ${{ toJson(github) | jq '{event_name: .event_name, repository: .repository, issue_number: .issue.number}' }}Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 actionlint (1.7.4)
28-28: unexpected token "[" while parsing variable access, function call, null, bool, int, float or string. expecting "IDENT", "(", "INTEGER", "FLOAT", "STRING"
(expression)
User description
Category:
Overview
Issue Number (if applicable) #00
New Vars (if applicable)
Screenshot (if applicable)
Code Quality Checklist (Please complete)
PR Type
configuration changes
Description
Changes walkthrough 📝
issue-manager.yml
Add GitHub Actions workflow for issue management.github/workflows/issue-manager.yml
events.
specific delay and messages.
Summary by CodeRabbit
New Features
Chores