Repository navigation
Add the package CI job #162
Description
User story / Problem statement
CI has two jobs, registry and daml. Neither runs a root npm install, so
nothing on the pull-request path compiles the service against the dependency set
a consumer gets, and nothing checks that the published package installs at all.
A change that empties the tarball, or leaves a runtime import declared only in
registry/package.json, is green on both existing checks and breaks only in a
downstream repository.
Expected outcome
A third status check, package, that installs from the root, checks the two
manifests agree, and runs the install smoke test.
Acceptance criteria
- A job named
packagein.github/workflows/ci.yml, alongsideregistry
anddaml - Its scope gate is per-step, matching the two existing jobs, so a scoped-out
pull request reports a green check carrying the scope log rather than
skipped - The gate matches
package.json,package-lock.json,registry/, both new
scripts,.gitignore, andci.yml - Steps, in order: checkout with full history, scope, setup-node keyed on the
root lockfile,npm ci,npm run check:deps,npm run smoke:registry - The gate regex is verified against a fixed list of paths that must match and
paths that must not
Technical notes
.gitignorebelongs in the gate. The rule that keepsregistry/distout
of git is the same rule that decides whether it reaches the tarball, so an edit
there can empty the package while touching nothing else the gate would catch.- The root
npm cirunsprepare, so this job compilesregistry/srcagainst
the root dependency set, which is the set a consumer gets. That is a
different compile from theregistryjob's, and it is the one that would catch
a type package arriving only throughregistry/node_modules. - A job's name is the status check context a ruleset would match on. Neither
existing check is required yet, so adding this one changes no merge
requirement; naming it consistently now is what makes it requirable later. - Copy the existing scope step verbatim, including its three-attempt fetch retry.
A blip on that fetch would otherwise red a check having verified nothing. - This job's own pull request touches
ci.yml, which is in all three gates, so
all three jobs run on it. The Daml job's gate also matchespackage.jsonand
package-lock.json, so the two manifest issues in this epic each trigger a
full Daml build; that is expected, not a misconfiguration.
Activity
lmcorbalan commentedon Sep 2, 2026
One correction to the technical notes, from a probe run while reviewing #159. The conclusion is right and
.gitignoredoes belong in the gate, but the stated mechanism is not what happens, and the difference changes what this job can usefully assert.The root
.gitignorecannot subtract from thefilesallowlist. Only a nested ignore file can. npm applies a nested ignore file to the pack walk even for a path that the rootfilesnames, whilefilesoutranks the root ignore file. That asymmetry is the whole reason #159 moved the rule up rather than deleting it.Measured on a detached worktree at
ca9ebca, the commit that moved it: withregistry/distin the root.gitignoreand nodistrule inregistry/.gitignore,npm pack --dry-runlists 24 files including all 16registry/dist/*.js. The root rule is inert with respect to the tarball. An edit to it cannot empty the package; an edit that reintroduces a rule inregistry/.gitignorecan, and that mutation is already in #161's list.Two things follow.
1.
.gitignoreis currently in no gate at all, which is a better argument for the criterion than the one in the note. Neither existing pattern matches it: the registry job's^(registry/|\.github/workflows/ci\.yml$)and the daml job's longer alternation both miss. A pull request touching only that file would report two green checks having verified nothing. That is not what happened on #165, whose diff also touchedpackage.jsonand so pulled the daml job in, but a follow-up that re-anchors or narrows the rule on its own would land unverified.2. The failure a root
.gitignoreedit can actually cause is not a packaging failure, so a pack assertion will not see it. It is the one7d04a6cfixed: an anchoredregistry/diststops ignoring adistat any other depth, so build output underregistry/srcorregistry/testsilently becomes committable. Worth deciding whether this job asserts anything about that (a smallgit check-ignoretable over a fixed list of paths would do it, and is the A/B that caught the narrowing in the first place), or whether.gitignoresits in the gate purely so that #161's smoke run is re-executed when the file changes. Either is defensible; the note as written implies a third thing that the pack cannot deliver.