This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| clickhouse/clickhouse-server | service | minor | `24.8` → `24.12` |
---
### Configuration
📅 **Schedule**: (UTC)
- Branch creation
- "before 6am on tuesday"
- Automerge
- At any time (no schedule defined)
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC41My4wIiwidXBkYXRlZEluVmVyIjoiNDQuNTMuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiZGVwZW5kZW5jaWVzIl19-->
Status: BLOCKED by branch protection, not by CI, and not superseded. Re-verified against main = 364b7643 (after PR #26 landed).
Why it cannot be merged. The only changed file is .gitea/workflows/ci.yml (1 file, +1/-1). main's branch protection sets protected_file_patterns = ".gitea/workflows/**;.gitignore", so
every route onto main is closed for this change: the merge API rejects it, and a direct push is
rejected by the pre-receive hook. Nothing about this PR is fixable inside the PR — its entire
content lives in a protected file.
Everything else is green. Both required contexts pass on head 15ebce07: CI (SIAX Cloud) / quality (push) and / security (push), both success (2026-09-01T03:03:02Z);
combined state success; required_approvals = 0.
Not superseded — content proof, not path existence:
git show origin/main:.gitea/workflows/ci.yml | grep -n clickhouse/clickhouse-server
91: image: clickhouse/clickhouse-server:24.8
git show pr/27:.gitea/workflows/ci.yml | grep -n clickhouse/clickhouse-server
91: image: clickhouse/clickhouse-server:24.12
The branch is 14 commits behind main, but that costs nothing: git merge-tree --write-tree origin/main pr/27 merges cleanly (exit 0) and the landing set against today's main is exactly .gitea/workflows/ci.yml | 2 +-, 1 file changed — no accidental reverts, no rebase needed.
What Simon has to do (an agent must not): temporarily relax protected_file_patterns on main in the repo's branch-protection settings, merge, restore it.
There is no whitelist for protected files in Gitea — the pattern applies to every user including
site admins, so no amount of permissions solves it from this side.
**Status: BLOCKED by branch protection, not by CI, and not superseded.** Re-verified against
`main` = `364b7643` (after PR #26 landed).
**Why it cannot be merged.** The only changed file is `.gitea/workflows/ci.yml` (1 file, +1/-1).
`main`'s branch protection sets `protected_file_patterns = ".gitea/workflows/**;.gitignore"`, so
every route onto `main` is closed for this change: the merge API rejects it, and a direct push is
rejected by the pre-receive hook. Nothing about this PR is fixable inside the PR — its entire
content lives in a protected file.
**Everything else is green.** Both required contexts pass on head `15ebce07`:
`CI (SIAX Cloud) / quality (push)` and `/ security (push)`, both `success` (2026-09-01T03:03:02Z);
combined state `success`; `required_approvals = 0`.
**Not superseded — content proof, not path existence:**
```
git show origin/main:.gitea/workflows/ci.yml | grep -n clickhouse/clickhouse-server
91: image: clickhouse/clickhouse-server:24.8
git show pr/27:.gitea/workflows/ci.yml | grep -n clickhouse/clickhouse-server
91: image: clickhouse/clickhouse-server:24.12
```
The branch is 14 commits behind `main`, but that costs nothing: `git merge-tree --write-tree
origin/main pr/27` merges cleanly (exit 0) and the landing set against today's `main` is exactly
`.gitea/workflows/ci.yml | 2 +-, 1 file changed` — no accidental reverts, no rebase needed.
**What Simon has to do** (an agent must not): temporarily relax
`protected_file_patterns` on `main` in the repo's branch-protection settings, merge, restore it.
There is no whitelist for protected files in Gitea — the pattern applies to every user including
site admins, so no amount of permissions solves it from this side.
Generated with [Claude Code](https://claude.com/claude-code)
admin
merged commit into main2026-09-08 20:49:02 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
This PR contains the following updates:
24.8→24.12Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate CLI.
Status: BLOCKED by branch protection, not by CI, and not superseded. Re-verified against
main=364b7643(after PR #26 landed).Why it cannot be merged. The only changed file is
.gitea/workflows/ci.yml(1 file, +1/-1).main's branch protection setsprotected_file_patterns = ".gitea/workflows/**;.gitignore", soevery route onto
mainis closed for this change: the merge API rejects it, and a direct push isrejected by the pre-receive hook. Nothing about this PR is fixable inside the PR — its entire
content lives in a protected file.
Everything else is green. Both required contexts pass on head
15ebce07:CI (SIAX Cloud) / quality (push)and/ security (push), bothsuccess(2026-09-01T03:03:02Z);combined state
success;required_approvals = 0.Not superseded — content proof, not path existence:
The branch is 14 commits behind
main, but that costs nothing:git merge-tree --write-tree origin/main pr/27merges cleanly (exit 0) and the landing set against today'smainis exactly.gitea/workflows/ci.yml | 2 +-, 1 file changed— no accidental reverts, no rebase needed.What Simon has to do (an agent must not): temporarily relax
protected_file_patternsonmainin the repo's branch-protection settings, merge, restore it.There is no whitelist for protected files in Gitea — the pattern applies to every user including
site admins, so no amount of permissions solves it from this side.
Generated with Claude Code