ci: implement automated quality gate with eslint - #293
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🎉 Welcome to CodeLens — Thank You for Your Contribution!Hey @kunalverma2512! 👋 We are genuinely excited to have you here. Every single PR — big or small — makes CodeLens better, and yours is no exception. Take a moment to review the checklist below to help us merge your work quickly and smoothly. ✅ Before Requesting a Review
💬 Join Our Community Channel — This is MandatoryBeing part of our communication channel is compulsory for all contributors, not optional. Why join? This is where all important announcements, PR review updates, contribution discussions, and maintainer decisions happen in real time. Contributors who are not in the channel regularly miss critical context and updates, which often leads to duplicated or misaligned work. Staying connected here is what keeps the community strong and your contributions impactful. We are rooting for you! If you have any questions, drop them in the channel or comment right here on this PR. Let's build something great together. 🚀✨ |
📝 WalkthroughWalkthroughAdds frontend and backend ESLint configuration, aligns affected code with lint rules, and introduces a GitHub Actions workflow that runs dependency installation, linting, and tests for both applications. ChangesQuality Gate
Estimated code review effort: 2 (Simple) | ~15 minutes Possibly related issues
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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: 3
🧹 Nitpick comments (2)
frontend/src/components/shared/Navbar.jsx (1)
291-296: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winInclude
closeMenuin the Escape effect dependencies.The effect at Lines 298-307 calls
closeMenu, but its dependency list remains[isMenuOpen]. Use[isMenuOpen, closeMenu]; the empty-dependencyuseCallbackkeeps the callback identity stable.🤖 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 `@frontend/src/components/shared/Navbar.jsx` around lines 291 - 296, Update the Escape-key effect near toggleMenu and closeMenu to include closeMenu in its dependency array alongside isMenuOpen. Keep closeMenu memoized with its existing empty-dependency useCallback so its identity remains stable.frontend/src/components/contests/ContestReminderBell.jsx (1)
14-14: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winNarrow the inline ESLint suppression.
// eslint-disable-linedisables every rule for this line. Name the specific rule and explain why the suppression is required.🤖 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 `@frontend/src/components/contests/ContestReminderBell.jsx` at line 14, Update the inline ESLint suppression on the Date.now() declaration in ContestReminderBell to disable only the specific rule being triggered, and add a brief reason explaining why that suppression is necessary; do not leave the broad eslint-disable-line directive.
🤖 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/quality-gate.yml:
- Around line 1-11: Update both actions/checkout@v4 steps in the quality-gate
workflow to set persist-credentials to false, ensuring the workflow token is not
retained while leaving the existing npm ci, lint, and test steps unchanged.
- Around line 19-20: Disable persisted checkout credentials in both checkout
steps in .github/workflows/quality-gate.yml at lines 19-20 and 45-46 by adding
the checkout action’s with configuration with persist-credentials set to false;
no other workflow behavior should change.
- Around line 32-33: Enforce zero ESLint warnings across the quality gate:
update the lint commands in frontend/eslint.config.js, server/eslint.config.js,
and server/package.json as needed, and ensure both npm run lint invocations in
.github/workflows/quality-gate.yml fail on warnings; alternatively promote the
intentionally blocking rules to errors while preserving intentionally allowed
warnings.
---
Nitpick comments:
In `@frontend/src/components/contests/ContestReminderBell.jsx`:
- Line 14: Update the inline ESLint suppression on the Date.now() declaration in
ContestReminderBell to disable only the specific rule being triggered, and add a
brief reason explaining why that suppression is necessary; do not leave the
broad eslint-disable-line directive.
In `@frontend/src/components/shared/Navbar.jsx`:
- Around line 291-296: Update the Escape-key effect near toggleMenu and
closeMenu to include closeMenu in its dependency array alongside isMenuOpen.
Keep closeMenu memoized with its existing empty-dependency useCallback so its
identity remains stable.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 25cb12ec-3f0a-4d3b-aa3d-28d209e4f1d8
⛔ Files ignored due to path filters (1)
server/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (10)
.github/workflows/quality-gate.yml.gitignorefrontend/.gitignorefrontend/eslint.config.jsfrontend/src/components/contests/ContestReminderBell.jsxfrontend/src/components/shared/Navbar.jsxfrontend/src/utils/reminderBroadcast.test.jsserver/eslint.config.jsserver/modules/github/service.jsserver/package.json
| name: Quality Gate | ||
|
|
||
| on: | ||
| push: | ||
| branches: | ||
| - main | ||
| pull_request: | ||
| branches: | ||
| - main | ||
|
|
||
| jobs: |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Workflow file =="
if [ -f .github/workflows/quality-gate.yml ]; then
cat -n .github/workflows/quality-gate.yml
else
fd -a 'quality-gate\.yml$|quality-gate\.yaml$' .github/workflows || true
fi
echo
echo "== All workflow permissions/token-related lines =="
rg -n "permissions:|GITHUB_TOKEN|pull_request_target|contents:|id-token:|npm run lint|checkout" .github/workflows || trueRepository: kunalverma2512/CodeLens
Length of output: 2415
🌐 Web query:
GitHub Actions workflows default permissions GITHUB_TOKEN contents read actions/checkout persists credentials
💡 Result:
The GITHUB_TOKEN and its interaction with the actions/checkout action are managed as follows: 1. GITHUB_TOKEN Default Permissions: While GITHUB_TOKEN was historically permissive, GitHub has transitioned to more restrictive defaults to align with the principle of least privilege [1][2]. For new repositories, the GITHUB_TOKEN generally defaults to read-only access for the contents and packages scopes [3]. Administrators can configure these repository-level or organization-level defaults to be either read-only or permissive (read/write) [1][3]. Regardless of these defaults, you can explicitly override permissions in your workflow or job configuration using the permissions key [1][4][5]. If you specify any permission within the permissions block, all unspecified permissions are set to none [1][5]. 2. actions/checkout and persist-credentials: The actions/checkout action uses a parameter called persist-credentials, which determines whether the GITHUB_TOKEN is stored in the local git configuration of the runner [6][7][8]. Default Status: The default value for persist-credentials is true [7][8][9]. When set to true, the action configures the runner's local git environment with the token, allowing subsequent git commands in your workflow to be authenticated automatically [8]. Security Context: Because persist-credentials defaults to true, the GITHUB_TOKEN is persisted in the runner's environment (specifically in the.git/config file, or in newer versions, a separate file in $RUNNER_TEMP) [8]. To enhance security and prevent the token from being potentially exposed or reused by other processes, it is a recommended security practice to explicitly set persist-credentials: false if your workflow does not require authenticated git operations [10][8]. In summary, while the GITHUB_TOKEN itself is increasingly restricted by default, the actions/checkout action defaults to persisting that token for git authentication, requiring users to explicitly opt-out if they wish to avoid storing the credentials locally [7][8].
Citations:
- 1: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/
- 2: https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/
- 3: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository
- 4: https://docs.github.com/en/actions/tutorials/authenticate-with-github_token
- 5: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
- 6: https://github.com/actions/checkout
- 7: https://github.com/actions/checkout/blob/cbb722410c2e876e24abbe8de2cc27693e501dcb/action.yml
- 8: https://github.com/actions/checkout/tree/v6.0.2?tab=readme-ov-file
- 9: https://github.com/actions/checkout/blob/34e114876b0b11c390a56381ad16ebd13914f8d5/action.yml
- 10: Change the default value of persist-credentials to false actions/checkout#1687
Keep checkout credentials from surviving in the lint/test runner.
actions/checkout@v4 persists the workflow token by default, but this workflow never needs authenticated git commands; the remaining steps only run npm ci, npm run lint, and npm test. Add persist-credentials: false to both checkout steps.
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 1-63: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block
(excessive-permissions)
🤖 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/quality-gate.yml around lines 1 - 11, Update both
actions/checkout@v4 steps in the quality-gate workflow to set
persist-credentials to false, ensuring the workflow token is not retained while
leaving the existing npm ci, lint, and test steps unchanged.
Source: Linters/SAST tools
| - name: Checkout Code | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow files =="
git ls-files '.github/workflows/*' || true
echo
echo "== quality-gate.yml outline/contents =="
if [ -f .github/workflows/quality-gate.yml ]; then
wc -l .github/workflows/quality-gate.yml
sed -n '1,120p' .github/workflows/quality-gate.yml | cat -n
fi
echo
echo "== checkout usages in workflow =="
rg -n "actions/checkout|persist-credentials|GITHUB_TOKEN|permissions:|pull_request|jobs:" .github/workflows/quality-gate.yml || trueRepository: kunalverma2512/CodeLens
Length of output: 2161
🌐 Web query:
actions/checkout v4 persist-credentials default true README
💡 Result:
In the actions/checkout v4 action, the persist-credentials input defaults to true [1][2][3]. This setting controls whether the GitHub Actions authentication token or SSH key is configured in the local git repository's configuration [1][4][5]. When set to true (the default), the action persists these credentials, which allows your subsequent workflow steps to execute authenticated git commands directly [4][3]. The token is automatically removed during the post-job cleanup process [4][3]. If you wish to opt-out of this behavior for security or other reasons, you can explicitly set this input to false in your workflow file [4][3]: - persist-credentials: false
Citations:
- 1: https://github.com/actions/checkout/blob/v4/action.yml
- 2: https://github.com/actions/checkout/blob/v4.1.1/action.yml
- 3: https://github.com/marketplace/actions/checkout
- 4: https://github.com/actions/checkout/blob/v4/README.md
- 5: https://github.com/actions/checkout/blob/main/README.md
🌐 Web query:
GitHub Actions GITHUB_TOKEN permissions pull_request workflow workflow_dispatch README
💡 Result:
The GITHUB_TOKEN is an automatically generated, short-lived token provided to GitHub Actions workflows that allows them to authenticate with the GitHub API [1][2][3]. To adhere to security best practices, you should configure its permissions to grant only the minimum access required [1][4]. Permissions Configuration You can control the permissions of the GITHUB_TOKEN using the permissions key in your workflow YAML file, either at the top level (for the entire workflow) or within specific jobs [1][5]. When you define the permissions key, any permission not explicitly listed is set to none [3][5]. Example: permissions: contents: read issues: write Default Settings The initial permissions are determined by enterprise, organization, or repository-level settings [5]. Organizations and repositories can be configured to use either a permissive default (read/write for all scopes) or a restricted default (read-only for contents and packages) [3][6]. Special Considerations for Events 1. Pull Requests: When a workflow triggered by the GITHUB_TOKEN creates or updates a pull request, specific events (opened, synchronize, reopened) create workflow runs that require manual approval from a user with write access to the repository [7][8][2]. This prevents recursive workflow loops [8][2]. Pull requests from forked repositories always receive a read-only token, regardless of your permission settings [7][3]. 2. workflow_dispatch and repository_dispatch: These events always trigger new workflow runs, even when initiated by the GITHUB_TOKEN [7][8][2]. If you require automation that triggers workflows without manual approval or needs elevated permissions, consider using a GitHub App installation access token or a personal access token instead of the GITHUB_TOKEN [8][2].
Citations:
- 1: https://docs.github.com/en/actions/tutorials/authenticate-with-github_token
- 2: https://docs.github.com/en/actions/concepts/security/github_token
- 3: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/
- 4: https://github.com/github/docs/blob/main/content/actions/reference/security/secure-use.md
- 5: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
- 6: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository
- 7: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
- 8: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow
Disable persisted checkout credentials in both jobs.
actions/checkout@v4 persists authentication in local Git config by default, and this workflow runs PR-controlled npm ci/lint/test steps after checkout. Add with: persist-credentials: false to both checkout steps at .github/workflows/quality-gate.yml#L19-L20 and #L45-L46.
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 19-20: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
📍 Affects 1 file
.github/workflows/quality-gate.yml#L19-L20(this comment).github/workflows/quality-gate.yml#L45-L46
🤖 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/quality-gate.yml around lines 19 - 20, Disable persisted
checkout credentials in both checkout steps in
.github/workflows/quality-gate.yml at lines 19-20 and 45-46 by adding the
checkout action’s with configuration with persist-credentials set to false; no
other workflow behavior should change.
Source: Linters/SAST tools
| - name: Run Linter | ||
| run: npm run lint |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 💤 Low value
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== candidate files =="
git ls-files | rg '(^|/)(quality-gate\.yml|package\.json|eslint\.config\.js)$' || true
echo
echo "== workflow excerpts =="
sed -n '1,90p' .github/workflows/quality-gate.yml 2>/dev/null || true
echo
echo "== package scripts and eslint config excerpts =="
for f in frontend/package.json server/package.json frontend/eslint.config.js server/eslint.config.js; do
if [ -f "$f" ]; then
echo "--- $f ---"
sed -n '1,80p' "$f"
fi
done
echo
echo "== lint run references in tracked files =="
rg -n 'npm run lint|eslint|max-warnings' .github frontend server -S 2>/dev/null || trueRepository: kunalverma2512/CodeLens
Length of output: 16341
🌐 Web query:
ESLint 9 10 default max-warnings exit when warnings exceed limit configuration
💡 Result:
In ESLint 9, you can control whether ESLint exits with an error status based on the number of warnings using the --max-warnings command-line option [1][2]. Configuration and Behavior: - The --max-warnings option accepts an integer value representing the maximum number of warnings allowed [1][3]. - If the number of warnings exceeds this threshold, ESLint will exit with exit code 1 [1][3]. - The default value is -1, which means there is no limit on warnings and they will not trigger a non-zero exit code [1][2]. - There is currently no option to set --max-warnings directly within an ESLint configuration file (.eslintrc or eslint.config.js); it must be provided as a command-line argument [4]. Exit Codes in ESLint 9: - Exit code 0: Linting was successful, no errors were found, and the number of warnings is at or below the --max-warnings threshold (if set) [1][3]. - Exit code 1: Linting was successful but either at least one error was found, or the number of warnings exceeded the --max-warnings threshold [1][3]. - Exit code 2: Linting failed due to a configuration error or an internal error [1][3]. Note on --quiet: If you use --max-warnings in conjunction with the --quiet flag, rules marked as warnings will still be executed, but their output will be suppressed in the console [5][3]. Note that in ESLint 9, --quiet is more performant because it prevents rules set to "warn" from executing entirely, unless --max-warnings is also present [5][6].
Citations:
- 1: https://eslint.org/docs/latest/use/command-line-interface
- 2: https://eslint-eslint.mintlify.app/use/command-line
- 3: https://github.com/eslint/eslint/blob/f9e54f43/docs/src/use/command-line-interface.md
- 4: Add maxWarnings as a configuration option eslint/eslint#16804
- 5: https://eslint.org/docs/latest/use/migrate-to-9.0.0
- 6: https://eslint.org/blog/2024/04/eslint-v9.0.0-released/
🌐 Web query:
ESLint 8 CLI exit code rules warn default does not count as error max-warnings
💡 Result:
In ESLint 8 (and other versions), warnings do not count as errors by default and will not trigger a non-zero exit code on their own [1][2][3]. By default, ESLint only exits with a non-zero status (exit code 1) when it encounters actual errors [1][4][3]. To treat warnings as errors for the purpose of the CLI exit code, you must use the --max-warnings flag [1][2][5]. How --max-warnings works: - Default behavior: The --max-warnings option defaults to -1, which means there is no limit on warnings and they will never cause a non-zero exit code [1][5][6]. - Triggering an error: If you set --max-warnings to a specific number (n), ESLint will exit with exit code 1 if the total number of warnings exceeds that threshold [1][4][3]. - Strict mode: To make any warning trigger a non-zero exit code, you can set --max-warnings=0 [2][7]. When --max-warnings is configured and the threshold is exceeded, ESLint exits with code 1, the same code used when actual rule errors are found [1][4][3]. Note that exit code 2 is reserved for configuration issues or internal errors [1][3].
Citations:
- 1: https://eslint.org/docs/latest/use/command-line-interface
- 2: Change Request: (add eslint warnings exit code) eslint/eslint#18402
- 3: https://errors.fyi/ns/eslint/
- 4: https://github.com/eslint/eslint/blob/f9e54f43/docs/src/use/command-line-interface.md
- 5: https://archive.eslint.org/docs/7.0.0/user-guide/command-line-interface
- 6: https://archive.eslint.org/docs/user-guide/command-line-interface
- 7: https://eslint.org/blog/2023/10/eslint-v8.51.0-released/
Fail CI on lint warnings unless they are intentionally allowed.
Both lint scripts run eslint . without --max-warnings=0, and the workflow runs those scripts via npm run lint, so warnings from no-unused-vars, React-hooks rules, etc. can pass the quality gate. Enforce zero warnings in the workflow scripts (and backend) or set these rules to errors if they should block merge.
📍 Affects 4 files
.github/workflows/quality-gate.yml#L32-L33(this comment)frontend/eslint.config.js#L26-L30server/eslint.config.js#L15-L15server/package.json#L9-L10.github/workflows/quality-gate.yml#L58-L59
🤖 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/quality-gate.yml around lines 32 - 33, Enforce zero ESLint
warnings across the quality gate: update the lint commands in
frontend/eslint.config.js, server/eslint.config.js, and server/package.json as
needed, and ensure both npm run lint invocations in
.github/workflows/quality-gate.yml fail on warnings; alternatively promote the
intentionally blocking rules to errors while preserving intentionally allowed
warnings.
1 participant
Resolves (Test & Lint Enforcement)
closes #287
Changes:
server/directory..github/workflows/quality-gate.ymlto automatically runnpm run lintandnpm teston every Pull Request.Summary by CodeRabbit
Bug Fixes
Quality Improvements
Maintenance