The generator pin is duplicated in two workflows with nothing asserting they agree

[ptr727]

Found while reviewing this pipeline against the new fleet hugo type (ptr727/ProjectTemplate#560), which asserts hugo.generator.pinned. The pinning itself is right and is being kept; only the duplication is the finding.

What is duplicated

The same two values appear in two files, each with its own install step that verifies them identically:

• .github/workflows/validate-task.yml:12-13 and its install at :81-89
• .github/workflows/deploy-site-task.yml:14-15 and its install at :56-64

  HUGO_VERSION: 0.164.0
  HUGO_SHA256: 8325f3653032d0fc536503691f4833dc4eb6c6be02ee62466758f3f37a7f2fcd

Both files carry an "update both values together" instruction. Nothing enforces it.

Why it matters

A one-sided bump is silent and produces the failure mode the pin exists to prevent. Validation would build the site with one generator and the deploy would ship a tree built by another, with no error at any point, since each install verifies its own checksum against its own version and both succeed. The stated rationale (validate-task.yml:9-11) is that "the site build is only reproducible if the generator is", and two independently-editable pins is exactly the state where that stops being true.

There is no bot to catch it either: no Dependabot ecosystem tracks Hugo, so both pins move by hand.

The version and the digest also have to move together within a file, and a hand-edited digest is easy to get wrong in a way that only surfaces as a failed sha256sum --check on the next run.

Options

1. A composite action (.github/actions/install-hugo/action.yml) owning both values and the install. One definition, two callers, no drift possible. Also removes the duplicated curl-verify-dpkg block.
2. A validation step that greps both workflow files and fails when the pairs differ. Cheaper, keeps the two installs, catches the drift rather than preventing it.
3. A committed pin file (hugo-version.json) both workflows read. Closest to the fleet's upstream-tracker shape, and it would give a future version tracker something to write to. Heaviest of the three.

Option 1 is the one I would take: it removes the duplication rather than detecting it, and the install block is worth factoring out on its own.

Whichever lands, deploy/README.md:24 notes the build must be +extended, which today is asserted only by the .deb filename. Worth folding a hugo version | grep extended assertion into the same step.

Recorded in the hub registry as a driftNote against hugo.generator.pinned until it clears.

[ptr727]

Fixed in 49dfbbc on develop (#30). Closing manually because the PR targeted develop rather than the default branch, so the Closes #29 keyword will not fire until the promotion to main.

The pin now lives in .github/actions/install-hugo/action.yml and both validate-task.yml and deploy-site-task.yml call it. Verified: grep -rn '0.164.0|8325f36' .github/ returns that one file and nothing else.

Two things changed from the fix as first written, both from review:

• The action originally exposed version and sha256 as inputs with defaults. That left the same divergence one level up, since two callers could pass different values, and the only thing preventing it was that neither passes the arguments. That is correctness by convention, which is what the original two-file pin also was. The pin is hardcoded now, so callers cannot override it.
• The extended build is asserted from hugo version rather than inferred from the .deb filename, which was the only thing carrying that requirement before despite deploy/README.md:24 stating it.

Not done here and worth knowing: no Dependabot ecosystem tracks Hugo, so the pin still moves by hand. It now moves in one place.