Add CI format check workflow#11
Conversation
This workflow runs on all pull requests and verifies that code has been formatted using `make format`. It checks both backend (.NET) and frontend (Prettier) code in parallel jobs. Closes #8 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
📝 WalkthroughWalkthroughA GitHub Actions workflow is added to enforce code formatting standards on pull requests. The workflow runs two parallel jobs: a backend checker that uses ChangesFormat Check Workflow
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
No description provided. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
.github/workflows/format-check.yml (2)
3-8: ⚡ Quick winDeclare explicit least-privilege workflow permissions.
Add a top-level
permissionsblock so token scope is unambiguous and minimized for PR checks.🛡️ Suggested diff
on: pull_request: branches: - main +permissions: + contents: read + jobs:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/format-check.yml around lines 3 - 8, Add a top-level permissions block to the workflow (alongside the existing on: pull_request block) to explicitly declare least-privilege token scopes; update the YAML so there is a top-level permissions: mapping (not per-job) that lists only the minimal scopes your jobs need (for example start with contents: read and avoid broad defaults like write for everything), and only add additional scopes (e.g., pull-requests, checks, id-token) if a specific job requires them—adjust the mapping values accordingly and keep it adjacent to the existing on: pull_request declaration.
45-47: ⚡ Quick winRemove
--experimental-clifrom the merge-blocking formatting check.Even though Prettier 3.8.3 supports
--experimental-cli, the flag remains experimental by design. For required CI gates that block merges, use stable CLI behavior unless there's a documented requirement for the flag. The formatting check works without it.♻️ Suggested diff
- - name: Check formatting - working-directory: src/frontend - run: npx prettier --check --experimental-cli src/ + - name: Check formatting + working-directory: src/frontend + run: npx prettier --check src/🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/format-check.yml around lines 45 - 47, In the "Check formatting" workflow step, remove the experimental flag from the Prettier invocation: update the run command in the Check formatting step (the line currently containing "npx prettier --check --experimental-cli src/") to call Prettier without "--experimental-cli" so it uses stable CLI behavior (e.g., "npx prettier --check src/").
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/format-check.yml:
- Around line 14-17: The workflow uses floating major tags for actions
(actions/checkout@v4 and actions/setup-dotnet@v4 and the similar uses on lines
32-35); replace each floating tag with the corresponding full commit SHA for the
exact action release to pin the dependency, e.g., update the uses entries
(actions/checkout@v4 and actions/setup-dotnet@v4) to uses:
actions/checkout@<full-commit-sha> and uses:
actions/setup-dotnet@<full-commit-sha>, ensuring you fetch the recommended
immutable SHAs from the official action repositories and apply the same
substitution for the other occurrences referenced in the diff.
---
Nitpick comments:
In @.github/workflows/format-check.yml:
- Around line 3-8: Add a top-level permissions block to the workflow (alongside
the existing on: pull_request block) to explicitly declare least-privilege token
scopes; update the YAML so there is a top-level permissions: mapping (not
per-job) that lists only the minimal scopes your jobs need (for example start
with contents: read and avoid broad defaults like write for everything), and
only add additional scopes (e.g., pull-requests, checks, id-token) if a specific
job requires them—adjust the mapping values accordingly and keep it adjacent to
the existing on: pull_request declaration.
- Around line 45-47: In the "Check formatting" workflow step, remove the
experimental flag from the Prettier invocation: update the run command in the
Check formatting step (the line currently containing "npx prettier --check
--experimental-cli src/") to call Prettier without "--experimental-cli" so it
uses stable CLI behavior (e.g., "npx prettier --check src/").
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 793ff0ce-ec40-4acd-aecd-27ffbd11cd1e
📒 Files selected for processing (1)
.github/workflows/format-check.yml
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Setup .NET | ||
| uses: actions/setup-dotnet@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/format-check.ymlRepository: dellch/editorconfig-preview
Length of output: 1519
🌐 Web query:
GitHub Actions pinning commit SHA vs version tags security best practices
💡 Result:
Best practice: pin GitHub Actions to a full-length immutable commit SHA (not a tag like v4 or main) in your workflow uses: lines, and (optionally) configure GitHub org/repo policies to enforce SHA pinning. 1) Why commit-SHA pinning is safer than version tags - GitHub’s official security guidance says pinning to a full-length commit SHA is currently the only way to use an action as an immutable release, and that it mitigates backdoor risk (an attacker would need a SHA-1 collision for a valid Git object payload) [1][2]. - GitHub’s same guidance explains why tags are riskier even if you trust the author: “a tag can be moved or deleted” if a bad actor gains access [1][2]. 2) What to do in your workflows - Use full-length SHAs in uses: owner/repo@<full_sha>. - Prefer adding a readability comment showing the original version/tag the SHA corresponds to (example pattern shown by community guidance; GitHub’s docs emphasize SHA pinning as the security control) [3][1]. Example pattern: - Before (mutable tag): uses: actions/checkout@v4 - After (immutable pin): uses: actions/checkout@11bd719 # v4.2.2 [3][1] 3) Enforce it centrally (so teams can’t accidentally use tags) - GitHub released a policy control that lets administrators enforce SHA pinning: the policy checks for a full commit SHA, and workflows that try to use an action that isn’t pinned fail [4]. 4) Operational guidance / maintenance - Pinning to SHAs doesn’t eliminate the need to update: you should have a process/tooling (e.g., Dependabot) to bump pinned SHAs when new versions are released [1]. 5) Related nuance: don’t use short SHAs - GitHub’s security hardening documentation warns that the short version of a commit SHA is insecure and should never be used for specifying an action’s Git reference [2]. Bottom line - For supply-chain security of GitHub Actions, use full-length commit SHAs in all third-party action uses: references, and enforce this via GitHub Actions policies when possible [4][1].
Citations:
- 1: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions?learn=getting_started&learnProduct=actions
- 2: https://docs.github.com/enterprise-server@3.0/actions/security-guides/security-hardening-for-github-actions
- 3: https://dev.to/ciberconscientes/github-actions-why-you-should-pin-your-actions-to-a-specific-version-1513
- 4: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
Pin GitHub Actions to full commit SHAs instead of floating major tags.
Using @v4 leaves this workflow exposed to upstream tag drift. Pinning to immutable SHAs is GitHub's recommended security hardening practice to mitigate supply-chain risks.
🔒 Suggested hardening
- - name: Checkout code
- uses: actions/checkout@v4
+ - name: Checkout code
+ uses: actions/checkout@<full_commit_sha>
- - name: Setup .NET
- uses: actions/setup-dotnet@v4
+ - name: Setup .NET
+ uses: actions/setup-dotnet@<full_commit_sha>
- - name: Checkout code
- uses: actions/checkout@v4
+ - name: Checkout code
+ uses: actions/checkout@<full_commit_sha>
- - name: Setup Node.js
- uses: actions/setup-node@v4
+ - name: Setup Node.js
+ uses: actions/setup-node@<full_commit_sha>Also applies to: 32-35
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/format-check.yml around lines 14 - 17, The workflow uses
floating major tags for actions (actions/checkout@v4 and actions/setup-dotnet@v4
and the similar uses on lines 32-35); replace each floating tag with the
corresponding full commit SHA for the exact action release to pin the
dependency, e.g., update the uses entries (actions/checkout@v4 and
actions/setup-dotnet@v4) to uses: actions/checkout@<full-commit-sha> and uses:
actions/setup-dotnet@<full-commit-sha>, ensuring you fetch the recommended
immutable SHAs from the official action repositories and apply the same
substitution for the other occurrences referenced in the diff.
Summary
.github/workflows/format-check.ymlthat runs on pull requestsdotnet format --verify-no-changesnpx prettier --check --experimental-cli src/.nvmrcfor consistent Node.js version in CIThis enforces the
make formatconvention at the CI level so unformatted code cannot be merged.Closes #8
Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit