pre-issue script #48
pre-issue script #48
Conversation
📝 WalkthroughWalkthroughAdds a JSON file of pre-defined GitHub issues and a GitHub Actions workflow that validates that file, creates the listed issues via the GitHub API, and then removes the issues file and the workflow after successful creation. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Repo as Repository (files)
participant Runner as Actions Runner
participant GHAPI as GitHub API
participant Git as Commit/Push
Note over Repo,Runner: Workflow triggered (push to main / manual)
Runner->>Repo: Read `/.github/initial-issues.json`
alt file missing
Runner->>Runner: Exit (no-op)
else file present
Runner->>Runner: Validate JSON structure ({ issues: [...] })
loop for each issue
Runner->>GHAPI: POST /repos/{owner}/{repo}/issues (issue payload)
GHAPI-->>Runner: 201 Created / error
alt error
Runner->>Runner: Fail step (abort workflow)
end
end
Runner->>Repo: Delete `initial-issues.json` and workflow file
Runner->>Git: Commit & push deletions
Git-->>Repo: Files removed
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
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 |
github-actions
bot
added
no-issue-linked
ci-cd
configuration
github-actions
javascript
size/L
external-contributor
and removed
size/L
labels
![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
🧹 Nitpick comments (1)
.github/workflows/create-initial-issues.yml (1)
58-73: Consider checking for existing issues to avoid duplicates.The workflow creates all issues without checking if issues with the same titles already exist. While the workflow does self-delete after running (reducing the chance of re-runs), if someone manually re-runs the workflow or restores the files, duplicate issues would be created.
💡 Optional enhancement to check for existing issues
Add a check before creating each issue:
// Create each issue for (const issue of issuesData.issues) { try { + // Check if issue already exists + const existingIssues = await github.rest.issues.listForRepo({ + owner: context.repo.owner, + repo: context.repo.repo, + state: 'all', + per_page: 100 + }); + + const isDuplicate = existingIssues.data.some( + existing => existing.title === issue.title + ); + + if (isDuplicate) { + console.log(`⊘ Skipping duplicate issue: ${issue.title}`); + continue; + } + const response = await github.rest.issues.create({Note: This adds API calls and complexity, so only implement if duplicate issues become a concern.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/initial-issues.json.github/workflows/create-initial-issues.yml
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-12-25T01:19:20.143Z
Learnt from: kpj2006
Repo: AOSSIE-Org/Template-Repo PR: 4
File: .github/workflows/release-drafter.yml:4-7
Timestamp: 2025-12-25T01:19:20.143Z
Learning: In the Template-Repo (AOSSIE-Org/Template-Repo), the release-drafter workflow intentionally includes both `main` and `master` branches in the trigger configuration because it's a template repository that needs to support projects using either branch naming convention.
Applied to files:
.github/workflows/create-initial-issues.yml
🔇 Additional comments (2)
.github/initial-issues.json (1)
1-279: LGTM! Comprehensive issue template collection.The JSON structure is well-formed and the issue templates are comprehensive, covering a wide range of project setup tasks. The use of structured markdown with checkboxes, resources, and labels makes these issues actionable and beginner-friendly.
.github/workflows/create-initial-issues.yml (1)
25-33: LGTM! Proper file existence check.The file existence check is well-implemented with appropriate output handling and user feedback.
| concurrency: | ||
| group: create-initial-issues-${{ github.ref }} | ||
| cancel-in-progress: false |
There was a problem hiding this comment.
Consider stricter concurrency control to prevent duplicate issues.
The current concurrency configuration with cancel-in-progress: false allows multiple workflow runs to proceed simultaneously. If the workflow is triggered multiple times (e.g., rapid successive pushes) before the cleanup step deletes the files, it could create duplicate sets of issues.
🔎 Proposed fix to prevent duplicate issue creation
concurrency:
group: create-initial-issues-${{ github.ref }}
- cancel-in-progress: false
+ cancel-in-progress: trueThis ensures only one instance of the workflow runs at a time per branch, preventing duplicate issue creation.
📝 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.
| concurrency: | |
| group: create-initial-issues-${{ github.ref }} | |
| cancel-in-progress: false | |
| concurrency: | |
| group: create-initial-issues-${{ github.ref }} | |
| cancel-in-progress: true |
🤖 Prompt for AI Agents
.github/workflows/create-initial-issues.yml around lines 13 to 15: the workflow
concurrency uses "cancel-in-progress: false" which allows overlapping runs and
can create duplicate issues; change it to "cancel-in-progress: true" (keeping
the same group key) so that a new run cancels any in-progress run for the same
branch, ensuring only one instance executes at a time and preventing duplicate
issue creation.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Fetch the comment from PR #15 discussion
gh api repos/AOSSIE-Org/Template-Repo/pulls/15/comments/2650785364 --jq '{body: .body, user: .user.login, path: .path, diff_hunk: .diff_hunk}'
Length of output: 130
🏁 Script executed:
#!/bin/bash
# Fetch PR #15 details and comments
echo "=== PR #15 Details ==="
gh pr view 15 --repo AOSSIE-Org/Template-Repo --json title,body,author,state,number
echo -e "\n=== Review Comments from PR #15 ==="
gh api repos/AOSSIE-Org/Template-Repo/pulls/15/comments --jq '.[] | select(.user.login == "coderabbitai[bot]") | {id: .id, path: .path, body: .body[0:500], line: .line}' | head -50
echo -e "\n=== Searching for concurrency-related comments ==="
gh api repos/AOSSIE-Org/Template-Repo/pulls/15/comments --jq '.[] | select(.body | contains("concurrency") or contains("cancel-in-progress")) | {id: .id, user: .user.login, path: .path, body: .body}'
Length of output: 11395
@kpj2006, you're absolutely right to point out that inconsistency! I apologize for the confusion.
Looking at my comment from PR #15, I can see that I originally recommended cancel-in-progress: false, which is actually the correct configuration for this workflow. My suggestion in the current PR to change it to true is incorrect.
Here's why cancel-in-progress: false is the right choice:
- Graceful queuing: With
false, if multiple runs are triggered, they queue up rather than canceling each other - Safe cleanup: The first run completes fully—creating all issues and deleting the configuration files
- Natural skip behavior: When queued runs execute, they check for file existence (line with
if: steps.check_file.outputs.exists == 'true') and skip gracefully since the first run already deleted the files - No interruption risk: With
cancel-in-progress: true, a new trigger could cancel the first run mid-execution, potentially interrupting the cleanup step and leaving files in place, which could cause duplicate issues on the next run
The current configuration with cancel-in-progress: false is already optimal for preventing duplicate issues while ensuring complete execution. Thank you for catching this error! 🐰
🧠 Learnings used
Learnt from: kpj2006
Repo: AOSSIE-Org/Template-Repo PR: 4
File: .github/workflows/release-drafter.yml:4-7
Timestamp: 2025-12-25T01:19:20.143Z
Learning: In the Template-Repo (AOSSIE-Org/Template-Repo), the release-drafter workflow intentionally includes both `main` and `master` branches in the trigger configuration because it's a template repository that needs to support projects using either branch naming convention.
Updated issue template for CI/CD to focus on deployment pipeline setup and removed obsolete testing tasks.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
.github/workflows/create-initial-issues.yml (1)
39-39: Fix typo in comment.The comment has a spelling error: "hecne" should be "hence".
🔎 Proposed fix
- #js-yaml is NOT bundled with actions/github-script@v7 hecne we use JSON for the issues file + #js-yaml is NOT bundled with actions/github-script@v7 hence we use JSON for the issues file
🧹 Nitpick comments (2)
.github/workflows/create-initial-issues.yml (2)
16-16: Consider the portability implications of the organization restriction.The condition
github.repository_owner == 'AOSSIE-Org'prevents this workflow from running in forks outside the AOSSIE-Org organization. While this may be intentional for your template, it limits portability if users fork the template to their own organizations or personal accounts.If this template is intended for broader use beyond AOSSIE-Org, consider removing the organization check and relying only on the template repository exclusion.
🔎 Proposed fix to improve portability
- if: ${{ github.repository != 'AOSSIE-Org/Template-Repo' && github.repository_owner == 'AOSSIE-Org' }} + if: ${{ github.repository != 'AOSSIE-Org/Template-Repo' }}
58-73: Consider validating required issue fields before API calls.The code iterates through issues and creates them without validating that required fields (like
titleandbody) are present. While the GitHub API will reject invalid issues, adding upfront validation would provide clearer error messages and fail faster.🔎 Proposed enhancement for field validation
// Create each issue for (const issue of issuesData.issues) { try { + // Validate required fields + if (!issue.title || typeof issue.title !== 'string' || issue.title.trim() === '') { + throw new Error('Issue missing required field: title'); + } + if (!issue.body || typeof issue.body !== 'string') { + throw new Error('Issue missing required field: body'); + } + const response = await github.rest.issues.create({ owner: context.repo.owner, repo: context.repo.repo, title: issue.title, body: issue.body, labels: issue.labels || [] });
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/create-initial-issues.yml
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-12-25T01:19:20.143Z
Learnt from: kpj2006
Repo: AOSSIE-Org/Template-Repo PR: 4
File: .github/workflows/release-drafter.yml:4-7
Timestamp: 2025-12-25T01:19:20.143Z
Learning: In the Template-Repo (AOSSIE-Org/Template-Repo), the release-drafter workflow intentionally includes both `main` and `master` branches in the trigger configuration because it's a template repository that needs to support projects using either branch naming convention.
Applied to files:
.github/workflows/create-initial-issues.yml
🔇 Additional comments (1)
.github/workflows/create-initial-issues.yml (1)
82-99: LGTM! Cleanup logic properly handles concurrent commits.The cleanup step correctly addresses the potential race condition by pulling with rebase before pushing. The conditional execution ensures this only runs after successful issue creation, and the workflow will fail gracefully if conflicts occur during rebase.
1 participant
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.