Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Comments

Ci/add to project#32

Open
tac0turtle wants to merge 2 commits intomain from
ci/add-to-project
Open

Ci/add to project #32
tac0turtle wants to merge 2 commits intomain from
ci/add-to-project

Conversation

@tac0turtle
Copy link

@tac0turtle tac0turtle commented Feb 23, 2026
edited by coderabbitai bot
Loading

Overview

Summary by CodeRabbit

  • Chores
    • Automated workflow added to streamline issue management and project organization.

tac0turtle and others added 2 commits February 23, 2026 15:25
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Copy link
Contributor

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

Copy link

coderabbitai bot commented Feb 23, 2026
edited
Loading

📝 Walkthrough

Walkthrough

A new GitHub Actions workflow is added that automatically triggers when issues are opened. It adds the issue to GitHub Project 7 and sets the Area field to "devx" using sequential API calls with the gh CLI and jq.

Changes

Cohort / File(s) Summary
GitHub Actions Workflow Configuration
.github/workflows/add-to-project.yml
New workflow that triggers on issue creation, adds the issue to GitHub Project 7, then sets the Area field to "devx" through multi-step API calls retrieving project, field, and option IDs.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 When issues are born, they find their way,
To Project Seven, without delay,
With "devx" tag and careful care,
A rabbit's workflow, beyond compare! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name Status Explanation Resolution
Title check ❓ Inconclusive The title is vague and uses generic/abbreviated phrasing ('Ci/add to project') that doesn't clearly convey the purpose or main change to someone scanning history. Consider a more descriptive title like 'Add GitHub Actions workflow to auto-assign issues to project board' that clearly explains what the change does.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch ci/add-to-project

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Nitpick comments (2)
.github/workflows/add-to-project.yml (2)

27-31: Avoid the duplicate gh project field-list API call.

Lines 27-28 and 30-31 both invoke gh project field-list "$PROJECT_ID". Cache the output in a variable and parse it twice.

♻️ Proposed refactor
- FIELD_ID=$(gh project field-list "$PROJECT_ID" --owner evstack --format json \
- | jq -r '.fields[] | select(.name=="Area") | .id')
-
- OPTION_ID=$(gh project field-list "$PROJECT_ID" --owner evstack --format json \
- | jq -r '.fields[] | select(.name=="Area") | .options[] | select(.name=="devx") | .id')
+ FIELDS=$(gh project field-list "$PROJECT_ID" --owner evstack --format json)
+
+ FIELD_ID=$(echo "$FIELDS" | jq -r '.fields[] | select(.name=="Area") | .id')
+
+ OPTION_ID=$(echo "$FIELDS" | jq -r '.fields[] | select(.name=="Area") | .options[] | select(.name=="devx") | .id')
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/add-to-project.yml around lines 27 - 31, The duplicate gh
project field-list call should be replaced by capturing its JSON once and
reusing it; run gh project field-list "$PROJECT_ID" --owner evstack --format
json into a variable (e.g., FIELD_LIST_JSON) and then derive FIELD_ID and
OPTION_ID by piping that variable to the existing jq filters instead of calling
gh twice; update references to FIELD_ID and OPTION_ID generation to parse from
the cached JSON.

24-38: Replace hardcoded evstack with ${{ github.repository_owner }}.

The org name appears four times (--owner evstack, --owner evstack --format json ×ばつ2, --owner evstack in item-edit). Using the expression context variable makes the workflow portable if the repo is ever transferred or forked.

♻️ Proposed refactor (env var approach)
 - name: Set Area to devx
 env:
 GH_TOKEN: ${{ secrets.ADD_TO_PROJECT_PAT }}
 ITEM_ID: ${{ steps.add.outputs.itemId }}
