ci: restructure CI workflow for parallel jobs and improved build process#7135
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughSplit the CI into multiple parallel jobs with artifact handoffs (build, storybook, pack, tests, website, VR, deploy). Moved tgz_name output to the new pack job. package.json prebuild no longer runs lint; added check-types-lib and updated check-types. Playwright CT config paths, reporters, aliases, and workers adjusted. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant GH as GitHub Actions
participant Build as Build Job
participant Storybook as Storybook Job
participant Pack as Pack Job
participant Integration as Integration Tests
participant VR as VR Tests
participant MergeVR as merge_vr_reports
participant Website as Website Job
participant Deploy as Deploy Staging
GH->>Build: start build
Build->>GH: upload artifact (build-output) rgba(70,130,180,0.5)
GH->>Storybook: start storybook job
Storybook->>GH: upload artifact (storybook) rgba(34,139,34,0.5)
GH->>Pack: start pack (downloads build-output)
Pack->>GH: emit output tgz_name + upload tgz rgba(255,165,0,0.5)
GH->>Integration: integration_tests downloads pack.tgz (tgz_name) rgba(128,0,128,0.5)
GH->>VR: vr_tests matrix runs (depends on build) rgba(199,21,133,0.5)
VR->>GH: upload per-browser vr-blob-report rgba(199,21,133,0.5)
GH->>MergeVR: merge_vr_reports collects blobs
MergeVR->>GH: upload merged vr-report rgba(148,0,211,0.5)
GH->>Website: website downloads build + storybook, computes BASE_URL, builds site rgba(0,128,128,0.5)
Website->>Deploy: deploy_staging gated on website + merged vr-report rgba(220,20,60,0.5)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 |
Bundle ReportBundle size has no change ✅ |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/workflows/ci.yml (2)
415-415:vr_testswaits forbuildbut still rebuilds locally.Line 415 introduces
needs: [build], but this job rebuilds on Line 433 and again viatest-vr:prepareon Line 448. This likely adds avoidable CI wall time.Options to remove duplicate work
- needs: [build] + # Remove if this job does not consume build artifactsAnd if you keep the dependency, consider removing one of the two local build invocations in this job path.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci.yml at line 415, The vr_tests job currently declares a dependency on the build job (needs: [build]) but still runs local builds twice (a local build invocation inside the vr_tests job and another in the test-vr:prepare job), causing duplicate work; fix by keeping the dependency and removing the redundant local build commands (delete the local build step(s) inside the vr_tests job or inside test-vr:prepare), or alternatively remove the needs: [build] if you intend vr_tests to perform its own build — specifically edit the vr_tests job and/or the test-vr:prepare job to ensure only one build step remains (remove the extra "yarn build"/"npm run build" run step or equivalent).
257-257:websiteis gated bybuildwithout consuming its artifact.Line 257 adds
buildas a dependency, but this job only consumes Storybook output (Lines 287-291). That serializes the pipeline without a data dependency.Possible simplification
- needs: [build, storybook] + needs: [storybook]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci.yml at line 257, The website job lists build in its needs array but never consumes build's artifacts—only Storybook's—creating unnecessary serialization; update the needs for the website job (the job named "website") to remove "build" and depend only on "storybook", or alternatively add explicit artifact download steps to consume build's output if that dependency is really required; adjust the needs array in the CI workflow so "website" only depends on the jobs whose artifacts it actually uses (e.g., "storybook") or add artifact consumption for "build".
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/ci.yml:
- Line 415: The vr_tests job currently declares a dependency on the build job
(needs: [build]) but still runs local builds twice (a local build invocation
inside the vr_tests job and another in the test-vr:prepare job), causing
duplicate work; fix by keeping the dependency and removing the redundant local
build commands (delete the local build step(s) inside the vr_tests job or inside
test-vr:prepare), or alternatively remove the needs: [build] if you intend
vr_tests to perform its own build — specifically edit the vr_tests job and/or
the test-vr:prepare job to ensure only one build step remains (remove the extra
"yarn build"/"npm run build" run step or equivalent).
- Line 257: The website job lists build in its needs array but never consumes
build's artifacts—only Storybook's—creating unnecessary serialization; update
the needs for the website job (the job named "website") to remove "build" and
depend only on "storybook", or alternatively add explicit artifact download
steps to consume build's output if that dependency is really required; adjust
the needs array in the CI workflow so "website" only depends on the jobs whose
artifacts it actually uses (e.g., "storybook") or add artifact consumption for
"build".
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 67f7b734-9dc8-460f-b050-f1ba052047ec
📒 Files selected for processing (2)
.github/workflows/ci.ymlpackage.json
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #7135 +/- ##
=======================================
Coverage 89.59% 89.59%
=======================================
Files 536 536
Lines 40401 40401
Branches 5498 5499 +1
=======================================
Hits 36197 36197
Misses 4196 4196
Partials 8 8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/ci.yml (1)
5-8:⚠️ Potential issue | 🟠 MajorNarrow default workflow token permissions to least privilege.
pull-requests: writeat workflow scope gives every job write-level PR permissions, even jobs that only build/test. Keep write scope only in jobs that actually comment/update PRs.🔒 Suggested least-privilege change
permissions: contents: read - pull-requests: write🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci.yml around lines 5 - 8, The workflow-wide permissions block currently grants pull-requests: write; change the default workflow permissions to the least privilege by removing or setting pull-requests to none under the top-level permissions key (i.e., update the permissions block that contains "contents" and "pull-requests"), and then add a job-level permissions override only in the job(s) that need to modify or comment on PRs by setting permissions: pull-requests: write in that job; ensure all other jobs inherit the restricted default to avoid unnecessary write access.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In @.github/workflows/ci.yml:
- Around line 5-8: The workflow-wide permissions block currently grants
pull-requests: write; change the default workflow permissions to the least
privilege by removing or setting pull-requests to none under the top-level
permissions key (i.e., update the permissions block that contains "contents" and
"pull-requests"), and then add a job-level permissions override only in the
job(s) that need to modify or comment on PRs by setting permissions:
pull-requests: write in that job; ensure all other jobs inherit the restricted
default to avoid unnecessary write access.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: cb45d96d-0e7a-4f64-b4e3-0bed68e8b910
📒 Files selected for processing (2)
.github/workflows/ci.ymlpackage.json
🚧 Files skipped from review as they are similar to previous changes (1)
- package.json
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/ci.yml (1)
325-329:⚠️ Potential issue | 🟡 MinorMake the Storybook copy step idempotent.
mkdir www/docs/storybook-staticfails if the directory already exists. Use-pto avoid brittle reruns/retries.Suggested fix
- name: Copy storybook to docs folder run: | - mkdir www/docs/storybook-static + mkdir -p www/docs/storybook-static cp -r storybook/public/* www/docs/storybook-static/🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci.yml around lines 325 - 329, The "Copy storybook to docs folder" CI step is brittle because mkdir www/docs/storybook-static fails if the directory exists; update this step to create the directory idempotently by using mkdir -p for www/docs/storybook-static (and keep the existing cp -r storybook/public/* www/docs/storybook-static/ command) so repeated runs/retries don't fail; locate the step by its name "Copy storybook to docs folder" and the commands invoking mkdir and cp to apply the change.
🤖 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/ci.yml:
- Around line 179-191: The Chromatic publish step should not block downstream
artifact consumers — move the Chromatic action out of the storybook job into its
own job (e.g., job name "chromatic") that has needs: [storybook] so it runs
after storybook but is not a prerequisite for website or deploy_staging; update
the existing Chromatic step (and the duplicate at lines ~276-279) to that new
job and keep the same with: options (projectToken, skip) and conditional on
env.ENCRYPTED_CHROMATIC_TOKEN so failures in Chromatic won’t fail the storybook
job or prevent website/deploy_staging from running.
- Line 184: The CI workflow step using chromaui/action@latest is
non-deterministic; replace the floating tag by pinning to a specific immutable
commit SHA or a fixed major version (e.g., chromaui/action@vX) to ensure
reproducible builds—locate the step with the uses: chromaui/action@latest
reference in the .github/workflows/ci.yml and update it to the chosen commit SHA
or stable version tag.
---
Outside diff comments:
In @.github/workflows/ci.yml:
- Around line 325-329: The "Copy storybook to docs folder" CI step is brittle
because mkdir www/docs/storybook-static fails if the directory exists; update
this step to create the directory idempotently by using mkdir -p for
www/docs/storybook-static (and keep the existing cp -r storybook/public/*
www/docs/storybook-static/ command) so repeated runs/retries don't fail; locate
the step by its name "Copy storybook to docs folder" and the commands invoking
mkdir and cp to apply the change.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 556cd354-a871-4f4c-917d-dc7e795f1388
📒 Files selected for processing (1)
.github/workflows/ci.yml
| # Chromatic gives us only this many free credits per month | ||
| # so let's publish only at the end so that we don't waste them when we know we can't merge from the previous steps anyway. | ||
| - name: Publish visual regression tests to Chromatic | ||
| if: ${{ env.ENCRYPTED_CHROMATIC_TOKEN }} | ||
| # Chromatic action from https://www.chromatic.com/docs/github-actions | ||
| uses: chromaui/action@latest | ||
| # Chromatic GitHub Action options | ||
| with: | ||
| # 👇 Chromatic projectToken, refer to the manage page to obtain it. | ||
| projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }} | ||
| # Let's say that we don't want to use our Chromatic credits for PRs from dependabot | ||
| skip: 'dependabot/**' | ||
|
|
There was a problem hiding this comment.
Decouple Chromatic publishing from the storybook job’s success path.
Right now, a failure in the final Chromatic step fails storybook, which then skips website (it needs: [build, storybook]) and blocks deploy_staging. That undermines the flaky-rerun goal because a non-artifact step can block downstream artifact consumers.
Suggested adjustment
- name: Publish visual regression tests to Chromatic
if: ${{ env.ENCRYPTED_CHROMATIC_TOKEN }}
+ continue-on-error: true
# Chromatic action from https://www.chromatic.com/docs/github-actions
uses: chromaui/action@latestAlso applies to: 276-279
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/ci.yml around lines 179 - 191, The Chromatic publish step
should not block downstream artifact consumers — move the Chromatic action out
of the storybook job into its own job (e.g., job name "chromatic") that has
needs: [storybook] so it runs after storybook but is not a prerequisite for
website or deploy_staging; update the existing Chromatic step (and the duplicate
at lines ~276-279) to that new job and keep the same with: options
(projectToken, skip) and conditional on env.ENCRYPTED_CHROMATIC_TOKEN so
failures in Chromatic won’t fail the storybook job or prevent
website/deploy_staging from running.
| - name: Publish visual regression tests to Chromatic | ||
| if: ${{ env.ENCRYPTED_CHROMATIC_TOKEN }} | ||
| # Chromatic action from https://www.chromatic.com/docs/github-actions | ||
| uses: chromaui/action@latest |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Floating action refs:"
rg -nP 'uses:\s*[^#\s]+@latest\b'
echo
echo "Non-immutable action refs (consider pinning to commit SHA):"
rg -nP 'uses:\s*[^#\s]+@(main|master|latest|next|beta|v?\d+)\b'Repository: recharts/recharts
Length of output: 82
🏁 Script executed:
sed -n '180,190p' .github/workflows/ci.ymlRepository: recharts/recharts
Length of output: 735
Pin the chromaui/action to a specific commit SHA or major version.
uses: chromaui/action@latest at line 184 is non-deterministic and can break CI unexpectedly due to untracked changes or security vulnerabilities in newer versions. Pin to a specific immutable commit SHA (preferred) or at least a fixed major version tag.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/ci.yml at line 184, The CI workflow step using
chromaui/action@latest is non-deterministic; replace the floating tag by pinning
to a specific immutable commit SHA or a fixed major version (e.g.,
chromaui/action@vX) to ensure reproducible builds—locate the step with the uses:
chromaui/action@latest reference in the .github/workflows/ci.yml and update it
to the chosen commit SHA or stable version tag.
|
Staging Deployment Details
These deployments will remain available for 30 days. To update snapshots: Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
.github/workflows/ci.yml (1)
186-190:⚠️ Potential issue | 🟠 MajorChromatic is still a blocking and non-deterministic step in
storybook.Line 186-190 keeps Chromatic inside
storybookand useschromaui/action@latest; this can both block downstream jobs on Chromatic flake and introduce unreproducible CI behavior.Suggested minimal hardening
- name: Publish visual regression tests to Chromatic if: ${{ env.ENCRYPTED_CHROMATIC_TOKEN }} + continue-on-error: true - uses: chromaui/action@latest + uses: chromaui/action@<pinned-commit-sha-or-fixed-major>#!/bin/bash set -euo pipefail echo "Chromatic step and ref:" rg -nP 'Publish visual regression tests to Chromatic|uses:\s*chromaui/action@' .github/workflows/ci.yml -A3 -B2 echo echo "Downstream dependency on storybook:" rg -nP '^\s*website:|^\s*needs:\s*\[build,\s*storybook\]' .github/workflows/ci.yml -A2 -B1🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci.yml around lines 186 - 190, The Chromatic step "Publish visual regression tests to Chromatic" currently uses chromaui/action@latest inside the storybook job and blocks downstream jobs; fix this by extracting that step into its own job (e.g., a "chromatic" job) that depends on storybook but is not required for critical downstream jobs, or make the step non-blocking by setting continue-on-error: true; also stop using chromaui/action@latest and pin the action to a stable version (replace chromaui/action@latest with a specific version tag) and keep the existing if: condition on the ENCRYPTED_CHROMATIC_TOKEN to preserve gating.
🤖 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/ci.yml:
- Around line 533-535: The deploy_staging job currently attempts an
unconditional download of the vr-report artifact which will fail if
merge_vr_reports didn't upload it; update the download step in deploy_staging to
tolerate missing artifacts by adding if-no-files-found: ignore to the
download-artifact action (or wrap the step with a conditional that checks
needs.merge_vr_reports.result == 'success') so deployment can proceed when
merge_vr_reports failed; refer to the deploy_staging job and the
download-artifact step for the exact location to change and the artifact name
vr-report.
In `@package.json`:
- Around line 34-35: The "check-types" npm script incorrectly invokes the npm
script check-types-lib as a shell command; update the "check-types" script to
call "npm run check-types-lib" (matching how the other scripts are invoked) so
npm resolves the script correctly; specifically modify the "check-types" entry
to use npm run before check-types-lib while keeping the rest of the chain ("npm
run check-types-test", "npm run check-types-storybook", "npm run
check-types-website") unchanged.
---
Duplicate comments:
In @.github/workflows/ci.yml:
- Around line 186-190: The Chromatic step "Publish visual regression tests to
Chromatic" currently uses chromaui/action@latest inside the storybook job and
blocks downstream jobs; fix this by extracting that step into its own job (e.g.,
a "chromatic" job) that depends on storybook but is not required for critical
downstream jobs, or make the step non-blocking by setting continue-on-error:
true; also stop using chromaui/action@latest and pin the action to a stable
version (replace chromaui/action@latest with a specific version tag) and keep
the existing if: condition on the ENCRYPTED_CHROMATIC_TOKEN to preserve gating.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 51fa6c1c-e7cb-4007-b6fd-5dbf0f1b4abe
📒 Files selected for processing (3)
.github/workflows/ci.ymlpackage.jsontest-vr/playwright-ct.config.ts
| # Since the merge_vr_reports job will fail when tests fail, | ||
| # the deploy_staging job will be skipped. To achieve your intended behavior, you need to explicitly allow deploy_staging to run when merge_vr_reports fails. | ||
| if: always() && needs.website.result == 'success' && (needs.merge_vr_reports.result == 'success' || needs.merge_vr_reports.result == 'failure') |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Deploy condition:"
rg -n 'if:\s*always\(\).*needs\.merge_vr_reports\.result' .github/workflows/ci.yml -A1 -B2
echo
echo "VR artifact download in deploy_staging:"
rg -n 'name:\s*Download VR report artifact|name:\s*vr-report' .github/workflows/ci.yml -A4 -B2Repository: recharts/recharts
Length of output: 1037
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== merge_vr_reports job definition ==="
rg -n 'merge_vr_reports:' .github/workflows/ci.yml -A 50 | head -70
echo
echo "=== Check for if-no-files-found in artifact downloads ==="
rg -n 'if-no-files-found' .github/workflows/ci.yml -B 5 -A 2
echo
echo "=== Full deploy_staging job section ==="
rg -n 'deploy_staging:' .github/workflows/ci.yml -A 40Repository: recharts/recharts
Length of output: 2313
🌐 Web query:
actions/download-artifact default behavior when artifact does not exist
💡 Result:
actions/download-artifact fails the step by default if the requested artifact(s) don’t exist (there’s no “ignore missing” input like actions/cache has).
- If you set
with: name: my-artifactand it doesn’t exist, the action errors (e.g.Error: Unable to find an artifact with the name: …) and the step fails. [2] - If you don’t set
name, the action tries to download all artifacts for the run; if there are no artifacts, it errors (e.g.Unable to find any artifacts for the associated workflow) and the step fails. [3][1]
Workarounds: wrap the step with continue-on-error: true, or pre-check for the artifact via the API/gh and only run the download when it exists. [1]
Sources: [1] [2] [3]
The failure-tolerant condition is undermined by unconditional artifact download.
Line 535 allows deploy_staging to run when merge_vr_reports fails, but line 553-557 unconditionally download the vr-report artifact. If merge_vr_reports fails (either from test failures or merge command errors), the artifact is never uploaded. The download-artifact action fails by default when the artifact doesn't exist, causing deploy_staging to fail anyway—defeating the purpose of the failure-tolerant condition.
Make the artifact download conditional or add if-no-files-found: ignore to allow deployment to proceed even if the report is unavailable.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/ci.yml around lines 533 - 535, The deploy_staging job
currently attempts an unconditional download of the vr-report artifact which
will fail if merge_vr_reports didn't upload it; update the download step in
deploy_staging to tolerate missing artifacts by adding if-no-files-found: ignore
to the download-artifact action (or wrap the step with a conditional that checks
needs.merge_vr_reports.result == 'success') so deployment can proceed when
merge_vr_reports failed; refer to the deploy_staging job and the
download-artifact step for the exact location to change and the artifact name
vr-report.
There was a problem hiding this comment.
♻️ Duplicate comments (3)
.github/workflows/ci.yml (3)
186-190:⚠️ Potential issue | 🟠 MajorDecouple Chromatic failure from the
storybookjob success path.A transient Chromatic failure here still fails
storybook, which blockswebsite(Line 283) and thendeploy_staging. That conflicts with the flaky-rerun objective.Suggested minimal fix
- name: Publish visual regression tests to Chromatic if: ${{ env.ENCRYPTED_CHROMATIC_TOKEN }} + continue-on-error: true # Chromatic action from https://www.chromatic.com/docs/github-actions uses: chromaui/action@latest🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci.yml around lines 186 - 190, The Chromatic step "Publish visual regression tests to Chromatic" currently causes the entire storybook job to fail on transient Chromatic errors; update that step (the one using chromaui/action@latest) to allow failures by adding continue-on-error: true (or equivalent conditional that does not set job to failed) while keeping the existing if: check for env.ENCRYPTED_CHROMATIC_TOKEN so the step still runs only when the token is present; this will decouple Chromatic failures from the storybook job and avoid blocking downstream website/deploy_staging jobs.
553-557:⚠️ Potential issue | 🟠 MajorGuard VR artifact download and move to preserve failure-tolerant deploy behavior.
deploy_stagingis allowed to run whenmerge_vr_reportsfails (Line 535), but this step always downloadsvr-report, and deploy always moves../vr-report. If the artifact is missing, deployment still fails.Suggested fix
- name: Download VR report artifact + if: needs.merge_vr_reports.result == 'success' uses: actions/download-artifact@v4 with: name: vr-report path: vr-report- mv ../vr-report $TARGET_DIR/vr-tests + if [ -d ../vr-report ]; then + mv ../vr-report $TARGET_DIR/vr-tests + fiBased on learnings: In this repository, staging should still deploy website/VR report artifacts even when VR tests fail so report review remains possible.
Also applies to: 585-587
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci.yml around lines 553 - 557, Guard the "Download VR report artifact" step and the deploy step that moves "../vr-report" so missing VR artifacts don't break deploy_staging: conditionally run the "Download VR report artifact" step (the actions/download-artifact@v4 step with name "vr-report" / path "vr-report") only when the VR-report-producing job/step succeeded (e.g. add if: ${{ steps.merge_vr_reports.outcome == 'success' }} or check the producing job outcome), and add the same conditional around the deploy logic that moves ../vr-report (or make the download step continue-on-error: true and have the deploy step check the artifact exists before moving) so deploy_staging remains tolerant when merge_vr_reports fails.
189-189:⚠️ Potential issue | 🟠 MajorPin
chromaui/actionto an immutable ref.
chromaui/action@latestis non-deterministic and can introduce unexpected CI breakages. Pin to a full commit SHA (preferred) or at least a fixed major tag.What are the currently available release tags for `chromaui/action`, and which immutable commit SHA corresponds to the stable tag we should pin in GitHub Actions?🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci.yml at line 189, Replace the non-deterministic reference chromaui/action@latest in the GitHub Actions step with an immutable ref by pinning to the full commit SHA for a stable release (e.g., chromaui/action@<40-char-commit-sha>) or at minimum a fixed release tag like chromaui/[email protected]; to get the correct SHA, open the chromaui/action repo's Releases/Tags, pick the stable tag you want to lock to, click the tag to view its commit and copy the full commit SHA, then update the uses line accordingly so the workflow is pinned to that immutable commit.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/ci.yml:
- Around line 186-190: The Chromatic step "Publish visual regression tests to
Chromatic" currently causes the entire storybook job to fail on transient
Chromatic errors; update that step (the one using chromaui/action@latest) to
allow failures by adding continue-on-error: true (or equivalent conditional that
does not set job to failed) while keeping the existing if: check for
env.ENCRYPTED_CHROMATIC_TOKEN so the step still runs only when the token is
present; this will decouple Chromatic failures from the storybook job and avoid
blocking downstream website/deploy_staging jobs.
- Around line 553-557: Guard the "Download VR report artifact" step and the
deploy step that moves "../vr-report" so missing VR artifacts don't break
deploy_staging: conditionally run the "Download VR report artifact" step (the
actions/download-artifact@v4 step with name "vr-report" / path "vr-report") only
when the VR-report-producing job/step succeeded (e.g. add if: ${{
steps.merge_vr_reports.outcome == 'success' }} or check the producing job
outcome), and add the same conditional around the deploy logic that moves
../vr-report (or make the download step continue-on-error: true and have the
deploy step check the artifact exists before moving) so deploy_staging remains
tolerant when merge_vr_reports fails.
- Line 189: Replace the non-deterministic reference chromaui/action@latest in
the GitHub Actions step with an immutable ref by pinning to the full commit SHA
for a stable release (e.g., chromaui/action@<40-char-commit-sha>) or at minimum
a fixed release tag like chromaui/[email protected]; to get the correct SHA, open
the chromaui/action repo's Releases/Tags, pick the stable tag you want to lock
to, click the tag to view its commit and copy the full commit SHA, then update
the uses line accordingly so the workflow is pinned to that immutable commit.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a2673ced-3609-4121-8d0c-3ea9c50c6591
📒 Files selected for processing (1)
.github/workflows/ci.yml
|
Staging Deployment Details
These deployments will remain available for 30 days. To update snapshots: Comment |
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
|
Staging Deployment Details
These deployments will remain available for 30 days. To update snapshots: Comment |
1 participant
Description
Hopefully this will make it run a bit faster, and allow us to re-run only flaked tests instead of the whole pipeline.
Summary by CodeRabbit