Skip to content

Alternative preview release flow#613

Open
emmatown wants to merge 4 commits into
changesets:mainfrom
emmatown:main
Open

Alternative preview release flow#613
emmatown wants to merge 4 commits into
changesets:mainfrom
emmatown:main

Conversation

@emmatown
Copy link
Copy Markdown
Member

@emmatown emmatown commented May 7, 2026

Example run: https://github.com/emmatown/changesets-action/actions/runs/25488677177

Note I've done this from a fork of this repo, not on changesets/action itself, this is partly because GitHub won't let you trigger the workflow dispatch unless the workflow exists on main and partly to demonstrate how it works on a fork.

@emmatown emmatown requested a review from Andarist as a code owner May 7, 2026 09:55
@changeset-bot
Copy link
Copy Markdown

changeset-bot Bot commented May 7, 2026

⚠️ No Changeset found

Latest commit: cedecbb

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Copy Markdown
Member

@Andarist Andarist left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this approach - I wouldnt be able to trigger the preview release on a fork, right?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, the "base" workflow is caled publish - perhaps we should rename this one to match the base one more closely?

Comment thread scripts/release-pr.ts

const tag = `v${pkgJson.version}`;
const releaseLine = "pr-release";
const releaseLine = `built-${process.env.GITHUB_REF_NAME}`;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

git stores branches as directories, perhaps we should use a pattern like this:

Suggested change
const releaseLine = `built-${process.env.GITHUB_REF_NAME}`;
const releaseLine = `built-pr/${process.env.GITHUB_REF_NAME}`;

this way they would be "grouped"

permissions:
contents: write
steps:
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how strong guarantees do we have here when it comes to what commit gets actually built and released? a workflow could get queued and also retried later - I feel this might be risky-ish because, I'd assume, it might run against the "current" version of a branch

a security researcher emailed me with a description of an atack like this:

  1. the maintainer schedules a job on a PR
  2. the attacker polls the github API against the triggering action (like a PR comment, or maybe a new workflow run)
  3. the attacker quickly pushes malicious stuff to that PR

It feels like this workflow would be prone to this attack. I know none of those preview builds can truly be trusted - but we should minimize the risks when we can.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants