TRAC-969: Create reusable preview deployment action - #3194
Conversation
🦋 Changeset detectedLatest commit: 6b275bd The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
2a99903 to
74462d0
Compare
Bundle Size ReportComparing against baseline from No bundle size changes detected. |
Unlighthouse Performance Comparison — VercelComparing PR preview deployment Unlighthouse scores vs production Unlighthouse scores. Summary ScoreAggregate score across all categories as reported by Unlighthouse.
Category Scores
Core Web Vitals
|
| return response.json(); | ||
| } | ||
|
|
||
| async function github(path, init = {}) { |
There was a problem hiding this comment.
It's a very simple github wrapper and we only use it for 3 endpoints really, so I'd like to avoid pulling in any dependencies on the action since it has 0 deps right now aside from the js-yaml dev dependency
There was a problem hiding this comment.
Pretty sure github does something where it makes oktokit very light to add, could be wrong though 🤷♂️
There was a problem hiding this comment.
@chanceaclark It looks like if we use octokit we'll have to start committing a dist/ folder in order for the action to work which might add some more complexity with the release flow.. If we keep it simple with 0 dependencies, it's much more straightforward and simple - less cognitive overhead
…nd update documentation
…cess and documentation
…vironment variables for configuration and update documentation
…andling for preview deployments
5e8228e to
800df79
Compare
0da1e66 to
6b275bd
Compare
2 participants
Jira: TRAC-969
What/Why?
Adds
packages/deployment-preview-action, a GitHub Action that deploys a preview of a pull request to BigCommerce native hosting and keeps the PR comments describing it accurate.core/.github/ships a ready-to-use workflow, so scaffolded storefronts get previews without writing one.Three decisions worth knowing before reading the diff:
All previews share one hosting project. Native hosting assigns a hostname per project, not per deployment, so a second deploy replaces the first at the same URL. The project serves one PR at a time, which is why there is arbitration at all. The newest open PR deploys on push; any other takes the preview over by commenting
redeploy preview. A PR that loses the preview gets its comment rewritten, so no thread advertises a URL that now serves someone else's code.Shipped as both an action and a reusable workflow. A workflow can declare
concurrency,permissionsandenvironment; an action cannot. The concurrency group is load-bearing here — two deploys at once would race for the shared project — so the reusable wrapper is the recommended entry point andcore/uses it.The comment path builds PR code with the store's deploy credentials. Write-permission and same-repo checks run before checkout, so nothing untrusted is fetched, let alone executed by
pnpm install. These live inside the action rather than in copy-pasteable YAML so they can't be omitted by mistake.Unconfigured repositories skip silently rather than failing, so a freshly scaffolded storefront doesn't get a red X on its first PR.
Testing
pnpm --filter @bigcommerce/deployment-preview-action test43 tests against a stubbed BigCommerce and GitHub API — no credentials or network needed. They cover the deploy-eligibility rules, which comment updates notify vs. stay silent, and
action.ymlitself (everyrunblock is syntax-checked, since nothing compiles it).Verified end to end against a real store: auto-deploy on the newest PR, deferral on an older one,
redeploy previewtakeover, and the comment rewrite on the displaced PR.Migration
None for existing projects. Previews stay off until configured with a
PREVIEW_DEPLOYMENT_PROJECT_UUIDvariable and the store credentials — see the package README.