+ ORG: ${{ github.repository_owner }}
 run: |
 PROJECT_ID=$(gh project list --owner "$ORG" --format json \
 | jq -r '.projects[] | select(.number==7) | .id')
 FIELDS=$(gh project field-list "$PROJECT_ID" --owner "$ORG" --format json)
 FIELD_ID=$(echo "$FIELDS" | jq -r '.fields[] | select(.name=="Area") | .id')
 OPTION_ID=$(echo "$FIELDS" | jq -r '.fields[] | select(.name=="Area") | .options[] | select(.name=="devx") | .id')
 gh project item-edit \
 --id "$ITEM_ID" \
 --project-id "$PROJECT_ID" \
 --field-id "$FIELD_ID" \
 --single-select-option-id "$OPTION_ID"
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/add-to-project.yml around lines 24 - 38, The workflow
hardcodes the organization name "evstack" in multiple gh project commands (used
when computing PROJECT_ID, FIELD_ID, OPTION_ID and in gh project item-edit);
replace those hardcoded --owner evstack occurrences with the repo owner
expression (e.g. use ${{ github.repository_owner }} either inline or set
OWNER="${{ github.repository_owner }}" and use --owner "$OWNER") so PROJECT_ID,
FIELD_ID, OPTION_ID lookups and the gh project item-edit call are portable if
the repo is transferred/forked.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/add-to-project.yml:
- Around line 22-38: After resolving PROJECT_ID, FIELD_ID and OPTION_ID, add
empty-variable guards that test each (e.g., [ -z "$PROJECT_ID" ], [ -z
"$FIELD_ID" ], [ -z "$OPTION_ID" ]) and when empty print a clear error to stderr
(describing which lookup failed, e.g., "failed to find Project ID for number 7",
"failed to find field 'Area'", "failed to find option 'devx'") and exit
non‐zero; place these checks immediately after the assignments for PROJECT_ID,
FIELD_ID and OPTION_ID so the subsequent gh project item-edit call never runs
with empty IDs.
- Around line 33-38: The gh project item-edit invocation uses unsupported flags
(--project-number and --owner) and will fail; update the gh project item-edit
call to use the resolved PROJECT_ID by replacing the invalid flags with
--project-id "$PROJECT_ID" while keeping the existing --id, --field-id and
--single-select-option-id flags (i.e., call gh project item-edit with
--project-id "$PROJECT_ID" --id "$ITEM_ID" --field-id "$FIELD_ID"
--single-select-option-id "$OPTION_ID").
- Line 12: The workflow currently references the action with a mutable tag
"actions/add-to-project@v1.0.2"; replace that tag with the action's immutable
full commit SHA (e.g., actions/add-to-project@<full-commit-sha>) to pin the
action to a specific commit, fetching the correct SHA from the action
repository's commit history and updating the uses line accordingly so the
workflow uses the fixed commit instead of a mutable tag.
---
Nitpick comments:
In @.github/workflows/add-to-project.yml:
- Around line 27-31: The duplicate gh project field-list call should be replaced
by capturing its JSON once and reusing it; run gh project field-list
"$PROJECT_ID" --owner evstack --format json into a variable (e.g.,
FIELD_LIST_JSON) and then derive FIELD_ID and OPTION_ID by piping that variable
to the existing jq filters instead of calling gh twice; update references to
FIELD_ID and OPTION_ID generation to parse from the cached JSON.
- Around line 24-38: The workflow hardcodes the organization name "evstack" in
multiple gh project commands (used when computing PROJECT_ID, FIELD_ID,
OPTION_ID and in gh project item-edit); replace those hardcoded --owner evstack
occurrences with the repo owner expression (e.g. use ${{ github.repository_owner
}} either inline or set OWNER="${{ github.repository_owner }}" and use --owner
"$OWNER") so PROJECT_ID, FIELD_ID, OPTION_ID lookups and the gh project
item-edit call are portable if the repo is transferred/forked.

i️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 80b4b4c and e10c1e7.

📒 Files selected for processing (1)
  • .github/workflows/add-to-project.yml

name: Add to project
runs-on: ubuntu-latest
steps:
- uses: actions/add-to-project@v1.0.2
Copy link

@coderabbitai coderabbitai bot Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n .github/workflows/add-to-project.yml | head -20

Repository: evstack/ev-metrics

Length of output: 642


🏁 Script executed:

# Check if we can find any information about the actions/add-to-project repository
# Look for any documentation or references in the codebase
rg "actions/add-to-project" -A 2 -B 2

Repository: evstack/ev-metrics

Length of output: 44


🌐 Web query:

actions/add-to-project v1.0.2 commit SHA github

💡 Result:

actions/add-to-project@v1.0.2 resolves to commit SHA:

244f685bbc3b7adfa8466e08b698b5577571133e [1]


🌐 Web query:

actions/add-to-project v1.0.2 release tag github 244f685bbc3b7adfa8466e08b698b5577571133e

💡 Result:

