Make clickhouse-tools and logviewer public and require CI status checks #83
Reference in New Issue
Block a user
Delete Branch "benvin/repo-defaults"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
private: falseon both repo definitionsstatus_check_contexts: ["ci/woodpecker/pr/build"]to the main branch protection rule on both reposNote 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 namedbuild(covering test + dry-run), so the required context follows the Woodpecker conventionci/woodpecker/pr/<pipeline>used by node-lookup/artifactapi:ci/woodpecker/pr/build. If separatetest/pre-commitpipelines are added later, extend the list then — requiring contexts that no pipeline reports would block every PR.Reviewed the diff and body only (two repo yamls:
config/git.unkin.net/unkin/repository/{clickhouse-tools,logviewer}.yaml).Checks that pass:
private: false+status_check_contextson both, nothing else.status_check_contextsis a real, correctly-spelled attribute ofmodules/gitea_instance/modules/branch_protection(it maps straight through to the provider'sstatus_check_patternsongitea_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..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/buildcontext "follows the Woodpecker convention ... used by node-lookup/artifactapi." Checked both live via the Gitea API:807d3df) reports three required contexts:ci/woodpecker/pr/pre-commit,ci/woodpecker/pr/test,ci/woodpecker/pr/build.pre-commit,test,build).Neither repo gates on
buildalone — the repo that actually uses a singleci/woodpecker/pr/buildcontext 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, alignstatus_check_contextswith that instead).VERDICT: ISSUES
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.