[vannt-dev]

Why

A new standard reaches a repository only when someone runs repokeeper update in it. With twelve repositories that was twelve runs and twelve commits by hand on 11 October, and it comes back with every standard.

What changes

modules.autoupdate: true (off unless asked for, in no preset, GitHub only) writes .github/workflows/repokeeper-autoupdate.yml: every Monday, and by hand, it calls the new reusable workflow repokeeper-update.yml, which

1. runs repokeeper update with the newest repokeeper;
2. when that changes anything, pushes the branch repokeeper/update and opens chore(repokeeper): update standard to X.Y.Z; a later run moves the same branch and edits the same pull request;
3. when nothing changes, ends with a notice.

What the pull request holds is what the command writes by hand:

• Files edited locally, and owned ones, are kept. repokeeper update exits 1 for kept files; the job takes that as a warning, not a failure, and the body of the pull request carries the update's report, which names them.
• A package.json the update changes has its package-lock.json brought in step, so npm ci still installs. With pnpm, Yarn or Bun the body says the lockfile is still to be updated.

Token. An update usually changes a file under .github/workflows/, which GITHUB_TOKEN may not push, so the job takes a REPOKEEPER_TOKEN secret (contents, pull requests and workflows, read and write). Without it GITHUB_TOKEN is used: it can propose an update that touches no workflow file, a refused push says why, and the held runs of its pull request are approved by an update-pr-ci job, as release-pr-ci does for releases.

Compatibility. The switch is written to .repokeeper.yml only when on, so a file without it is still read by every earlier repokeeper, and the playground (published at merge) keeps producing files 0.8.2 accepts unless the new box is ticked, in which case it says that 0.9.0 is needed. No generated file of an existing repository changes, so the standard version stays 1.4.4.

On GitLab the switch writes nothing and check/update say so. A scheduled job that opens a merge request needs a project token and was not built, because it could not be tried here.

Checked

• 434 tests (4 new for the module, written first; the interactive init tests now ask the new question and take a yes), biome check, typecheck, build.

• The reusable workflow's step, run outside GitHub against a repository made with the published 0.8.0 (standard 1.4.3), a bare repository as its origin and a stand-in for gh:

  Situation	Result
  a newer standard, no pull request	branch pushed with ci.yml, .repokeeper.yml, the lock, package.json and package-lock.json; npm ci on the branch passes; gh pr create; changed=true, pr_branch set
  the pull request is open, own token	gh pr edit 7; no pr_branch
  after the merge	notice, changed=false, no gh call
  newest standard, a managed file edited by hand	warning, changed=false, exit 0
  older standard and that edited file	pull request opened; the body names the kept file
  the remote refuses the push over a workflow file	exit 1 with the message that asks for REPOKEEPER_TOKEN

• The built CLI in a scratch repository: init writes no autoupdate line; switching it on and running update writes the workflow, and check then passes; with platform: gitlab the note is printed.

• Not run: the workflow on GitHub itself (the scheduled trigger, the real gh calls, the approval of held runs). The reusable workflow only exists at @v0 after a release, so the first real run is in a repository that switches it on after 0.9.0.

A second commit: the tests and git's hook environment

test: keep git's hook environment away from the tests. Pushed from a linked worktree, the pre-push hook runs the suite with GIT_DIR and GIT_WORK_TREE pointing at this repository, and the tests' own git init, git config and git commit then act on it instead of on their scratch directories: 72 tests fail, and the repository gets their commits and settings. That happened here while this branch was first pushed (the branch was rebuilt and the settings removed; nothing else was touched). test/setup.ts drops those variables before any test runs; with it the suite passes under the hook's environment and leaves the repository alone.