Alternative preview release flow#613
Conversation
|
Andarist
left a comment
There was a problem hiding this comment.
With this approach - I wouldnt be able to trigger the preview release on a fork, right?
There was a problem hiding this comment.
nit, the "base" workflow is caled publish - perhaps we should rename this one to match the base one more closely?
|
|
||
| const tag = `v${pkgJson.version}`; | ||
| const releaseLine = "pr-release"; | ||
| const releaseLine = `built-${process.env.GITHUB_REF_NAME}`; |
There was a problem hiding this comment.
git stores branches as directories, perhaps we should use a pattern like this:
| 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 |
There was a problem hiding this comment.
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:
- the maintainer schedules a job on a PR
- the attacker polls the github API against the triggering action (like a PR comment, or maybe a new workflow run)
- 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.
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.