From 1d3bacfb121532be8660d43fe9baa4efa4d9b2d9 Mon Sep 17 00:00:00 2001 From: Justin Klein Date: Sat, 26 Sep 2026 21:43:14 +0000 Subject: [PATCH 1/2] docs: name the remote that exists, and a push rule for the wiki MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The remote bullet described two remotes, github and JLab-Git, and denied that origin exists. The checkout has exactly one, origin, pointing at the Gitea instance, and so does every worktree cut from it; two agents lost time on the difference. The point the bullet made survives — Gitea is the leading copy, the mirror is fed from there, and where a second remote does exist the advice to name it still holds. The wiki has no PR flow, so parallel edits meet only at push time. During Gitea #16 and #18 two agents edited the same two pages minutes apart and the rebase happened to be clean; a force push would have deleted the other edit with nothing to report it. Fetch and rebase before every push, never force-push. The chart pages no longer quote versions, so the sentence that explained them as snapshots now says they carry no numbers at all. That change is already in the wiki. --- CLAUDE.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index aaee606..1b2d7fd 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -30,6 +30,8 @@ git clone ssh://git@git.jk-dev.de:30022/jlab-cluster/helm-charts.wiki.git Flat layout, one Markdown file per page, page name = file name, links are relative page names without the extension (`[CI/CD](CI-CD)`). A new page must also be listed in `_Sidebar.md`, or it is reachable only by search. +**There is no PR flow here, so fetch and rebase before every push and never force-push** — two agents have already edited the same page minutes apart, and a force push deletes the other edit silently, with nothing left to report it. + **What obliges a wiki edit** (step 7 of the workflow above, same round of work, never a follow-up issue): | Change | Page | @@ -43,7 +45,7 @@ Flat layout, one Markdown file per page, page name = file name, links are relati | a Renovate rule added or changed | `Renovate` | | something broke in a way a rule now prevents | `Lessons-Learned` | -**What does not oblige an edit:** a plain app-version bump. Renovate automerges those continuously and never touches the wiki, which is why chart pages quote versions as snapshots and name `Chart.yaml` as the source of truth. An app update that *does* change values or behaviour is not a plain bump, and the table applies. +**What does not oblige an edit:** a plain app-version bump. Renovate automerges those continuously and never touches the wiki, which is why chart pages carry no version numbers at all and name `Chart.yaml` as the source of truth. An app update that *does* change values or behaviour is not a plain bump, and the table applies. Wiki commits follow the same rules as repo commits: no `Co-Authored-By`, no "Generated with Claude Code" footer. @@ -52,7 +54,7 @@ Wiki commits follow the same rules as repo commits: no `Co-Authored-By`, no "Gen Everything runs on the Gitea instance JLab-Git: issues, pull requests, CI and Renovate. github.com is a push mirror with Actions and Renovate **switched off**, and it lags until the mirror runs. README, "Where this repo lives", holds the measured differences between a Gitea runner and a GitHub one. - **`tea`, not `gh`.** Work happens in a **Coder workspace, and it has no `op`** — that is the normal case here, not a broken environment, so do not wait for the 1Password CLI or propose installing it. Call `tea` directly; it carries the workspace's stored login and opens PRs and issues under the **bot account**, which is accepted. Say so in the report when something is authored that way. (`op plugin run -- tea`, the older instruction, applies only where `op` actually exists.) -- **Remotes are named `github` and `JLab-Git`** — there is no `origin`. `JLab-Git/main` is the leading copy; say which remote you mean, because `git push` without one is ambiguous here. +- **The remote is `origin`, and it points at Gitea** (`ssh://git@git.jk-dev.de:30022/jlab-cluster/helm-charts.git`). The checkout has exactly that one, and so does every worktree cut from it, so a bare `git push` goes to the leading copy; the github.com mirror is fed by Gitea itself and is never pushed to by hand. A clone elsewhere may carry the mirror as a second remote named `github` — wherever more than one exists, say which one you mean. - **Branch protection with a signature requirement is active**, and signatures verify on Gitea. A commit that is not signed does not reach `main` — check before opening a PR, do not discover it at merge time. - **No merge queue.** Gitea has none, and its place is taken by **auto-merge on green checks**: the PR is armed once and merges itself when the required check passes **and the required review exists** — both are active on `main`, so an armed PR without a review sits there instead of merging. Rule 6 above is unchanged — the user merges, and an agent never merges its own PR or arms auto-merge on it. - **A required check per chart is not possible.** Gitea runs a whole matrix as one job under one status context, so the install-test reports once for all charts. What is required on `main` is `validate-charts`, as that single context; per chart is the part that cannot be had. Relevant whenever branch protection is touched. -- 2.54.0 From 733fea5d9e25a064744dddcba1ea215352f6e7c0 Mon Sep 17 00:00:00 2001 From: Justin Klein Date: Sat, 26 Sep 2026 21:46:03 +0000 Subject: [PATCH 2/2] docs: point the two workflow cross-references at the right steps MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Moving the wiki step from 7 to 5 shifted the two items behind it, and the references that name them by number stayed where they were. The wiki section still called itself step 7, and the auto-merge bullet cited rule 6 for "the user merges", which is rule 7 — rule 6 is the agent's lifetime. A number pointing at the wrong step is the kind of reference that passes for a reason on the next reading, so both are corrected here rather than in an issue of their own. --- CLAUDE.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 1b2d7fd..94a7f8f 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -32,7 +32,7 @@ Flat layout, one Markdown file per page, page name = file name, links are relati **There is no PR flow here, so fetch and rebase before every push and never force-push** — two agents have already edited the same page minutes apart, and a force push deletes the other edit silently, with nothing left to report it. -**What obliges a wiki edit** (step 7 of the workflow above, same round of work, never a follow-up issue): +**What obliges a wiki edit** (step 5 of the workflow above, same round of work, never a follow-up issue): | Change | Page | | --- | --- | @@ -56,7 +56,7 @@ Everything runs on the Gitea instance JLab-Git: issues, pull requests, CI and Re - **`tea`, not `gh`.** Work happens in a **Coder workspace, and it has no `op`** — that is the normal case here, not a broken environment, so do not wait for the 1Password CLI or propose installing it. Call `tea` directly; it carries the workspace's stored login and opens PRs and issues under the **bot account**, which is accepted. Say so in the report when something is authored that way. (`op plugin run -- tea`, the older instruction, applies only where `op` actually exists.) - **The remote is `origin`, and it points at Gitea** (`ssh://git@git.jk-dev.de:30022/jlab-cluster/helm-charts.git`). The checkout has exactly that one, and so does every worktree cut from it, so a bare `git push` goes to the leading copy; the github.com mirror is fed by Gitea itself and is never pushed to by hand. A clone elsewhere may carry the mirror as a second remote named `github` — wherever more than one exists, say which one you mean. - **Branch protection with a signature requirement is active**, and signatures verify on Gitea. A commit that is not signed does not reach `main` — check before opening a PR, do not discover it at merge time. -- **No merge queue.** Gitea has none, and its place is taken by **auto-merge on green checks**: the PR is armed once and merges itself when the required check passes **and the required review exists** — both are active on `main`, so an armed PR without a review sits there instead of merging. Rule 6 above is unchanged — the user merges, and an agent never merges its own PR or arms auto-merge on it. +- **No merge queue.** Gitea has none, and its place is taken by **auto-merge on green checks**: the PR is armed once and merges itself when the required check passes **and the required review exists** — both are active on `main`, so an armed PR without a review sits there instead of merging. Rule 7 above is unchanged — the user merges, and an agent never merges its own PR or arms auto-merge on it. - **A required check per chart is not possible.** Gitea runs a whole matrix as one job under one status context, so the install-test reports once for all charts. What is required on `main` is `validate-charts`, as that single context; per chart is the part that cannot be had. Relevant whenever branch protection is touched. - **Issue numbers changed with the move, and `#n` in this repo's files means the GitHub tracker.** The issues open at the time are Gitea #5–#21 and #24; the mapping is a comment on Gitea #14. Closed ones were not migrated and exist only on GitHub. Beware that Gitea silently resolves a bare `#n` against its own counter, so an old reference can render as a link to something unrelated. When you write a *new* reference, use the Gitea number. - **Renovate runs outside this repo**, as the shared `jlab-renovate-bot` instance; it reads our `renovate.json5` and its `postUpgradeTasks` hook is allow-listed there. **Do not add a Renovate workflow here** — a second runner means duplicate PRs and two schedulers rewriting each other's branches. README, "Renovate on Gitea", has the evidence. -- 2.54.0