Repository navigation
Add the package CI job #162
Description
Activity
- added a parent issue
on 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..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
.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.- moved this from In progress to Done in Canton - dAppBooster (#390)
on Sep 3, 2026
User story / Problem statement
CI has two jobs,
registryanddaml. Neither runs a rootnpm install, sonothing 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 adownstream repository.
Expected outcome
A third status check,
package, that installs from the root, checks the twomanifests agree, and runs the install smoke test.
Acceptance criteria
packagein.github/workflows/ci.yml, alongsideregistryand
damlpull request reports a green check carrying the scope log rather than
skippedpackage.json,package-lock.json,registry/, both newscripts,
.gitignore, andci.ymlroot lockfile,
npm ci,npm run check:deps,npm run smoke:registrypaths that must not
Technical notes
.gitignorebelongs in the gate. The rule that keepsregistry/distoutof 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.
npm cirunsprepare, so this job compilesregistry/srcagainstthe root dependency set, which is the set a consumer gets. That is a
different compile from the
registryjob's, and it is the one that would catcha type package arriving only through
registry/node_modules.existing check is required yet, so adding this one changes no merge
requirement; naming it consistently now is what makes it requirable later.
A blip on that fetch would otherwise red a check having verified nothing.
ci.yml, which is in all three gates, soall three jobs run on it. The Daml job's gate also matches
package.jsonandpackage-lock.json, so the two manifest issues in this epic each trigger afull Daml build; that is expected, not a misconfiguration.