Commit Graph
2 Commits
Author SHA1 Message Date
mathiasandClaude Opus 5 2c4158a808 fix(test): grade golangci-lint on its exit code, not on grepping its output
CD / Detect unsubstituted template (pull_request) Successful in 0s
CD / Lint / Test / Vet (pull_request) Successful in 5s
CD / Build & Import (pull_request) Skipped
CD / Deploy via GitOps (pull_request) Skipped
CD / Detect unsubstituted template (push) Successful in 0s
CD / Lint / Test / Vet (push) Successful in 5s
CD / Build & Import (push) Skipped
CD / Deploy via GitOps (push) Skipped
Addresses the blocking finding from the review of this PR.

The harness matched golangci-lint's human-readable summary to decide pass or
fail, and discarded its exit status. Any failure that is not "found issues" --
bad config, unwritable TMPDIR, OOM, a future change to the output format --
produces non-matching text and was scored `ok`.

Since this harness is the only gate covering cmd/__PROJECT_NAME__, a linter
that dies would have left the entrypoint unchecked with CI green. That is the
precise defect class this file was added to end, which is why it blocked the
PR rather than being filed as a follow-up.

golangci-lint exits 0 clean / 1 issues found / >1 the linter itself failed.
Now graded on that, and the >1 case reports the child as UNCHECKED rather than
clean.

Two more from the same review:

  - a missing tool now fails instead of `exit 0` with zero assertions, which
    was indistinguishable from a real pass to anything reading the exit code.
    It was unreachable in CI only by luck of task ordering, not by rule.
  - Dockerfile joins the substituted file set. It builds ./cmd/__PROJECT_NAME__
    and was outside the pattern, so the harness never validated the one path a
    repo rename has historically broken here.

Verified by flipping each case:

    crashing linter (exit 3)  -> FAIL "the child is UNCHECKED, not clean"
    tools absent              -> FAIL, 0 passed
    normal                    -> 5 passed, 0 failed

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-17 18:14:23 +02:00
mathiasandClaude Opus 5 39b8e86540 fix(ci): let the template test itself, and cover the entrypoint ./... cannot see
CD / Detect unsubstituted template (pull_request) Successful in 1s
CD / Lint / Test / Vet (pull_request) Successful in 8s
CD / Build & Import (pull_request) Skipped
CD / Deploy via GitOps (pull_request) Skipped
Closes #12.

The guard that stops this template building itself also stopped it TESTING
itself: check, build and deploy were all gated on is_template, which is always
true here. So the repo that mints every other repo was the one repo with no
working gate — and #8 sat in it for months with CI green throughout, found
eventually by a child rather than by us.

check is now ungated. build and deploy stay gated, because they genuinely
cannot work here: placeholder module path, no image name, no namespace.

Ungating alone would have been a false fix. `go build ./...`, `go vet ./...`,
`go test ./...` and `golangci-lint run ./...` cannot see cmd/__PROJECT_NAME__
at all — Go skips directories whose names begin with an underscore when
expanding package patterns:

    $ go list ./...
    __MODULE_PATH__/internal/web        <- no cmd package

So a newly-ungated check would still have skipped the package every generated
repo is built around.

scripts/tests/generated-child_test.sh substitutes the tracked tree into a
throwaway child and gates the result: templ generate, go list, build, vet,
golangci-lint. Ported from template-go-agent, plus a templ step, which also
proves the pinned generator and pinned library agree.

Proven to fail when it should. With a deliberate errcheck violation added to
the entrypoint:

    generated-child harness -> FAIL cmd/childproj/main.go:12:26 errcheck
    golangci-lint run ./... -> "0 issues."

The existing gate calls the same broken code clean. That contrast is the
reason this harness exists rather than a wider lint invocation.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-17 18:05:23 +02:00