Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

A preview build is labelled with the head sha but built from the merge ref, and nothing says so

Aperta
#557 1 commento 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions
Ambito
ci-cd, release

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 of 211db370 into main)

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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di stackblitz-labs/pkg.pr.new

Tutte le issue di stackblitz-labs/pkg.pr.new

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.