## Summary
Restore CI, visual testing, and Vercel preview workflows for reviewed
fork pull requests after `actions/checkout` began refusing fork code in
`pull_request_target` jobs by default.
The affected workflows now also use Node 24-compatible action releases,
and the shared Builder E2E artifact is retained long enough for delayed
failed-job reruns.
Closes#6053
## Root cause
Applying `safe-to-deploy` still triggered the intended workflows, but
each job stopped at checkout with:
> Refusing to check out fork pull request code from a
`pull_request_target` workflow.
The label is the repository's explicit human-review gate for trusted
fork code, but the checkout steps did not pass the action's new explicit
opt-in.
A later failed-job rerun also could not download `builder-e2e-build`
because its one-day retention period had elapsed. The affected
JavaScript actions additionally targeted the deprecated Node 20 action
runtime.
## Implementation
- Opt into fork checkout only when the event is `pull_request_target`
and the applied label is exactly `safe-to-deploy`.
- Apply the opt-in to Main, Chromatic, Visual Regression Tests, and
Vercel staging checkout steps.
- Gate `check-size` with the same push, regular PR, or reviewed-fork
condition as the other Main workflow jobs.
- Gate `deployment-host` so synchronize events only remove the approval
label and do not check out fork code.
- Upgrade the affected Checkout, Setup Node, pnpm setup, Cache,
artifact, GitHub Script, and Chromatic actions to Node 24-compatible
majors.
- Retain `builder-e2e-build` for seven days so delayed failed-job reruns
can download it.
- Preserve existing push and normal `pull_request` paths.
## Security tradeoff
`pull_request_target` jobs have base-repository credentials and secrets.
This change deliberately permits fork checkout only after a maintainer
applies `safe-to-deploy`; no other label or synchronize event receives
the opt-in.
## Todo
- [x] Reproduce and inspect the checkout failure on fork PR #6041.
- [x] Add explicit checkout opt-in behind the trusted label.
- [x] Gate previously unconditional jobs before enabling fork checkout.
- [x] Upgrade affected JavaScript actions to Node 24-compatible
releases.
- [x] Keep Builder E2E prerequisites available for delayed reruns.
- [x] Review documentation impact; no product documentation is affected.
- [x] Verify fixture inputs and outputs are unaffected.
- [ ] Verify the labeled fork path after this workflow version reaches
`main`.
## Verification
- `git diff --check`
- Parsed all changed workflow and composite-action YAML files with
Ruby's YAML parser.
- Verified each upgraded action manifest declares the Node 24 runtime.
- Verified `actions/checkout@v5` retains the `allow-unsafe-pr-checkout`
input.
- Audited every `actions/checkout` step in the affected
`pull_request_target` workflows for the exact label guard.
- PR checks passed for Main, Chromatic, Vercel staging, submodules, and
PR title validation; Lost Pixel remains excluded from this fix.
The live labeled-fork execution cannot be proven from this PR itself
because `pull_request_target` loads workflow definitions from the base
branch. It should be verified with a fork PR after this change reaches
`main`.
## Description
### Full track
https://github.com/webstudio-is/webstudio-saas/issues/317#issuecomment-2289241819
So thoughts about session
https://github.com/webstudio-is/webstudio-saas/issues/317#issuecomment-2314515772
Some explanations what is fixed and how
https://github.com/webstudio-is/webstudio-saas/issues/317#issue-2465048823
Next PR:
- [x] - Old share links auto redirect
- [x] - Try make better error message having that current PR will logout
all users.
## Steps for reproduction
1. Login using `google login` or `dev login` try to open projects on
dahsboard, create new, clone delete etc.
2. Try to open projects on dahboard, see each is on it's own domain and
work
3. Try to open project link (without share token) with other user -
should fail.
4. Try publish/clone any links and operations.
5. Share project from `userA`:
- try to open it with other `userB`
- see `userB` is not logged in to that project
- try to get using fetch from console anything about `userB` or `userA`
i.e rest etc endpoints on apps.webstudio.is domain
- try to open incognito, check it works.
6. Open few project, then logout from dashboard, reload project page
- See login page
- Try to login as same uer - see it works
- Or try to login as another user - see auth error
## Code Review
- [ ] hi @kof, I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
- test it on preview
## Before requesting a review
- [ ] made a self-review
- [ ] added inline comments where things may be not obvious (the "why",
not "what")
## Before merging
- [ ] tested locally and on preview environment (preview dev login:
5de6)
- [ ] updated [test
cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env` file
## Description
Tired of deployment messages
https://github.com/orgs/community/discussions/36919
## Steps for reproduction
1. click button
2. expect xyz
## Code Review
- [ ] hi @kof, I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
- test it on preview
## Before requesting a review
- [ ] made a self-review
- [ ] added inline comments where things may be not obvious (the "why",
not "what")
## Before merging
- [ ] tested locally and on preview environment (preview dev login:
5de6)
- [ ] updated [test
cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env` file
Oleg Isonen