Repository navigation
[ci] Deploy worker previews from PRs and use them on staging - #4493
szdziedzic wants to merge 3 commits into
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Subscribed to pull request
Generated by CodeMention Warning: The preamble and epilogue options in commentConfiguration are deprecated. Use template instead. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| concurrency: | ||
| group: worker-preview-${{ github.event.pull_request.number }} | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
🔴 Unrelated labels cancel preview deployment
Changing another label while a preview deploys makes cancel-in-progress cancel the deploy. The replacement run skips both jobs, leaving the preview missing or outdated.
Learn more
The workflow subscribes to all label changes, but deploy-worker-preview runs only when the preview label is added and remove-worker-preview runs only when it is removed. Concurrency applies before those job conditions, so an unrelated label change cancels a running deployment without replacing it. The same issue affects cleanup: closing a PR immediately after removing preview cancels the removal run, while the close run sees no preview label and skips removal.
Example: Add preview to PR 123 and, while its worker builds, add needs-review. The second run cancels the build, skips both jobs, and leaves pr-123 without its new worker.
Recommended fix: Ensure irrelevant label events cannot enter the preview's canceling concurrency group. For example, handle deployment and cleanup in separate workflows or concurrency groups with event-specific admission, and let a close event repeat cleanup even if preview was already removed.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
|
||
| on: | ||
| pull_request: | ||
| types: [labeled, unlabeled, synchronize, closed] |
There was a problem hiding this comment.
🟡 Reopened PR keeps a missing preview
Reopening a closed PR with the preview label does not trigger deployment because reopened is absent. Closing deleted its tarballs, so the labeled PR has no preview until another push or relabel.
Was this helpful? React with 👍 or 👎 to provide feedback.
| 'worker-preview': Flags.string({ | ||
| description: | ||
| 'Run the session on a worker preview built from an expo/eas-cli pull request, e.g. "pr-1234". Only supported on staging.', | ||
| hidden: true, | ||
| }), |
There was a problem hiding this comment.
🔍 Check changelog exemption for new flag
The new simulator flag has no changelog entry, although CONTRIBUTING.md requests one for every PR. Confirm whether the changelog exemption applies.
Was this helpful? React with 👍 or 👎 to provide feedback.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
⏩ The changelog entry check has been skipped since the "no changelog" label is present. |
Why
Right now the only way to try a worker change on staging is to promote it over the shared staging tarball. This gives each PR its own worker that a single staging job can opt into.
How
previewlabel to a PR. CI builds the worker from the PR head and uploadsworker-{android,ios}-preview-pr-<number>.tar.gz. New pushes upload it again. Removing the label or closing the PR deletes it.__EAS_WORKER_PREVIEW=pr-<number>in the build profile or workflow jobenv, or runeas simulator:start --worker-preview pr-<number>(hidden flag).build-and-deploy-worker.ymlgets an optionalrefinput so it builds the PR head and not the merge commit.generated.tsis edited by hand. Regenerate after expo/universe#31641 is deployed.Needs expo/workflow-orchestration#1035 and expo/universe#31641 on staging. The
previewlabel doesn't exist yet.Test Plan
gs://eas-build-worker-tarballs/, run a staging build with the env var, then remove the label and check the tarballs are gone.🤖 Generated with Claude Code