ci: harden automated workflow and stabilize jscpd#80
Conversation
Add Bandit SAST and openenv validate to the GitHub Actions CI workflow to achieve parity with the local `validate-submission.sh` script. Pin `jscpd` to 4.0.0 and ignore `**/dist/**` to resolve false positives and platform dependency failures. Create `CYCLE_8_REPORT.md` documenting this improvement sprint. Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
There was a problem hiding this comment.
Sorry @NITISH-R-G, you have reached your weekly rate limit of 500000 diff characters.
Please try again later or upgrade to continue using Sourcery
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ 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 |
|
Failed to generate code suggestions for PR |
Greptile SummaryThis PR hardens the GitHub Actions CI pipeline by adding Bandit SAST and
Confidence Score: 4/5Safe to merge; the workflow additions are straightforward and the jscpd pinning reduces flakiness. The Bandit and OpenEnv steps are additive and well-scoped, and the jscpd pin removes a concrete source of pipeline instability. The only concerns are a redundant openenv-core entry in the explicit pip install and a Bandit step that duplicates what security.yml already does — neither causes incorrect behaviour, just minor maintenance overhead. code-quality.yml — the interaction between the new Bandit step here and the existing one in security.yml is worth a second look. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Push / PR to main] --> B[python-quality job]
A --> C[frontend-quality job]
A --> D[duplicate-code job]
A --> E[security.yml → python-security job]
B --> B1[ruff check + format]
B1 --> B2[mypy]
B2 --> B3[vulture]
B3 --> B4[radon]
B4 --> B5[bandit NEW]
B5 --> B6[pytest]
B6 --> B7[openenv validate NEW]
C --> C1[tsc --noEmit]
C1 --> C2[prettier --check]
D --> D1[npm install -g jscpd@4.0.0 PINNED]
D1 --> D2[jscpd . --ignore dist/** NEW]
E --> E1[bandit -r . -c pyproject.toml DUPLICATE]
style B5 fill:#90ee90
style B7 fill:#90ee90
style D1 fill:#90ee90
style D2 fill:#90ee90
style E1 fill:#ffe4b5
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A[Push / PR to main] --> B[python-quality job]
A --> C[frontend-quality job]
A --> D[duplicate-code job]
A --> E[security.yml → python-security job]
B --> B1[ruff check + format]
B1 --> B2[mypy]
B2 --> B3[vulture]
B3 --> B4[radon]
B4 --> B5[bandit NEW]
B5 --> B6[pytest]
B6 --> B7[openenv validate NEW]
C --> C1[tsc --noEmit]
C1 --> C2[prettier --check]
D --> D1[npm install -g jscpd@4.0.0 PINNED]
D1 --> D2[jscpd . --ignore dist/** NEW]
E --> E1[bandit -r . -c pyproject.toml DUPLICATE]
style B5 fill:#90ee90
style B7 fill:#90ee90
style D1 fill:#90ee90
style D2 fill:#90ee90
style E1 fill:#ffe4b5
Prompt To Fix All With AIFix the following 2 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 2
.github/workflows/code-quality.yml:29
**Redundant `openenv-core` in explicit install line** — `openenv-core>=0.2.3` is already a base project dependency in `pyproject.toml`, so it will be installed by the `pip install -e ".[dev,demo]"` step that follows. Listing it again on the first line is harmless but misleading: it implies the package wouldn't otherwise be present, and it can drift out of sync with the pinned version in `pyproject.toml`.
```suggestion
pip install ruff mypy pydantic vulture radon bandit
```
### Issue 2 of 2
.github/workflows/code-quality.yml:50-52
**Bandit already runs in `security.yml`** — `security.yml` has a `python-security` job that runs `bandit -r . -c pyproject.toml` on the same trigger events (`push`/`pull_request` to `main`/`master`). Adding the same scan here means every PR runs Bandit twice in parallel, consuming redundant CI minutes. If the intent is consolidation, it would be cleaner to remove the step from one workflow; if the intent is defence-in-depth, a comment explaining that would help future maintainers.
Reviews (1): Last reviewed commit: "ci: harden automated workflow and stabil..." | Re-trigger Greptile |
| run: | | ||
| python -m pip install --upgrade pip | ||
| pip install ruff mypy pydantic vulture radon | ||
| pip install ruff mypy pydantic vulture radon bandit openenv-core |
There was a problem hiding this comment.
Redundant
openenv-core in explicit install line — openenv-core>=0.2.3 is already a base project dependency in pyproject.toml, so it will be installed by the pip install -e ".[dev,demo]" step that follows. Listing it again on the first line is harmless but misleading: it implies the package wouldn't otherwise be present, and it can drift out of sync with the pinned version in pyproject.toml.
| pip install ruff mypy pydantic vulture radon bandit openenv-core | |
| pip install ruff mypy pydantic vulture radon bandit |
Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/workflows/code-quality.yml
Line: 29
Comment:
**Redundant `openenv-core` in explicit install line** — `openenv-core>=0.2.3` is already a base project dependency in `pyproject.toml`, so it will be installed by the `pip install -e ".[dev,demo]"` step that follows. Listing it again on the first line is harmless but misleading: it implies the package wouldn't otherwise be present, and it can drift out of sync with the pinned version in `pyproject.toml`.
```suggestion
pip install ruff mypy pydantic vulture radon bandit
```
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| - name: Security checks with Bandit | ||
| run: | | ||
| python -m bandit -r . -c pyproject.toml |
There was a problem hiding this comment.
Bandit already runs in
security.yml — security.yml has a python-security job that runs bandit -r . -c pyproject.toml on the same trigger events (push/pull_request to main/master). Adding the same scan here means every PR runs Bandit twice in parallel, consuming redundant CI minutes. If the intent is consolidation, it would be cleaner to remove the step from one workflow; if the intent is defence-in-depth, a comment explaining that would help future maintainers.
Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/workflows/code-quality.yml
Line: 50-52
Comment:
**Bandit already runs in `security.yml`** — `security.yml` has a `python-security` job that runs `bandit -r . -c pyproject.toml` on the same trigger events (`push`/`pull_request` to `main`/`master`). Adding the same scan here means every PR runs Bandit twice in parallel, consuming redundant CI minutes. If the intent is consolidation, it would be cleaner to remove the step from one workflow; if the intent is defence-in-depth, a comment explaining that would help future maintainers.
How can I resolve this? If you propose a fix, please make it concise.
This submission hardens the GitHub Actions CI pipeline to match the strictness of the local validation script, ensuring that code merging into the main branch cannot bypass SAST (Bandit) and OpenEnv validations.
It also fixes the frontend duplicate code detection workflow, which was previously unstable due to using an unpinned version of
jscpdand failing to ignore build artifacts (dist).jscpdis now strictly pinned to4.0.0, and thedistdirectory is ignored.A new Agile Sprint Cycle report (
CYCLE_8_REPORT.md) has been generated detailing these changes as requested in the system prompt.PR created automatically by Jules for task 4227819274363062904 started by @NITISH-R-G