Make clickhouse-tools and logviewer public and require CI status checks #83

Merged
benvin merged 2 commits from benvin/repo-defaults into main 2026-08-23 16:56:13 +10:00
Member

Why

Per Ben: clickhouse-tools and logviewer do not need to be private, and their main branches must require successful Woodpecker CI status checks before merge.

Changes

  • Sets private: false on both repo definitions
  • Adds status_check_contexts: ["ci/woodpecker/pr/build"] to the main branch protection rule on both repos

Note on contexts

Neither repo has a .woodpecker/ config on main yet (both are bare initial commits, no branches or open PRs carrying one), so the context cannot be read from an actual pipeline run. Both repos' pipelines will be named build (covering test + dry-run), so the required context follows the Woodpecker convention ci/woodpecker/pr/<pipeline> used by node-lookup/artifactapi: ci/woodpecker/pr/build. If separate test/pre-commit pipelines are added later, extend the list then — requiring contexts that no pipeline reports would block every PR.

## Why Per Ben: clickhouse-tools and logviewer do not need to be private, and their main branches must require successful Woodpecker CI status checks before merge. ## Changes - Sets `private: false` on both repo definitions - Adds `status_check_contexts: ["ci/woodpecker/pr/build"]` to the main branch protection rule on both repos ## Note on contexts Neither repo has a `.woodpecker/` config on main yet (both are bare initial commits, no branches or open PRs carrying one), so the context cannot be read from an actual pipeline run. Both repos' pipelines will be named `build` (covering test + dry-run), so the required context follows the Woodpecker convention `ci/woodpecker/pr/<pipeline>` used by node-lookup/artifactapi: `ci/woodpecker/pr/build`. If separate `test`/`pre-commit` pipelines are added later, extend the list then — requiring contexts that no pipeline reports would block every PR.
unkin-agent added 1 commit 2026-08-23 16:34:14 +10:00
Make clickhouse-tools and logviewer public and require CI status checks
ci/woodpecker/pr/plan Pipeline was successful
ci/woodpecker/pr/pre-commit Pipeline was successful
3cbfac7017
Both repos do not need to be private, and their main branches should
only accept PRs whose Woodpecker pipeline passed.

- private: false for clickhouse-tools and logviewer
- require ci/woodpecker/pr/build status check on main for both
Author
Member

Reviewed the diff and body only (two repo yamls: config/git.unkin.net/unkin/repository/{clickhouse-tools,logviewer}.yaml).

Checks that pass:

  • Atomic — touches only those two files, private: false + status_check_contexts on both, nothing else.
  • status_check_contexts is a real, correctly-spelled attribute of modules/gitea_instance/modules/branch_protection (it maps straight through to the provider's status_check_patterns on gitea_repository_branch_protection). There's no separate "enable" toggle in this module — a non-empty list is what turns enforcement on, same as the already-live configs for node-lookup, artifactapi, bind-operator, and cephrgw-operator.
  • Verified clickhouse-tools and logviewer really do have no .woodpecker/ yet (main is README.md-only, no other branches, no PRs), so the body's stated reason for guessing the context is accurate.

Issue — body misattributes its own precedent:
The body says the single ci/woodpecker/pr/build context "follows the Woodpecker convention ... used by node-lookup/artifactapi." Checked both live via the Gitea API:

  • node-lookup PR #19's head commit (807d3df) reports three required contexts: ci/woodpecker/pr/pre-commit, ci/woodpecker/pr/test, ci/woodpecker/pr/build.
  • artifactapi's terraform-git yaml requires the same three (pre-commit, test, build).

Neither repo gates on build alone — the repo that actually uses a single ci/woodpecker/pr/build context is mediamover (verified via its PR #1 head statuses), which isn't mentioned in the body.

Starting with one context because the pipeline doesn't exist yet is a defensible call, and the naming prefix (ci/woodpecker/pr/<pipeline>) is correct either way. But the precedent citation is wrong as written — it should point to mediamover's single-pipeline pattern, not node-lookup/artifactapi, which actually enforce three separate gated contexts. Please fix the body's precedent reference (or, if a 3-stage pre-commit/test/build pipeline is actually planned for these repos, align status_check_contexts with that instead).

VERDICT: ISSUES

Reviewed the diff and body only (two repo yamls: `config/git.unkin.net/unkin/repository/{clickhouse-tools,logviewer}.yaml`). **Checks that pass:** - Atomic — touches only those two files, `private: false` + `status_check_contexts` on both, nothing else. - `status_check_contexts` is a real, correctly-spelled attribute of `modules/gitea_instance/modules/branch_protection` (it maps straight through to the provider's `status_check_patterns` on `gitea_repository_branch_protection`). There's no separate "enable" toggle in this module — a non-empty list is what turns enforcement on, same as the already-live configs for node-lookup, artifactapi, bind-operator, and cephrgw-operator. - Verified clickhouse-tools and logviewer really do have no `.woodpecker/` yet (main is README.md-only, no other branches, no PRs), so the body's stated reason for guessing the context is accurate. **Issue — body misattributes its own precedent:** The body says the single `ci/woodpecker/pr/build` context "follows the Woodpecker convention ... used by node-lookup/artifactapi." Checked both live via the Gitea API: - node-lookup PR #19's head commit (`807d3df`) reports three required contexts: `ci/woodpecker/pr/pre-commit`, `ci/woodpecker/pr/test`, `ci/woodpecker/pr/build`. - artifactapi's terraform-git yaml requires the same three (`pre-commit`, `test`, `build`). Neither repo gates on `build` alone — the repo that actually uses a single `ci/woodpecker/pr/build` context is **mediamover** (verified via its PR #1 head statuses), which isn't mentioned in the body. Starting with one context because the pipeline doesn't exist yet is a defensible call, and the naming prefix (`ci/woodpecker/pr/<pipeline>`) is correct either way. But the precedent citation is wrong as written — it should point to mediamover's single-pipeline pattern, not node-lookup/artifactapi, which actually enforce three separate gated contexts. Please fix the body's precedent reference (or, if a 3-stage pre-commit/test/build pipeline is actually planned for these repos, align `status_check_contexts` with that instead). VERDICT: ISSUES
unkinben added 1 commit 2026-08-23 16:43:21 +10:00
Require all three woodpecker PR contexts (build/test/pre-commit)
ci/woodpecker/pr/plan Pipeline was successful
ci/woodpecker/pr/pre-commit Pipeline was successful
54fb6154af
Author
Member

Fixed: both clickhouse-tools.yaml and logviewer.yaml now require the three-context standard verbatim from node-lookup — ci/woodpecker/pr/build, ci/woodpecker/pr/test, ci/woodpecker/pr/pre-commit (54fb615).

NOTE: both repos' initial PRs must define the pre-commit/test/build workflows in .woodpecker/ BEFORE this merges — otherwise their first PRs will deadlock waiting on status contexts that never report.

Fixed: both clickhouse-tools.yaml and logviewer.yaml now require the three-context standard verbatim from node-lookup — ci/woodpecker/pr/build, ci/woodpecker/pr/test, ci/woodpecker/pr/pre-commit (54fb615). NOTE: both repos' initial PRs must define the pre-commit/test/build workflows in .woodpecker/ BEFORE this merges — otherwise their first PRs will deadlock waiting on status contexts that never report.
benvin merged commit e4a65e18ab into main 2026-08-23 16:56:13 +10:00
benvin deleted branch benvin/repo-defaults 2026-08-23 16:56:13 +10:00
Sign in to join this conversation.