The actions/add-to-project v1.0.2 GitHub release/tag points to commit 244f685bbc3b7adfa8466e08b698b5577571133e (short SHA 244f685). The release was published June 24, 2024. [1][2]


🌐 Web query:

actions/add-to-project releases page v1.0.2 commit

💡 Result:

actions/add-to-project@v1.0.2 points to commit 244f685bbc3b7adfa8466e08b698b5577571133e (short SHA 244f685). [1][2]

Sources:
[1] https://github.com/actions/add-to-project/releases
[2] actions/add-to-project@244f685


Pin actions/add-to-project to a full commit SHA.

Release tags are mutable and a malicious actor can override them. Pinning an action to a full-length commit SHA is currently the only way to use an action as an immutable release.

🔒 Proposed fix — pin to commit SHA with tag comment
- - uses: actions/add-to-project@v1.0.2
+ - uses: actions/add-to-project@244f685bbc3b7adfa8466e08b698b5577571133e # v1.0.2
📝 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.

Suggested change
- uses: actions/add-to-project@v1.0.2
- uses: actions/add-to-project@244f685bbc3b7adfa8466e08b698b5577571133e #v1.0.2
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/add-to-project.yml at line 12, The workflow currently
references the action with a mutable tag "actions/add-to-project@v1.0.2";
replace that tag with the action's immutable full commit SHA (e.g.,
actions/add-to-project@<full-commit-sha>) to pin the action to a specific
commit, fetching the correct SHA from the action repository's commit history and
updating the uses line accordingly so the workflow uses the fixed commit instead
of a mutable tag.

Comment on lines +22 to +38
run: |
# Get the field and option IDs for Area=devx
PROJECT_ID=$(gh project list --owner evstack --format json \
| jq -r '.projects[] | select(.number==7) | .id')

FIELD_ID=$(gh project field-list "$PROJECT_ID" --owner evstack --format json \
| jq -r '.fields[] | select(.name=="Area") | .id')

OPTION_ID=$(gh project field-list "$PROJECT_ID" --owner evstack --format json \
| jq -r '.fields[] | select(.name=="Area") | .options[] | select(.name=="devx") | .id')

gh project item-edit \
--owner evstack \
--project-number 7 \
--id "$ITEM_ID" \
--field-id "$FIELD_ID" \
--single-select-option-id "$OPTION_ID"
Copy link

@coderabbitai coderabbitai bot Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Add empty-variable guards to surface actionable errors.

jq -r exits 0 even when a filter matches nothing (returns empty string). Because of this, FIELD_ID or OPTION_ID being empty won't trigger the default -e exit, so a name mismatch (e.g., field is not literally "Area", option is not literally "devx") will silently pass empty strings to the downstream commands and produce cryptic gh errors rather than a clear diagnostic.
Error-checking patterns like testing whether an ID variable is empty and exiting with an explicit message are a commonly used safeguard in these workflows.

🛡️ Proposed fix — add guards after each ID resolution
 PROJECT_ID=$(gh project list --owner evstack --format json \
 | jq -r '.projects[] | select(.number==7) | .id')
+ [ -z "$PROJECT_ID" ] && { echo "Error: project 7 not found"; exit 1; }
 FIELD_ID=$(gh project field-list "$PROJECT_ID" --owner evstack --format json \
 | jq -r '.fields[] | select(.name=="Area") | .id')
