-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
CI: Provide basic CI jobs for forked repositories, and disable our own jobs #32632
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: next
Are you sure you want to change the base?
CI: Provide basic CI jobs for forked repositories, and disable our own jobs #32632
Conversation
View your CI Pipeline Execution ↗ for commit bfb21d2
☁️ Nx Cloud last updated this comment at |
46016c7
to
f4d9dfd
Compare
📝 WalkthroughWalkthroughAdds repository-owner gating (github.repository_owner == 'storybookjs') to many GitHub Actions jobs, introduces a new fork-only workflow that runs on non-storybook forks, and makes minor documentation, formatting, Prettier-ignore, JSON, and linting-comment changes. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Event as GitHub Event
participant WF as Workflow
participant Jobs as Jobs
rect rgba(230,240,255,0.35)
note over WF: Owner-gated workflows
Event->>WF: schedule / push / pull_request
WF->>WF: evaluate github.repository_owner == 'storybookjs'
alt owner == 'storybookjs'
WF->>Jobs: run gated jobs (publish, stale, triage, tests, generate-sandboxes, etc.)
else owner != 'storybookjs'
WF--xJobs: skip gated jobs
end
end
rect rgba(235,255,235,0.35)
note over WF: Fork-only workflow
Event->>WF: push (fork)
WF->>WF: evaluate github.repository_owner != 'storybookjs'
alt owner != 'storybookjs'
WF->>Jobs: run fork-checks (type-check, formatting, unit tests on Ubuntu/Windows)
else owner == 'storybookjs'
WF--xJobs: skip fork checks
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
🔇 Additional comments (1)
Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
CONTRIBUTING.md (1)
173-177
: Fix broken shell command (too many arguments to cd)The example concatenates two commands into one line; it will fail. Split into two lines.
-```shell -cd code yarn build --watch react core-server api addon-docs -``` +```shell +cd code +yarn build --watch react core-server api addon-docs +```
🧹 Nitpick comments (7)
.github/workflows/prepare-patch-release.yml (1)
21-21
: Owner-gate LGTM; consider explicit minimal permissionsThe repo-owner check is correct. Optionally harden the workflow by setting explicit, minimal GITHUB_TOKEN permissions.
Example (top-level):
on: push: branches: - next workflow_dispatch: +permissions: + contents: read + actions: read.github/workflows/cron-weekly.yml (1)
12-13
: Pin third-party actions to a commit SHATo reduce supply-chain risk, pin external actions (checkout, markdown-link-check) to immutable SHAs instead of tags.
.github/workflows/stale.yml (1)
6-12
: Set explicit permissions for the stale actionactions/stale needs write scopes to label/close. Define minimal permissions at workflow/job level to avoid relying on defaults.
Example (top-level):
on: schedule: - cron: "30 1 * * *" +permissions: + issues: write + pull-requests: write + contents: read.github/workflows/trigger-circle-ci-workflow.yml (2)
1-16
: Harden pull_request_target workflow permissionsGiven this uses pull_request_target and triggers external systems, set minimal GITHUB_TOKEN permissions.
Example (top-level):
name: Trigger CircleCI workflow on: pull_request_target: types: [opened, synchronize, labeled, reopened] push: branches: - next - main +permissions: + contents: read + pull-requests: read + actions: read
62-68
: Pin external action to a SHAPin fjogeleit/http-request-action to a commit SHA for supply-chain safety.
code/frameworks/angular/start-schema.json (1)
149-152
: loglevel description vs validation mismatchDescription includes “error” but the pattern excludes it. Include error to avoid rejecting valid values.
- "pattern": "(silly|verbose|info|warn|silent)" + "pattern": "^(silly|verbose|info|warn|error|silent)$"code/frameworks/angular/build-schema.json (1)
33-36
: loglevel description vs validation mismatchAllow “error” to match the documented options.
- "pattern": "(silly|verbose|info|warn|silent)" + "pattern": "^(silly|verbose|info|warn|error|silent)$"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (18)
.github/workflows/cron-weekly.yml
(1 hunks).github/workflows/fork-checks.yml
(1 hunks).github/workflows/generate-sandboxes.yml
(2 hunks).github/workflows/handle-release-branches.yml
(3 hunks).github/workflows/prepare-non-patch-release.yml
(1 hunks).github/workflows/prepare-patch-release.yml
(1 hunks).github/workflows/publish.yml
(2 hunks).github/workflows/stale.yml
(1 hunks).github/workflows/tests-unit.yml
(1 hunks).github/workflows/triage.yml
(1 hunks).github/workflows/trigger-circle-ci-workflow.yml
(3 hunks)CONTRIBUTING.md
(1 hunks)code/.prettierignore
(1 hunks)code/frameworks/angular/build-schema.json
(5 hunks)code/frameworks/angular/start-schema.json
(6 hunks)code/frameworks/server-webpack5/template/cli/page.stories.yaml
(1 hunks)code/frameworks/sveltekit/tsconfig.json
(1 hunks)code/lib/eslint-plugin/docs/rules/no-stories-of.md
(0 hunks)
💤 Files with no reviewable changes (1)
- code/lib/eslint-plugin/docs/rules/no-stories-of.md
🧰 Additional context used
📓 Path-based instructions (1)
code/**/tsconfig*.json
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Keep TypeScript strict mode enabled; do not relax strict compiler options in tsconfig files
Files:
code/frameworks/sveltekit/tsconfig.json
🪛 actionlint (1.7.7)
.github/workflows/fork-checks.yml
48-48: label "windows-11-arm" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2025", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-24.04-arm", "ubuntu-22.04", "ubuntu-22.04-arm", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Core Unit Tests, windows-latest
🔇 Additional comments (7)
.github/workflows/cron-weekly.yml (1)
9-9
: Owner-gate LGTMThis prevents scheduled runs on forks. Looks good.
.github/workflows/stale.yml (1)
9-9
: Owner-gate LGTMPrevents stale bot from operating on forks. Good.
.github/workflows/trigger-circle-ci-workflow.yml (1)
19-19
: Owner-gates LGTMGating all CircleCI trigger jobs on the org owner is correct and avoids secret exposure on forks.
Also applies to: 41-41, 60-60
code/frameworks/angular/start-schema.json (1)
96-100
: Formatting-only changes LGTMSingle-line arrays and trailing newline are fine; no behavior change.
Also applies to: 135-138, 140-143, 154-157, 196-197, 224-225, 233-233
code/frameworks/angular/build-schema.json (1)
70-74
: Formatting-only changes LGTMArray compaction and newline tweak look good; behavior unchanged.
Also applies to: 76-79, 81-84, 119-122, 161-162, 189-190, 198-198
.github/workflows/handle-release-branches.yml (1)
8-8
: Owner-gates LGTMKeeps release-branch handling limited to the org; safe given secrets and external hooks.
Also applies to: 72-72, 91-91
CONTRIBUTING.md (1)
132-140
: Fork/upstream guidance LGTMClearer upstream setup; removing “disable Actions on forks” aligns with new fork CI.
Package BenchmarksCommit: No significant changes detected, all good. 👏 |
|
||
import { addons } from 'storybook/manager-api'; | ||
|
||
/* eslint-disable prettier/prettier */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is questionable. To make sure prettier doesn't mess with our sensitive files in forked repos, we need to actually add them to prettierignore.
But this is a less good setup for us where we know internally that specific bits of the files should be ignored, but still want automatic formatting on the rest of the files through ESLint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is prettierignore better for forks here?
Is it because forks run prettier directly instead of via eslint? If so, can we just add a prettierignore comment as well as the existing eslint comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly. See how our command uses eslint-disable
to prevent prettifying? We don't appear to be running prettier directly in the monorepo. If we don't ignore the file in prettier, the file's content changes when running prettier. So actually ignoring the file results in stronger protection (at the expense of no longer having ESLint format the rest).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(btw I meant that my code change was questionable, not the original code ;-) so thanks for questioning it!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great idea!
- name: prettier | ||
run: cd code && yarn lint:prettier --check . | ||
|
||
test-windows: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we use an Actions strategy pattern instead for Windows+Ubuntu tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea!
- Switch to strategy matrix
|
||
import { addons } from 'storybook/manager-api'; | ||
|
||
/* eslint-disable prettier/prettier */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is prettierignore better for forks here?
Is it because forks run prettier directly instead of via eslint? If so, can we just add a prettierignore comment as well as the existing eslint comment?
TO DO
What I did
code/
to ensure the prettier job provided to fork repo owners provides actual feedback on their code changesThis should help ensure that forked repositories have a coherent CI status, that actually reflects code quality issues rather than CI setup shenanigans. If forked repos have code quality reporting, there's a wee chance this increases the quality of received PRs.
Checklist for Contributors
Testing
The changes in this PR are covered in the following automated tests:
ø
Manual testing
Documentation
Checklist for Maintainers
When this PR is ready for testing, make sure to add
ci:normal
,ci:merged
orci:daily
GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found incode/lib/cli-storybook/src/sandbox-templates.ts
Make sure this PR contains one of the labels below:
Available labels
bug
: Internal changes that fixes incorrect behavior.maintenance
: User-facing maintenance tasks.dependencies
: Upgrading (sometimes downgrading) dependencies.build
: Internal-facing build tooling & test updates. Will not show up in release changelog.cleanup
: Minor cleanup style change. Will not show up in release changelog.documentation
: Documentation only changes. Will not show up in release changelog.feature request
: Introducing a new feature.BREAKING CHANGE
: Changes that break compatibility in some way with current major version.other
: Changes that don't fit in the above categories.🦋 Canary release
This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the
@storybookjs/core
team here.core team members can create a canary release here or locally with
gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>
Summary by CodeRabbit