How a change of a template reaches the repositories

← Architecture

The templates are in templates/.github/: the four workflows, the workflow of the discussions, the firewall policy and the starter files that install writes. The jobs that the workflows call are the reusable workflows in .github/workflows/reusable-*.yml, which only this repository has. This repository looks after its own issues with the same workflows, but its copies in .github/ belong to the repository blueprint: every update of the blueprint writes them anew, as the templates of the release of the issue assistant that the blueprint pins. install and check of this commit never read these copies, only the check of the pinned release in the Lint workflow does (step 1 below), and no test compares them with templates/, because they are a release behind after every change of a template. Decision 0007 explains why.

1. A pull request here changes templates/ or the reusable workflows, never the copies of the templates in .github/. tests/test_templates.py pins the rules of the templates and of the jobs. The Action test lints them with actionlint and zizmor, installs them into the sample repository and into a copy of this repository, and checks both set-ups through the action. The Workflow test calls every reusable workflow of the pull request as a dry run, as a repository calls it. The required check issue-assistant runs check of the release that the Lint workflow pins, on this repository's own copies, which the pull request leaves as they are.
2. The release of a change of a template is a new minor version, and its notes say that repositories run install again; a change of the jobs alone reaches them with the move of the pins. A change of the jobs or of the firewall policy starts the canary with its merge, and the release waits until it passed: it calls the reusable workflow as every repository does, so it also shows that a caller's secret and variables reach the jobs.
3. The blueprint takes the release over in a pull request of its own: it runs install of the release in its root, takes over the firewall policy of templates/ and moves every pin of the issue assistant, that of the check in its Lint workflow too. It also adapts its own checks to the templates when they need it, as when actionlint had to ignore the queue of a concurrency group, which it doesn't know yet. A pull request that changed only the blueprint's copies would fail the check issue-assistant there in the same way.
4. The next release of the blueprint reaches every repository made from it, this one too, as an update pull request of the blueprint bot. Repositories that use the action without the blueprint receive the release as a pull request of Dependabot or Renovate that moves the pins, and run install again only when the release changed a template.