+ [ -z "$FIELD_ID" ] && { echo "Error: 'Area' field not found"; exit 1; }
- OPTION_ID=$(gh project field-list "$PROJECT_ID" --owner evstack --format json \
+ OPTION_ID=$(gh project field-list "$PROJECT_ID" --owner evstack --format json \ # reuse cached output — see refactor comment
 | jq -r '.fields[] | select(.name=="Area") | .options[] | select(.name=="devx") | .id')
+ [ -z "$OPTION_ID" ] && { echo "Error: 'devx' option not found in 'Area' field"; exit 1; }
📝 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.

Suggested change
run: |
# Get the field and option IDs for Area=devx
PROJECT_ID=$(gh project list --owner evstack --format json \
| jq -r '.projects[] | select(.number==7) | .id')
FIELD_ID=$(gh project field-list "$PROJECT_ID" --owner evstack --format json \
| jq -r '.fields[] | select(.name=="Area") | .id')
OPTION_ID=$(gh project field-list "$PROJECT_ID" --owner evstack --format json \
| jq -r '.fields[] | select(.name=="Area") | .options[] | select(.name=="devx") | .id')
gh project item-edit \
--owner evstack \
--project-number 7 \
--id "$ITEM_ID" \
--field-id "$FIELD_ID" \
--single-select-option-id "$OPTION_ID"
run: |
# Get the field and option IDs for Area=devx
PROJECT_ID=$(gh project list --owner evstack --format json \
| jq -r '.projects[] | select(.number==7) | .id')
[ -z "$PROJECT_ID" ] && { echo "Error: project 7 not found"; exit 1; }
FIELD_ID=$(gh project field-list "$PROJECT_ID" --owner evstack --format json \
| jq -r '.fields[] | select(.name=="Area") | .id')
[ -z "$FIELD_ID" ] && { echo "Error: 'Area' field not found"; exit 1; }
OPTION_ID=$(gh project field-list "$PROJECT_ID" --owner evstack --format json \ # reuse cached output — see refactor comment
| jq -r '.fields[] | select(.name=="Area") | .options[] | select(.name=="devx") | .id')
[ -z "$OPTION_ID" ] && { echo "Error: 'devx' option not found in 'Area' field"; exit 1; }
gh project item-edit \
--owner evstack \
--project-number 7 \
--id "$ITEM_ID" \
--field-id "$FIELD_ID" \
--single-select-option-id "$OPTION_ID"
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/add-to-project.yml around lines 22 - 38, After resolving
PROJECT_ID, FIELD_ID and OPTION_ID, add empty-variable guards that test each
(e.g., [ -z "$PROJECT_ID" ], [ -z "$FIELD_ID" ], [ -z "$OPTION_ID" ]) and when
empty print a clear error to stderr (describing which lookup failed, e.g.,
"failed to find Project ID for number 7", "failed to find field 'Area'", "failed
to find option 'devx'") and exit non‐zero; place these checks immediately after
the assignments for PROJECT_ID, FIELD_ID and OPTION_ID so the subsequent gh
project item-edit call never runs with empty IDs.

Comment on lines +33 to +38
gh project item-edit \
--owner evstack \
--project-number 7 \
--id "$ITEM_ID" \
--field-id "$FIELD_ID" \
--single-select-option-id "$OPTION_ID"
Copy link

@coderabbitai coderabbitai bot Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🌐 Web query:

gh project item-edit flags documentation GitHub CLI official

💡 Result:

Official docs for gh project item-edit (including the full list of flags/options) are in the GitHub CLI manual: gh_project_item-edit. (cli.github.com)

It lists these flags/options (among others): --id, --project-id, --field-id, --text, --number, --date, --iteration-id, --single-select-option-id, and --clear. (cli.github.com)

Citations:


gh project item-edit does not accept --project-number or --owner — this step will always fail at runtime.

The gh project item-edit command only supports flags like --id, --project-id, --field-id, and --single-select-option-id. Using --project-number or --owner will produce an "unknown flag" error. Since PROJECT_ID is already resolved above, replace the invalid flags with --project-id "$PROJECT_ID".

🐛 Proposed fix
 gh project item-edit \
- --owner evstack \
- --project-number 7 \
 --id "$ITEM_ID" \
+ --project-id "$PROJECT_ID" \
 --field-id "$FIELD_ID" \
 --single-select-option-id "$OPTION_ID"
📝 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.

Suggested change
gh project item-edit \
--owner evstack \
--project-number 7 \
--id "$ITEM_ID" \
--field-id "$FIELD_ID" \
--single-select-option-id "$OPTION_ID"
gh project item-edit \
--id "$ITEM_ID" \
--project-id "$PROJECT_ID" \
--field-id "$FIELD_ID" \
--single-select-option-id "$OPTION_ID"
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/add-to-project.yml around lines 33 - 38, The gh project
item-edit invocation uses unsupported flags (--project-number and --owner) and
will fail; update the gh project item-edit call to use the resolved PROJECT_ID
by replacing the invalid flags with --project-id "$PROJECT_ID" while keeping the
existing --id, --field-id and --single-select-option-id flags (i.e., call gh
project item-edit with --project-id "$PROJECT_ID" --id "$ITEM_ID" --field-id
"$FIELD_ID" --single-select-option-id "$OPTION_ID").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@coderabbitai coderabbitai[bot] coderabbitai[bot] left review comments

@chatton chatton Awaiting requested review from chatton

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

AltStyle によって変換されたページ (->オリジナル) /