CI should not run on the template repo itself (builds placeholders, self-deploys) #6

Closed
opened 2026-07-03 21:34:58 +00:00 by mathias · 0 comments
Owner

Context

Follow-up to gitea-mcp#44. The scaffold is now correctly parameterized with __PROJECT_NAME__/__MODULE_PATH__ (commit 8a22a28), which is right for instantiated repos. But .gitea/workflows/cd.yml fires on push to this template repo too, where:

  1. go build fails — module __MODULE_PATH__ isn't a valid module path, so the build job goes red on every push to the template.
  2. The deploy job would sed k3s/apps/__PROJECT_NAME__/deployment.yaml and clone infra — harmless (fails closed: path doesn't exist, and deploy needs build which already failed), but noisy.

Net: the template repo's own CI is permanently red now, and conceptually a template should never build/deploy itself — only the repos generated from it should.

Options

  1. Guard the workflow to skip when running in the template repo — e.g. an early step that exits 0 if go.mod still contains __MODULE_PATH__ (i.e. "unsubstituted template, nothing to build"). Simple, self-contained.
  2. Move the CD workflow into a init.yml-style bootstrap that only lands on first push of an instantiated repo (there was a prior init.yml bootstrap pattern for this template).
  3. Disable Actions on the template repo.

Recommend option 1 — a one-line guard keeps the workflow co-located and correct for both template and instances.

Acceptance

  • Pushing to the template repo does not produce a red build/deploy run.
  • An instantiated repo (placeholders substituted) still builds + deploys normally.
## Context Follow-up to gitea-mcp#44. The scaffold is now correctly parameterized with `__PROJECT_NAME__`/`__MODULE_PATH__` (commit `8a22a28`), which is right for **instantiated** repos. But `.gitea/workflows/cd.yml` fires on push to *this* template repo too, where: 1. `go build` fails — `module __MODULE_PATH__` isn't a valid module path, so the build job goes red on every push to the template. 2. The deploy job would `sed` `k3s/apps/__PROJECT_NAME__/deployment.yaml` and clone infra — harmless (fails closed: path doesn't exist, and deploy needs build which already failed), but noisy. Net: the template repo's own CI is permanently red now, and conceptually a *template* should never build/deploy itself — only the repos generated from it should. ## Options 1. **Guard the workflow** to skip when running in the template repo — e.g. an early step that exits 0 if `go.mod` still contains `__MODULE_PATH__` (i.e. "unsubstituted template, nothing to build"). Simple, self-contained. 2. Move the CD workflow into a `init.yml`-style bootstrap that only lands on first push of an instantiated repo (there was a prior init.yml bootstrap pattern for this template). 3. Disable Actions on the template repo. Recommend option 1 — a one-line guard keeps the workflow co-located and correct for both template and instances. ## Acceptance - [ ] Pushing to the template repo does not produce a red build/deploy run. - [ ] An instantiated repo (placeholders substituted) still builds + deploys normally.
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mathias/template-go-web#6