mi/werkator
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

The branch config takes precedence, including its build definitions

Browse Source 
A branch's committed .gittally.yml describes that branch's CI, so it wins
over the project and repo-install config — the `builds` section included.
Pinning it was wrong: a new build definition can only be tried out by
committing it on a branch, and pinned it neither took effect at build time
nor existed for the watcher, so the job silently never ran.

The watcher now decides per branch from that branch's own definitions,
reading its committed config via `git show` and caching it by head commit,
so the read happens only when the branch moved; an unreadable config falls
back to the primary definitions instead of failing the poll cycle. A
branch's definitions are evaluated for that branch alone, so a definition
committed on one branch can never trigger builds of another.

The pinned set is reduced to what does not describe this branch's build:
secrets (`git`), the host and repository sections (`server`, `gitea`,
`executor`, `watcher`), the sandbox policy (`docker.enabled`/`network`),
and the trust gate (`requirePullRequest`). Letting a branch set its own
build command through a definition grants no new power — `branches.*.
buildCommand` always allowed exactly that — while the sandbox and the gate
decide whether untrusted branch code runs on the host at all.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
mhoennig
2026-08-29 07:29:26 +02:00
co-authored by Claude Opus 5
parent a3faa172f8
commit f5871a0442
11 changed files with 395 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/main/resources/templates/releases.html
+12 -1
View File
@@ -7,8 +7,19 @@
<div th:replace="~{fragments :: nav(${view})}"></div>
<div class="panel release-notes">
<h2>v0.9.15 <span class="muted">— 2026-08-28</span></h2>
<h2>v0.9.15 <span class="muted">— 2026-08-29</span></h2>
<ul>
<li>The <code>.gittally.yml</code> committed on a branch now takes precedence for the
<code>builds</code> section as well — a branch can define its own build definitions
and override those from the project config. The watcher reads each origin branch's
committed configuration, so a new build definition takes effect by committing it on
a branch, without touching any other branch's builds. A branch's definitions apply
to that branch alone.</li>
<li>Pinned to the server side are only the keys that do not describe the branch's build:
secrets (<code>git</code>), the host and repository sections (<code>server</code>,
<code>gitea</code>, <code>executor</code>, <code>watcher</code>), the container sandbox
policy (<code>docker.enabled</code>, <code>docker.network</code>), and the
<code>requirePullRequest</code> gate.</li>
<li><strong>Changed:</strong> the build concurrency limit moved from
<code>builds.maxConcurrent</code> to <code>executor.maxConcurrent</code> (default 1,
no compatibility alias) — the <code>builds</code> section now holds build definitions