Add GitHub workflows for dependency review, label management, stale i…#250
Add GitHub workflows for dependency review, label management, stale i…#250kpj2006 wants to merge 3 commits intoAOSSIE-Org:mainfrom
Conversation
…ssue handling, and template synchronization
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 7 minutes and 6 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughAdded repository configuration files including editor settings for consistent code formatting, eight GitHub Actions workflows for automated dependency review, merge conflict detection, label management, stale issue handling, PR label synchronization, and template synchronization, plus a template sync ignore configuration file. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Poem
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.editorconfig:
- Around line 36-60: Condense the large inline documentation block in the
.editorconfig by removing or trimming the verbose explanatory comments (the
multi-line file-pattern and property descriptions) and keeping only a brief note
and the official documentation link; ensure the essential references (e.g., the
"Supported Editors" and "Official Documentation" URLs) remain so contributors
can find more info, but delete redundant examples and long lists to keep the
file concise.
- Around line 1-60: The .editorconfig file declares insert_final_newline = true
but the file is missing a trailing newline; update the .editorconfig content by
ensuring there is a single final newline at the end of the file (i.e., add a
newline character after the last comment line) so the file itself conforms to
the insert_final_newline setting.
- Line 26: The [*.sh] glob only matches .sh files; update the .editorconfig to
cover other shell-script extensions and extensionless scripts by expanding the
pattern (e.g., replace or add a section for [*.{sh,bash,zsh}] and/or a generic
[*] rule that applies desired settings when a file has a shell shebang), and
ensure you include the existing settings that applied under [*.sh] so they also
apply to these additional patterns.
- Line 22: The current glob pattern [*.{js,jsx,ts,tsx,json,yml,yaml}] in
.editorconfig misses modern JS/TS module extensions and common web asset files;
update that bracketed pattern to include .mjs, .cjs, .mts, .cts and any project
web files you use (e.g., .css, .scss, .less, .html, .vue) so the rule applies
consistently across those types—replace the existing [*.{...}] entry with an
expanded set like
[*.{js,jsx,mjs,cjs,ts,tsx,mts,cts,json,yml,yaml,css,scss,less,html,vue}] (adjust
list to match actual project file types).
In @.github/workflow/setup-labels.yml:
- Around line 23-131: The requiredLabels array is missing labels used by other
workflows so it should be the single source of truth: add entries for
"template_sync", "auto_pr", "PR has merge conflicts", "Stale", and
"pending-coderabbit-review" to the requiredLabels array (keeping the same object
shape: name, color, description) and choose consistent colors/descriptions for
each; ensure any workflow code that creates or checks labels continues to
reference requiredLabels so these labels are centrally managed by the
requiredLabels definition.
In @.github/workflow/sync-pr-labels.yml:
- Around line 291-293: The label string used when adding org members is
mis-cased: in the permission check block where you inspect
permissionLevel.data.permission and call contributorLabels.push('org-Member')
(and set isMaintainer = true), change the pushed label to the managed name
'org-member' (all lowercase) so it matches the label created by
setup-labels.yml.
- Around line 59-111: When a PR is updated to link an issue you must remove the
stale 'no-issue-linked' label; update the "Apply issue-based labels" script (the
block that reads issueNumber / prNumber and calls github.rest.issues.addLabels)
to, after successfully adding issue labels, call github.rest.issues.removeLabel
(or removeLabels) with owner, repo, issue_number: prNumber and name:
'no-issue-linked' and ignore 404 errors so removal is safe if the label isn't
present; ensure this removal runs only when issueLabels.length > 0 (i.e., inside
the same if branch that calls addLabels) so the contradictory label is cleared
whenever an issue becomes linked.
- Around line 123-130: The code uses github.rest.pulls.listFiles to fetch
changed files but does not paginate, so PRs with >30 files are truncated;
replace the single-page call with github.paginate to collect all pages (e.g.,
const files = await github.paginate(github.rest.pulls.listFiles, { owner:
context.repo.owner, repo: context.repo.repo, pull_number: prNumber }) and then
build changedFiles = files.map(f => f.filename)) so core.setOutput('files',
JSON.stringify(changedFiles)) contains every changed file; update references to
files and changedFiles accordingly.
- Around line 274-305: Replace the commit-count check that uses
github.rest.repos.listCommits and commits.data.length with a search for
previously merged PRs by the author: call
github.rest.search.issuesAndPullRequests (or equivalent search API) with
q=`author:${prAuthor} is:pr is:merged
repo:${context.repo.owner}/${context.repo.repo}` and use the returned
total_count to decide the contributor label (total_count === 0 => push
'first-time-contributor', total_count > 0 => push 'repeat-contributor'); keep
the existing maintainer check (permissionLevel, isMaintainer, contributorLabels)
but remove reliance on commits and the commits variable for contributor
classification.
In @.github/workflow/template-sync.yml:
- Around line 1-33: The workflow file is currently placed under .github/workflow
(singular) so GitHub Actions will ignore it; move the file (and any other new
workflow files) into the .github/workflows (plural) directory so the Template
Sync workflow (name: Template Sync, job: repo-sync) is recognized and runs; keep
the filename (template-sync.yml) and contents identical—only rename/move the
directory for all new workflow files.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: f0d7de1f-0a98-4eea-a960-bfa74c2dfad5
📒 Files selected for processing (9)
.editorconfig.github/workflow/dependency-review-action.yml.github/workflow/label-merge-conflicts.yml.github/workflow/release-drafter.yml.github/workflow/setup-labels.yml.github/workflow/stale.yml.github/workflow/sync-pr-labels.yml.github/workflow/template-sync.yml.templatesyncignore
| # EditorConfig helps maintain consistent coding styles across different editors and IDEs | ||
| # Documentation: https://editorconfig.org/ | ||
|
|
||
| # Top-most EditorConfig file | ||
| root = true | ||
|
|
||
| # Universal settings for all files | ||
| [*] | ||
| charset = utf-8 | ||
| end_of_line = lf | ||
| insert_final_newline = true | ||
| trim_trailing_whitespace = true | ||
| indent_style = space | ||
| indent_size = 4 | ||
|
|
||
| # Markdown files | ||
| [*.md] | ||
| # Trailing whitespace is significant in Markdown (two spaces = line break) | ||
| trim_trailing_whitespace = false | ||
|
|
||
| # JavaScript / TypeScript / Web / Config files (2-space indentation) | ||
| [*.{js,jsx,ts,tsx,json,yml,yaml}] | ||
| indent_size = 2 | ||
|
|
||
| # Shell scripts (2 spaces common practice) | ||
| [*.sh] | ||
| indent_size = 2 | ||
|
|
||
| # Makefiles (must use tabs) | ||
| [{Makefile,*.mk}] | ||
| indent_style = tab | ||
| tab_width = 4 | ||
|
|
||
|
|
||
|
|
||
| # For full list of Supported Editors: https://editorconfig.org/#pre-installed | ||
| # | ||
| # Common Properties: | ||
| # ------------------ | ||
| # - indent_style: "space" or "tab" | ||
| # - indent_size: number of columns for each indentation level | ||
| # - end_of_line: "lf", "cr", or "crlf" | ||
| # - charset: "utf-8", "utf-16be", "utf-16le", "latin1" | ||
| # - trim_trailing_whitespace: true or false | ||
| # - insert_final_newline: true or false | ||
| # - max_line_length: number (not supported by all editors) | ||
| # | ||
| # File Pattern Matching: | ||
| # ---------------------- | ||
| # - * : matches any string of characters (except path separator) | ||
| # - ** : matches any string of characters | ||
| # - ? : matches any single character | ||
| # - [name] : matches any single character in name | ||
| # - [!name] : matches any single character not in name | ||
| # - {s1,s2,s3} : matches any of the strings given (comma-separated) | ||
| # | ||
| # For more information and queries: | ||
| # - Official Documentation: https://editorconfig.org/ | ||
| # - Specification: https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties | ||
| # - Plugin Downloads: https://editorconfig.org/#download No newline at end of file |
There was a problem hiding this comment.
Add a final newline to comply with the file's own rules.
The file enforces insert_final_newline = true (Line 11) but is itself missing a trailing newline. While editors will auto-fix this upon opening, the file should follow its own conventions.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.editorconfig around lines 1 - 60, The .editorconfig file declares
insert_final_newline = true but the file is missing a trailing newline; update
the .editorconfig content by ensuring there is a single final newline at the end
of the file (i.e., add a newline character after the last comment line) so the
file itself conforms to the insert_final_newline setting.
| # For full list of Supported Editors: https://editorconfig.org/#pre-installed | ||
| # | ||
| # Common Properties: | ||
| # ------------------ | ||
| # - indent_style: "space" or "tab" | ||
| # - indent_size: number of columns for each indentation level | ||
| # - end_of_line: "lf", "cr", or "crlf" | ||
| # - charset: "utf-8", "utf-16be", "utf-16le", "latin1" | ||
| # - trim_trailing_whitespace: true or false | ||
| # - insert_final_newline: true or false | ||
| # - max_line_length: number (not supported by all editors) | ||
| # | ||
| # File Pattern Matching: | ||
| # ---------------------- | ||
| # - * : matches any string of characters (except path separator) | ||
| # - ** : matches any string of characters | ||
| # - ? : matches any single character | ||
| # - [name] : matches any single character in name | ||
| # - [!name] : matches any single character not in name | ||
| # - {s1,s2,s3} : matches any of the strings given (comma-separated) | ||
| # | ||
| # For more information and queries: | ||
| # - Official Documentation: https://editorconfig.org/ | ||
| # - Specification: https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties | ||
| # - Plugin Downloads: https://editorconfig.org/#download No newline at end of file |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Optional: Trim inline documentation for brevity.
The extensive documentation (lines 36-60) is helpful for new contributors but adds significant size to the file. The links at the top (Line 2) already point to official documentation. Consider condensing or removing these comments to keep the config concise.
This is purely a style preference with no functional impact.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.editorconfig around lines 36 - 60, Condense the large inline documentation
block in the .editorconfig by removing or trimming the verbose explanatory
comments (the multi-line file-pattern and property descriptions) and keeping
only a brief note and the official documentation link; ensure the essential
references (e.g., the "Supported Editors" and "Official Documentation" URLs)
remain so contributors can find more info, but delete redundant examples and
long lists to keep the file concise.
| const requiredLabels = [ | ||
| // ==================== CONTRIBUTOR LABELS ==================== | ||
| { | ||
| name: 'org-member', | ||
| color: '0E8A16', | ||
| description: 'Member of the organization with admin/maintain permissions' | ||
| }, | ||
| { | ||
| name: 'first-time-contributor', | ||
| color: '7057FF', | ||
| description: 'First PR of an external contributor' | ||
| }, | ||
| { | ||
| name: 'repeat-contributor', | ||
| color: '6F42C1', | ||
| description: 'PR from an external contributor who already had PRs merged' | ||
| }, | ||
|
|
||
| // ==================== ISSUE TRACKING LABELS ==================== | ||
| { | ||
| name: 'no-issue-linked', | ||
| color: 'D73A4A', | ||
| description: 'PR is not linked to any issue' | ||
| }, | ||
|
|
||
| // ==================== FILE TYPE LABELS ==================== | ||
| { | ||
| name: 'documentation', | ||
| color: '0075CA', | ||
| description: 'Changes to documentation files' | ||
| }, | ||
| { | ||
| name: 'frontend', | ||
| color: 'FEF2C0', | ||
| description: 'Changes to frontend code' | ||
| }, | ||
| { | ||
| name: 'backend', | ||
| color: 'BFD4F2', | ||
| description: 'Changes to backend code' | ||
| }, | ||
| { | ||
| name: 'javascript', | ||
| color: 'F1E05A', | ||
| description: 'JavaScript/TypeScript code changes' | ||
| }, | ||
| { | ||
| name: 'python', | ||
| color: '3572A5', | ||
| description: 'Python code changes' | ||
| }, | ||
| { | ||
| name: 'configuration', | ||
| color: 'EDEDED', | ||
| description: 'Configuration file changes' | ||
| }, | ||
| { | ||
| name: 'github-actions', | ||
| color: '2088FF', | ||
| description: 'GitHub Actions workflow changes' | ||
| }, | ||
| { | ||
| name: 'dependencies', | ||
| color: '0366D6', | ||
| description: 'Dependency file changes' | ||
| }, | ||
| { | ||
| name: 'tests', | ||
| color: 'C5DEF5', | ||
| description: 'Test file changes' | ||
| }, | ||
| { | ||
| name: 'docker', | ||
| color: '0DB7ED', | ||
| description: 'Docker-related changes' | ||
| }, | ||
| { | ||
| name: 'ci-cd', | ||
| color: '6E5494', | ||
| description: 'CI/CD pipeline changes' | ||
| }, | ||
|
|
||
| // ==================== SIZE LABELS ==================== | ||
| { | ||
| name: 'size/XS', | ||
| color: '00FF00', | ||
| description: 'Extra small PR (≤10 lines changed)' | ||
| }, | ||
| { | ||
| name: 'size/S', | ||
| color: '77FF00', | ||
| description: 'Small PR (11-50 lines changed)' | ||
| }, | ||
| { | ||
| name: 'size/M', | ||
| color: 'FFFF00', | ||
| description: 'Medium PR (51-200 lines changed)' | ||
| }, | ||
| { | ||
| name: 'size/L', | ||
| color: 'FF9900', | ||
| description: 'Large PR (201-500 lines changed)' | ||
| }, | ||
| { | ||
| name: 'size/XL', | ||
| color: 'FF0000', | ||
| description: 'Extra large PR (>500 lines changed)' | ||
| } | ||
| ]; |
There was a problem hiding this comment.
Make requiredLabels the actual source of truth.
This list omits labels that the other new workflows in this PR already use: template_sync, auto_pr, PR has merge conflicts, Stale, and pending-coderabbit-review. That means the automation will create or depend on labels that are not centrally managed here.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflow/setup-labels.yml around lines 23 - 131, The requiredLabels
array is missing labels used by other workflows so it should be the single
source of truth: add entries for "template_sync", "auto_pr", "PR has merge
conflicts", "Stale", and "pending-coderabbit-review" to the requiredLabels array
(keeping the same object shape: name, color, description) and choose consistent
colors/descriptions for each; ensure any workflow code that creates or checks
labels continues to reference requiredLabels so these labels are centrally
managed by the requiredLabels definition.
| - name: Apply issue-based labels | ||
| if: steps.extract-issue.outputs.issue_number != '' | ||
| uses: actions/github-script@v7 | ||
| with: | ||
| github-token: ${{ secrets.GITHUB_TOKEN }} | ||
| script: | | ||
| const issueNumber = '${{ steps.extract-issue.outputs.issue_number }}'; | ||
| const prNumber = context.payload.pull_request.number; | ||
|
|
||
| try { | ||
| // Fetch issue labels | ||
| const issue = await github.rest.issues.get({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| issue_number: parseInt(issueNumber) | ||
| }); | ||
|
|
||
| const issueLabels = issue.data.labels.map(label => | ||
| typeof label === 'string' ? label : label.name | ||
| ); | ||
|
|
||
| if (issueLabels.length > 0) { | ||
| console.log(`Applying issue-based labels: ${issueLabels.join(', ')}`); | ||
|
|
||
| // Add labels from issue | ||
| await github.rest.issues.addLabels({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| issue_number: prNumber, | ||
| labels: issueLabels | ||
| }); | ||
| } | ||
| } catch (error) { | ||
| console.log(`Error fetching issue #${issueNumber}: ${error.message}`); | ||
| } | ||
|
|
||
| - name: Mark no issue linked | ||
| if: steps.extract-issue.outputs.issue_number == '' | ||
| uses: actions/github-script@v7 | ||
| with: | ||
| github-token: ${{ secrets.GITHUB_TOKEN }} | ||
| script: | | ||
| const prNumber = context.payload.pull_request.number; | ||
|
|
||
| console.log('No issue linked to this PR'); | ||
|
|
||
| // Add "no-issue-linked" label | ||
| await github.rest.issues.addLabels({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| issue_number: prNumber, | ||
| labels: ['no-issue-linked'] | ||
| }); |
There was a problem hiding this comment.
Remove no-issue-linked when the PR body starts linking an issue.
Lines 95-111 add no-issue-linked, but Lines 59-94 never clear it if the author later edits the description to include a valid issue reference. That leaves contradictory labels on the same PR.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflow/sync-pr-labels.yml around lines 59 - 111, When a PR is
updated to link an issue you must remove the stale 'no-issue-linked' label;
update the "Apply issue-based labels" script (the block that reads issueNumber /
prNumber and calls github.rest.issues.addLabels) to, after successfully adding
issue labels, call github.rest.issues.removeLabel (or removeLabels) with owner,
repo, issue_number: prNumber and name: 'no-issue-linked' and ignore 404 errors
so removal is safe if the label isn't present; ensure this removal runs only
when issueLabels.length > 0 (i.e., inside the same if branch that calls
addLabels) so the contradictory label is cleared whenever an issue becomes
linked.
| const files = await github.rest.pulls.listFiles({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| pull_number: prNumber | ||
| }); | ||
|
|
||
| const changedFiles = files.data.map(file => file.filename); | ||
| core.setOutput('files', JSON.stringify(changedFiles)); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's find the exact workflow file path
find . -path "*github/workflows*" -name "*sync-pr-labels*" -o -path "*github/workflow*" -name "*sync-pr-labels*"Repository: AOSSIE-Org/Ell-ena
Length of output: 1887
🏁 Script executed:
# List GitHub workflows to find the correct directory structure
fd -t f "sync-pr-labels" .github/Repository: AOSSIE-Org/Ell-ena
Length of output: 1887
🌐 Web query:
GitHub REST API pulls.listFiles pagination default page size
💡 Result:
The GitHub REST API endpoint for listing files in a pull request (GET /repos/{owner}/{repo}/pulls/{pull_number}/files), often referred to as pulls.listFiles in client libraries, uses pagination with a default page size of 30 files. The maximum per_page is 100, and responses are limited to 3000 files total.
Citations:
- 1: https://docs.github.com/en/rest/pulls/pulls
- 2: https://apidog.com/apidoc/docs-site/347364/api-3489533
- 3: https://docs.github.com/rest/reference/pulls
- 4: https://docs.github.com/en/rest/pulls/comments
- 5: https://docs.github.com/en/rest/issues/issues
- 6: https://github.apidog.io/api-3489533
- 7: https://stackoverflow.com/questions/52345473/github-api-list-pull-requests-files-only-returns-30-files
🌐 Web query:
actions/github-script github.paginate method documentation
💡 Result:
The github.paginate method in the actions/github-script GitHub Action is part of the pre-authenticated Octokit client provided as the github argument to scripts. It handles pagination for GitHub REST API list endpoints that return multiple pages of results (e.g., issues, pull requests, files). ## Usage github.paginate accepts the same parameters as github.request or endpoint methods. It automatically fetches all pages until the last one and returns a single array of all items (flattening data from each response). ### Basic syntax javascript const results = await github.paginate(endpoint, options [, mapFn]); - endpoint: String route (e.g., 'GET /repos/{owner}/{repo}/issues') or endpoint method reference (e.g., github.rest.issues.listForRepo) or merged options object. - options: Parameters like {owner, repo, per_page: 100}. - mapFn (optional): Function (response, done) => {...} to transform each page or early-terminate via done. ### Examples from official docs and usage 1. String endpoint: javascript const issues = await github.paginate('GET /repos/{owner}/{repo}/issues', { owner: context.repo.owner, repo: context.repo.repo, state: 'all', per_page: 100 }); 2. REST endpoint method (recommended for v7+): javascript const opts = github.rest.issues.listForRepo.endpoint.merge({ ...context.issue, creator: context.payload.sender.login, state: 'all' }); const issues = await github.paginate(opts); 3. Iterator for memory efficiency: javascript for await (const response of github.paginate.iterator(github.rest.issues.listForRepo, options)) { // Process one page at a time } ## Key notes - Supports up to per_page: 100. - Always returns an array of items, even if raw responses use objects. - Unchanged across versions (v4-v8); works alongside github.rest.* (post-v5). - Relies on @octokit/plugin-paginate-rest; see Octokit pagination docs for details. - For GraphQL, use github.graphql (no built-in .paginate as of 2024; open issue). Official source: actions/github-script README explicitly states github includes pagination plugins and provides examples. Matches Octokit REST pagination behavior.
Citations:
- 1: https://github.com/actions/github-script
- 2: V6 can only count till 100 files and not beyond that actions/github-script#330
- 3: Regression with v7 when trying to iterate over pull requests. actions/github-script#448
- 4: https://andreypicado.com/simplifying-github-api-queries-with-actions-github-script/
Paginate pulls.listFiles() to capture all changed files.
The GitHub REST API pulls.listFiles endpoint defaults to 30 items per page and is paginated. Without pagination, PRs with more than 30 changed files will only process the first page, silently missing file-category labels for remaining files. Use github.paginate() to fetch all pages automatically.
Suggested fix
- const files = await github.rest.pulls.listFiles({
- owner: context.repo.owner,
- repo: context.repo.repo,
- pull_number: prNumber
- });
-
- const changedFiles = files.data.map(file => file.filename);
+ const files = await github.paginate(github.rest.pulls.listFiles, {
+ owner: context.repo.owner,
+ repo: context.repo.repo,
+ pull_number: prNumber,
+ per_page: 100
+ });
+
+ const changedFiles = files.map(file => file.filename);📝 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.
| const files = await github.rest.pulls.listFiles({ | |
| owner: context.repo.owner, | |
| repo: context.repo.repo, | |
| pull_number: prNumber | |
| }); | |
| const changedFiles = files.data.map(file => file.filename); | |
| core.setOutput('files', JSON.stringify(changedFiles)); | |
| const files = await github.paginate(github.rest.pulls.listFiles, { | |
| owner: context.repo.owner, | |
| repo: context.repo.repo, | |
| pull_number: prNumber, | |
| per_page: 100 | |
| }); | |
| const changedFiles = files.map(file => file.filename); | |
| core.setOutput('files', JSON.stringify(changedFiles)); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflow/sync-pr-labels.yml around lines 123 - 130, The code uses
github.rest.pulls.listFiles to fetch changed files but does not paginate, so PRs
with >30 files are truncated; replace the single-page call with github.paginate
to collect all pages (e.g., const files = await
github.paginate(github.rest.pulls.listFiles, { owner: context.repo.owner, repo:
context.repo.repo, pull_number: prNumber }) and then build changedFiles =
files.map(f => f.filename)) so core.setOutput('files',
JSON.stringify(changedFiles)) contains every changed file; update references to
files and changedFiles accordingly.
| const commits = await github.rest.repos.listCommits({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| author: prAuthor | ||
| }); | ||
|
|
||
| const contributorLabels = []; | ||
|
|
||
| // First check if maintainer | ||
| let isMaintainer = false; | ||
| try { | ||
| const permissionLevel = await github.rest.repos.getCollaboratorPermissionLevel({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| username: prAuthor | ||
| }); | ||
|
|
||
| if (['admin', 'maintain'].includes(permissionLevel.data.permission)) { | ||
| contributorLabels.push('org-Member'); | ||
| isMaintainer = true; | ||
| } | ||
| } catch (error) { | ||
| console.log('Could not check collaborator status'); | ||
| } | ||
|
|
||
| // If not maintainer, check contributor type | ||
| if (!isMaintainer) { | ||
| if (commits.data.length <= 1) { | ||
| contributorLabels.push('first-time-contributor'); | ||
| } else { | ||
| contributorLabels.push('repeat-contributor'); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find .github -name "*sync*" -type fRepository: AOSSIE-Org/Ell-ena
Length of output: 1887
🌐 Web query:
GitHub API repos.listCommits author parameter behavior what commits included
💡 Result:
The GitHub REST API endpoint for listing commits (GET /repos/{owner}/{repo}/commits, also referred to as repos.listCommits in SDKs) includes an optional 'author' query parameter. This parameter filters the returned commits to only those where the Git commit's author field matches the provided GitHub username or email address. It does not filter by the committer field; a separate 'committer' parameter exists for that. Key behavior: - Filters commits based on the 'author' in the commit object (commit.author.name or commit.author.email). - Equivalent to Git's --author filter in 'git log'. - Starts listing from the specified 'sha' (branch or commit SHA, default: default branch) backwards in history. - Can combine with 'path', 'since', 'until', etc. - Pagination required for full history (max 100 per page). Example: ?author=octocat returns commits where the author is user 'octocat' or their email. Note: This lists commits reachable from the specified ref in the specified repo only. For all commits by an author across repos/branches, use search API (/search/commits).
Citations:
- 1: https://docs.github.com/rest/commits/commits
- 2: https://docs.github.com/en/rest/commits/commits
- 3: https://developer.github.com/enterprise/2.16/v3/repos/commits/
🌐 Web query:
GitHub API check if user has previous merged pull requests contributor history
💡 Result:
To check if a GitHub user has previously merged pull requests (i.e., authored PRs that were merged) using the GitHub API, use the GraphQL v4 API's search query with qualifiers for the user's authored merged PRs. This returns a list of matching PRs; if any exist, the user has merged PR history. Example GraphQL query: { search(first: 1, query: "author:USERNAME is:pr is:merged", type: ISSUE) { edges { node { ... on PullRequest { number mergedAt } } } } } Replace USERNAME with the target username. If edges is non-empty, the user has at least one merged PR. For REST API v3, use the search issues endpoint (PRs are issues): GET https://api.github.com/search/issues?q=author:USERNAME+is:pr+is:merged Check if total_count > 0. This works across all public repositories (private requires authentication and access). Search is limited to 1000 results max, but for a boolean check, first: 1 or checking total_count suffices. Official GitHub search syntax supports these qualifiers (,,).
Citations:
- 1: https://docs.github.com/en/rest/pulls/pulls
- 2: https://docs.github.com/rest/pulls/pulls
- 3: https://stackoverflow.com/questions/29277128/find-pull-requests-merged-by-a-specific-user
- 4: https://docs.github.com/en/rest/issues/issues
- 5: https://stackoverflow.com/questions/57206043/using-graphql-github-api-to-filter-prs-merged-between-two-dates
- 6: https://gist.github.com/MichaelCurrin/f8a7a11451ce4ec055d41000c915b595?permalink_comment_id=5884033
- 7: https://docs.github.com/en/graphql/reference/queries
- 8: https://stackoverflow.com/questions/64347254/how-to-get-count-of-pull-requests-made-by-a-user-on-any-repo-belonging-to-an-org
- 9: https://linkedin.com/in/patrik-”reru”-56ab47180
- 10: https://docs.github.com/rest/issues/issues
Use merged-PR history for contributor labels, not commit count.
repos.listCommits({ author }) returns all commits authored by a user in the repository, but the current logic incorrectly assumes commit count indicates contributor status. A repeat contributor whose previous merged PR contained only one commit will have commits.data.length <= 1 and be mislabeled as first-time-contributor. Check for previously merged PRs instead, using the search API with author:USERNAME is:pr is:merged (REST or GraphQL equivalent).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflow/sync-pr-labels.yml around lines 274 - 305, Replace the
commit-count check that uses github.rest.repos.listCommits and
commits.data.length with a search for previously merged PRs by the author: call
github.rest.search.issuesAndPullRequests (or equivalent search API) with
q=`author:${prAuthor} is:pr is:merged
repo:${context.repo.owner}/${context.repo.repo}` and use the returned
total_count to decide the contributor label (total_count === 0 => push
'first-time-contributor', total_count > 0 => push 'repeat-contributor'); keep
the existing maintainer check (permissionLevel, isMaintainer, contributorLabels)
but remove reliance on commits and the commits variable for contributor
classification.
| if (['admin', 'maintain'].includes(permissionLevel.data.permission)) { | ||
| contributorLabels.push('org-Member'); | ||
| isMaintainer = true; |
There was a problem hiding this comment.
Use the managed label name here.
setup-labels.yml provisions org-member, but this step adds org-Member. Keep the exact label string aligned with the managed label set.
Suggested fix
- contributorLabels.push('org-Member');
+ contributorLabels.push('org-member');📝 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.
| if (['admin', 'maintain'].includes(permissionLevel.data.permission)) { | |
| contributorLabels.push('org-Member'); | |
| isMaintainer = true; | |
| if (['admin', 'maintain'].includes(permissionLevel.data.permission)) { | |
| contributorLabels.push('org-member'); | |
| isMaintainer = true; |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflow/sync-pr-labels.yml around lines 291 - 293, The label string
used when adding org members is mis-cased: in the permission check block where
you inspect permissionLevel.data.permission and call
contributorLabels.push('org-Member') (and set isMaintainer = true), change the
pushed label to the managed name 'org-member' (all lowercase) so it matches the
label created by setup-labels.yml.
| name: Template Sync | ||
|
|
||
| on: | ||
| # cronjob trigger - runs monthly on the 1st at midnight | ||
| schedule: | ||
| - cron: "0 0 1 * *" | ||
| workflow_dispatch: | ||
| jobs: | ||
| repo-sync: | ||
| runs-on: ubuntu-latest | ||
| if: github.repository != 'AOSSIE-Org/Template-Repo' | ||
| # https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs | ||
| permissions: | ||
| contents: write | ||
| pull-requests: write | ||
|
|
||
| steps: | ||
| # Check out the repository | ||
| - name: Checkout | ||
| uses: actions/checkout@v4 | ||
| # https://github.com/actions/checkout#usage | ||
| # uncomment if you use submodules within the repository | ||
| # with: | ||
| # submodules: true | ||
|
|
||
| - name: actions-template-sync | ||
| uses: AndreasAugustin/actions-template-sync@v2 | ||
| with: | ||
| source_repo_path: AOSSIE-Org/Template-Repo | ||
| upstream_branch: main # defaults to main | ||
| pr_labels: template_sync,auto_pr # defaults to template_sync | ||
| source_gh_token: ${{ secrets.GITHUB_TOKEN }} | ||
| is_pr_cleanup: true # for not open multiple PRs No newline at end of file |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd .github && find . -type d | head -20Repository: AOSSIE-Org/Ell-ena
Length of output: 1887
🏁 Script executed:
find . -path "./.github/workflow*" -type f | head -20Repository: AOSSIE-Org/Ell-ena
Length of output: 1887
🏁 Script executed:
ls -la .github/ | grep -i workflowRepository: AOSSIE-Org/Ell-ena
Length of output: 1887
🌐 Web query:
GitHub Actions workflow directory .github/workflows naming convention
💡 Result:
GitHub Actions workflow files must be stored in the .github/workflows directory of the repository. They must be YAML files with either a .yml or .yaml extension. There are no strict official naming conventions for the filenames beyond this requirement; any descriptive name ending in .yml or .yaml is valid. If the optional 'name' field is omitted in the YAML, GitHub displays the workflow using the file path relative to the repository root (e.g., .github/workflows/ci.yml). Common best practices from community sources include using kebab-case (lowercase with hyphens) for descriptive filenames, such as ci.yml, deploy-staging.yml, or test.yml, to improve readability and organization.
Citations:
- 1: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 2: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions
- 3: https://docs.github.com/en/actions/use-cases-and-examples/creating-an-example-workflow#:~:text=In your repository, create the,called learn-github-actions.
- 4: https://docs.github.com/actions/using-workflows/about-workflows
- 5: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions
- 6: https://www.reddit.com/r/GithubActions/comments/yj1opc/naming_convention_for_workflows/
- 7: https://dev.to/thesius_code_7a136ae718b7/github-actions-workflows-github-actions-patterns-best-practices-pge
- 8: https://earthly.dev/blog/github-actions-reusable-workflows/
Move the new workflows into .github/workflows/.
Workflow files must be stored in .github/workflows/ (plural). Files in .github/workflow/ (singular) will be ignored by GitHub Actions, so none of the automation in this PR will trigger. Rename the directory for all new workflow files.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflow/template-sync.yml around lines 1 - 33, The workflow file is
currently placed under .github/workflow (singular) so GitHub Actions will ignore
it; move the file (and any other new workflow files) into the .github/workflows
(plural) directory so the Template Sync workflow (name: Template Sync, job:
repo-sync) is recognized and runs; keep the filename (template-sync.yml) and
contents identical—only rename/move the directory for all new workflow files.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
1 participant
…ssue handling, and template synchronization
Closes #
📝 Description
🔧 Changes Made
📷 Screenshots or Visual Changes (if applicable)
🤝 Collaboration
Collaborated with:
@username(optional)✅ Checklist
Summary by CodeRabbit