A preview build is labelled with the head sha but built from the merge ref, and nothing says so
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 52/100
Direzione di ricerca
Start with the publish step and the GitHub Actions workflow path, especially the actions/checkout invocation shown in vuejs/core's ci.yml. Verify how the artifact label is derived and whether the checked-out commit is available there. Done means a merge-ref build is explicitly identified in the PR comment, package metadata, or both, without changing the existing merge-build behavior.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Installing pkg.pr.new/<pkg>@<sha> does not always give you a build of that sha's tree. On a
pull_request run it gives you a build of that head merged into the base as of the run. The
label says one thing, the contents are another, and nothing in the comment or in the package
says which.
I hit this while checking that a fix worked, by comparing two preview builds from the same
pull request. The two commits are 21 days apart and a major release landed on the base
between them, so my "before" and "after" differed by the release as well as by the fix. I
posted a wrong claim on the maintainer's thread before I caught it.
How to see it
Compare the version in a commit's own tree with the version the artifact labelled with that
commit reports.
ag-ui-protocol/ag-ui#2354, two commits on the same PR:
1bda0cf5 077cdcf7
tree at that sha 0.0.58 0.0.58
artifact reports 0.0.58 1.0.1
dist/index.js 65,523 B 82,982 B
Both commits' trees say 0.0.58. The later artifact reports 1.0.1, is 17,459 bytes bigger,
and contains a protocol-negotiation feature that is on the base branch and in neither commit.
It is not that repo. vuejs/core, derived the same way:
PR #14955 211db370 its tree says 3.5.35 the artifact says 3.5.38
PR #13952 ece39d9c its tree says 3.5.21 the artifact says 3.5.22
Why
actions/checkout defaults to refs/pull/N/merge on a pull_request event. A workflow that
does not pin ref: therefore builds the merge commit, while the artifact is labelled with the
head sha.
vuejs/core's ci.yml:
on:
pull_request:
...
- name: Checkout
uses: actions/checkout@... # v7.0.1
with:
persist-credentials: false
No ref:. I read the twenty largest workflows that call pkg-pr-new publish: eighteen run on
pull_request, and all eighteen of those pin no ref — vue, redux, webpack, jest, docusaurus,
prisma, TanStack/query, TanStack/table, apollo-client, element-plus, mermaid, lerna, hono,
typeorm, slidev, p5.js, halo, NativeScript. The two that are not exposed are storybook, which
pins a ref, and appwrite, which does not run on pull_request.
One thing about those numbers
The version comparison only detects the merge when a version bump happened to fall between
the branch point and the run. The merge happens on every run; the mismatch is the visible
subset. Of 31 drifted vuejs/core PRs with a live artifact, 3 showed it. That is a floor, not
a rate.
Suggestion
The publish step is the only place that knows both things. It could compare the sha it is
about to label with the commit actually checked out, and when they differ, say so — in the PR
comment, in the published package's metadata, or both. Something as small as
built from
abc1234(merge of211db370intomain)
would tell anyone doing a two-build comparison that they want
ref: ${{ github.event.pull_request.head.sha }} if they mean the commit itself.
To be clear about scope: I am not calling this a defect in pkg.pr.new. The default belongs to
actions/checkout, and building the merge is the right thing for "does this PR work". It is
the labelling that is silent, and pkg.pr.new is the only component that can see both sides of
it.
- Lingua principale
- TypeScript
- Stelle
- 1.9k
- Fork
- 131
- Merge medio
- 1g 9h
- PR unite (30g)
- 6
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di stackblitz-labs/pkg.pr.new
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
stackblitz-labs/pkg.pr.new#531 · 2 commenti ·
-
--template does not resolve pnpm catalog: references before uploading to StackBlitzForse già presa @kunalgoesbyken l’ha presa 6 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
stackblitz-labs/pkg.pr.new#489 · 1 commento · 1 reazione ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
stackblitz-labs/pkg.pr.new#482 · 1 reazione ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
stackblitz-labs/pkg.pr.new#343 · 1 commento ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
stackblitz-labs/pkg.pr.new#320 · 2 commenti · 1 reazione ·
Tutte le issue di stackblitz-labs/pkg.pr.new
Issue simili
-
Add: Disco Mix SDApertacheck:passed streams:add
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
level2 nsoc26
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
GauravKarakoti/SecureFlow#1488 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
deltachat/deltachat-desktop#6914 ·
I maintainer di solito rispondono entro 2 giorni
-
area:cli bug P4
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
bug from-studio
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
esengine/DeepSeek-Reasonix#14868 ·
I maintainer di solito rispondono entro 1 giorno