yadflow 3.15.4 → 3.15.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +9 -0
- package/cli/doctor.mjs +5 -1
- package/package.json +1 -1
- package/skills/yad-checks/SKILL.md +5 -2
- package/skills/yad-checks/templates/checks/ledger-guard.sh +42 -3
- package/skills/yad-connect-repos/SKILL.md +5 -1
- package/skills/yad-connect-repos/references/hub-config.md +2 -1
- package/skills/yad-hub-bridge/SKILL.md +6 -3
- package/skills/yad-hub-bridge/references/bridge.md +32 -12
- package/skills/yad-hub-bridge/templates/github/yad-gate-sync.yml +81 -10
- package/skills/yad-hub-bridge/templates/gitlab/yad-gate-sync.gitlab-ci.yml +45 -9
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,12 @@
|
|
|
1
|
+
## [3.15.5](https://github.com/abdelrahmannasr/yadflow/compare/v3.15.4...v3.15.5) (2026-08-12)
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
### Bug Fixes
|
|
5
|
+
|
|
6
|
+
* **bridge:** resolve the wired gate-sync pin from the repo, not a floating major ([8489bf5](https://github.com/abdelrahmannasr/yadflow/commit/8489bf5298f529868dc65085068882b59e89bbb5)), closes [#163](https://github.com/abdelrahmannasr/yadflow/issues/163) [#163](https://github.com/abdelrahmannasr/yadflow/issues/163)
|
|
7
|
+
* **checks:** require a platform for the ledger-guard bridge gate ([297d13a](https://github.com/abdelrahmannasr/yadflow/commit/297d13a0ebf26bec995ce64e0aacfa022b228e18)), closes [#185](https://github.com/abdelrahmannasr/yadflow/issues/185) [#186](https://github.com/abdelrahmannasr/yadflow/issues/186)
|
|
8
|
+
* **checks:** scope the ledger-guard bridge read to root-level keys ([4fb83a9](https://github.com/abdelrahmannasr/yadflow/commit/4fb83a968d4537e89a9367d72418aede9cf305f0)), closes [#186](https://github.com/abdelrahmannasr/yadflow/issues/186) [#186](https://github.com/abdelrahmannasr/yadflow/issues/186)
|
|
9
|
+
|
|
1
10
|
## [3.15.4](https://github.com/abdelrahmannasr/yadflow/compare/v3.15.3...v3.15.4) (2026-08-12)
|
|
2
11
|
|
|
3
12
|
## [3.15.3](https://github.com/abdelrahmannasr/yadflow/compare/v3.15.2...v3.15.3) (2026-08-11)
|
package/cli/doctor.mjs
CHANGED
|
@@ -62,7 +62,11 @@ export function projectChecks(checks, root) {
|
|
|
62
62
|
// version stamp
|
|
63
63
|
const ver = readJSON(verPath, null);
|
|
64
64
|
if (!ver) check(checks, 'cli-version', 'project', 'warn', `${PROJECT_FILES.version} missing or unreadable`, 'run `yad check --fix`');
|
|
65
|
-
|
|
65
|
+
// The stamp is not only cosmetic: in bridge mode the wired gate-sync job resolves the yadflow it
|
|
66
|
+
// RUNS from it — unless hub.json pins `gate_sync_version`, a YAD_VERSION variable overrides, or the
|
|
67
|
+
// stamp is not an exact release of the current major (then the job skips it and floats). So a stale
|
|
68
|
+
// stamp can mean CI is running an old gate; say so, or the warning reads as bookkeeping.
|
|
69
|
+
else if (ver.version !== VERSION) check(checks, 'cli-version', 'project', 'warn', `project stamped v${ver.version}, CLI is v${VERSION} — this also drives the wired gate-sync pin`, 'run `yad update` to reconcile');
|
|
66
70
|
else check(checks, 'cli-version', 'project', 'ok', `version stamp matches (v${VERSION})`);
|
|
67
71
|
|
|
68
72
|
// hub.json: parse + shape
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "yadflow",
|
|
3
|
-
"version": "3.15.
|
|
3
|
+
"version": "3.15.5",
|
|
4
4
|
"description": "Yadflow — the gated, team, multi-repo SDLC: author → review → build with a PR-driven review gate and a zero-dependency `yad` CLI (setup, gate, commit, open-pr, ship, repo, thread, reconcile). A BMAD module + 38 yad-* skills.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"author": "AbdelRahman Nasr",
|
|
@@ -51,8 +51,11 @@ and GitLab CI. This step is **by hand** in Phase 3 — run the gates with the sk
|
|
|
51
51
|
- Canonical gate sources live in this skill's `templates/` (the source of truth that gets installed
|
|
52
52
|
into each code repo):
|
|
53
53
|
- `templates/checks/{spec-link,contract-check,build-test-lint,verified-commits}.sh`
|
|
54
|
-
- `templates/checks/ledger-guard.sh` → **hub-only** gate, active **only in bridge mode**
|
|
55
|
-
|
|
54
|
+
- `templates/checks/ledger-guard.sh` → **hub-only** gate, active **only in bridge mode** — hub.json
|
|
55
|
+
carries BOTH a `platform` and `bridge_enabled` (or the legacy `bridge`) true, the same predicate
|
|
56
|
+
`isBridge` (`cli/gate.mjs`) applies, so the gate and the CLI can never disagree about who owns the
|
|
57
|
+
ledger (#186). A no-op otherwise, when humans legitimately own it. On review PRs it FAILs any
|
|
58
|
+
commit that touches the
|
|
56
59
|
CI-owned gate ledger (`.sdlc/{state,approvals,comments,hub-prs}.json`, `reviews/*.md`) unless it
|
|
57
60
|
is a **verified gate-bot commit** — bot-authored AND platform-Verified, since author text alone is
|
|
58
61
|
spoofable. `.sdlc/contract-lock.json` is artifact-side and exempt. So is a **new epic's seed**:
|
|
@@ -20,16 +20,55 @@
|
|
|
20
20
|
# distinguishes CI-generated commits. A spoofed-author commit that is not Verified is treated as a
|
|
21
21
|
# human edit and rejected.
|
|
22
22
|
#
|
|
23
|
-
# Scope: enforced ONLY when the bridge is enabled
|
|
24
|
-
# (
|
|
23
|
+
# Scope: enforced ONLY when the bridge is enabled — hub.json carries BOTH a `platform` and
|
|
24
|
+
# `bridge_enabled` (or the legacy `bridge`) true, the same predicate `isBridge` (cli/gate.mjs) and
|
|
25
|
+
# `hubActions` (cli/plan.mjs) apply. Without the bridge (file-only / non-bridge, or a platform-less
|
|
26
|
+
# hub) humans legitimately write the ledger locally, so the gate is a no-op.
|
|
25
27
|
#
|
|
26
28
|
# Degradation: a base ref that cannot be resolved FAILs closed; no platform (cannot read the Verified
|
|
27
29
|
# badge) WARNs and waives the signature half — the same stance verified-commits takes.
|
|
28
30
|
set -euo pipefail
|
|
29
31
|
|
|
30
32
|
# ---- bridge gate: only CI-owned ledgers are guarded -------------------------------------------
|
|
33
|
+
# The predicate is BOTH a platform and the bridge flag, exactly as `isBridge` (cli/gate.mjs) and
|
|
34
|
+
# `hubActions` (cli/plan.mjs) define it. Requiring the flag alone put this gate out of step with every
|
|
35
|
+
# other bridge detector (issue #186): a hub carrying `bridge_enabled: true` with no `platform` would
|
|
36
|
+
# have its human ledger commits rejected here while the CLI, reading the same file, called it
|
|
37
|
+
# file-only and kept the LOCAL write path — no CI writer and no permitted human writer, so no gate
|
|
38
|
+
# could advance. Reachable through a stale install (platform set, script wired, platform later
|
|
39
|
+
# nulled), not through `yad setup`, which derives both from one value.
|
|
40
|
+
#
|
|
41
|
+
# `tr -d '\n'` first, like every other hub.json read in these gates: a key and its value may legally
|
|
42
|
+
# sit on separate lines, and a per-line match would MISS the flag and silently no-op a security gate
|
|
43
|
+
# (the fail-open direction of issue #161).
|
|
44
|
+
#
|
|
45
|
+
# Matched at the ROOT LEVEL only. The shared `default_branch` read below is depth-blind, and that is
|
|
46
|
+
# survivable there — a false match yields a bogus branch name and the gate fails loudly. Here it is
|
|
47
|
+
# not: a nested `"bridge": true` (say under `review`) would silently ENABLE this gate on a hub whose
|
|
48
|
+
# `isBridge` is false, recreating the exact no-writer deadlock #186 is about, from the other side. So
|
|
49
|
+
# the nesting is stripped rather than ignored: peel the outermost braces, then delete innermost
|
|
50
|
+
# objects/arrays until none remain, leaving only root-level pairs to match against. Not a JSON parser
|
|
51
|
+
# — a value containing a literal brace would confuse it — but hub.json is machine-written and the
|
|
52
|
+
# failure it prevents is the one that matters.
|
|
53
|
+
#
|
|
54
|
+
# Flattened ONCE into a variable and matched with here-strings, never `tr … | grep -q`: under the
|
|
55
|
+
# `pipefail` set above, `grep -q` exits at the first match and can SIGPIPE `tr`, which would make a
|
|
56
|
+
# MATCHING pipeline report failure. Reading from a here-string has no upstream process to kill.
|
|
31
57
|
HUB="${SDLC_HUB_CONFIG:-.sdlc/hub.json}"
|
|
32
|
-
|
|
58
|
+
HUB_FLAT="$(tr -d '\n' < "$HUB" 2>/dev/null || true)"
|
|
59
|
+
HUB_ROOT="${HUB_FLAT#*\{}"
|
|
60
|
+
HUB_ROOT="${HUB_ROOT%\}*}"
|
|
61
|
+
while :; do
|
|
62
|
+
_stripped="$(sed -E 's/\{[^{}]*\}//g; s/\[[^][]*\]//g' <<< "$HUB_ROOT")"
|
|
63
|
+
[ "$_stripped" = "$HUB_ROOT" ] && break
|
|
64
|
+
HUB_ROOT="$_stripped"
|
|
65
|
+
done
|
|
66
|
+
# One line in, so `sed` emits at most one line out — no `head` needed (which would re-introduce the
|
|
67
|
+
# SIGPIPE-under-pipefail problem this avoids).
|
|
68
|
+
hub_str() { sed -nE "s/.*\"$1\"[[:space:]]*:[[:space:]]*\"([^\"]*)\".*/\1/p" <<< "$HUB_ROOT"; }
|
|
69
|
+
hub_true() { grep -Eq "\"$1\"[[:space:]]*:[[:space:]]*true" <<< "$HUB_ROOT"; }
|
|
70
|
+
|
|
71
|
+
if [ ! -f "$HUB" ] || [ -z "$(hub_str platform)" ] || { ! hub_true bridge_enabled && ! hub_true bridge; }; then
|
|
33
72
|
echo "PASS [ledger-guard]: bridge not enabled — the ledger is locally owned, nothing to guard."
|
|
34
73
|
exit 0
|
|
35
74
|
fi
|
|
@@ -148,7 +148,11 @@ write only `{project-root}/.sdlc/hub.json` (`config.yaml` `hub.config`) — neve
|
|
|
148
148
|
- **`detect-hub`** — detect the hub's own platform and upsert `.sdlc/hub.json`. Run
|
|
149
149
|
`git remote get-url origin` **on the hub** and read the host with the SAME logic Step 1 uses for code
|
|
150
150
|
repos: `github.com` → `github`, GitLab host → `gitlab`, no remote → `platform: null`. Record
|
|
151
|
-
`git_url`, `default_branch`, `detectedAt`, and `bridge_enabled
|
|
151
|
+
`git_url`, `default_branch`, `detectedAt`, and `bridge_enabled` — **`true` only when a platform was
|
|
152
|
+
detected, `false` alongside `platform: null`** (preserve an existing roster). The two travel
|
|
153
|
+
together: bridge mode is a platform AND the flag (`isBridge`, `cli/gate.mjs`), and `yad setup`
|
|
154
|
+
derives both from one value, so writing the flag onto a platform-less hub creates a state no CLI
|
|
155
|
+
path can produce and the gates read differently (#186).
|
|
152
156
|
Auth is the local user's own `gh`/`glab`/git; **store no tokens**. Idempotent — safe to re-run.
|
|
153
157
|
- **`roster`** — set one roster entry mapping a platform `login` → SDLC `name` + `email` + a per-scope
|
|
154
158
|
`roles` map (`roles: { hub: ["owner","reviewer"], <repo>: ["domain-owner", …] }`). Upsert by `login`;
|
|
@@ -18,7 +18,8 @@ login to an SDLC name + role. It is a single object for the hub itself — the s
|
|
|
18
18
|
"platform": "github", // github | gitlab (from the hub's own remote host); null when local-only
|
|
19
19
|
"git_url": "https://github.com/abdelrahmannasr/yadflow.git", // REQUIRED when platform is non-null (scopes auth + opens PRs); yad doctor warns YAD-CFG-005 if absent
|
|
20
20
|
"default_branch": "main",
|
|
21
|
-
"bridge_enabled": true, // open review PRs/MRs on the hub for front-half reviews
|
|
21
|
+
"bridge_enabled": true, // open review PRs/MRs on the hub for front-half reviews; travels WITH platform — bridge mode is both (isBridge), so never true beside platform: null (#186)
|
|
22
|
+
"gate_sync_version": "3.15.3", // OPTIONAL exact pin for the wired gate-sync job; an exact 3.x.y, prereleases included (3.16.0-rc.1) — anything else is skipped. Omitted => the .sdlc/cli-version.json stamp if that qualifies, else floating 3
|
|
22
23
|
"review": { "requireEngagement": false }, // Review Companion: false (soft) counts bare approves but nudges; true counts only verified-engagement approvals
|
|
23
24
|
"detectedAt": "2026-06-08", // last detect-hub run (YYYY-MM-DD)
|
|
24
25
|
"roster": [
|
|
@@ -103,9 +103,12 @@ default branch. (File-only mode keeps `yad gate sync` as the local writer.)
|
|
|
103
103
|
- GitLab → `.gitlab/ci/yad-gate-sync.yml` (from `templates/gitlab/yad-gate-sync.gitlab-ci.yml`)
|
|
104
104
|
- plus the hub-side **verified-commits** gate (`checks/verified-commits.sh` + its workflow/fragment,
|
|
105
105
|
owned by `yad-checks`) so review PRs accept only signed commits from roster-known authors
|
|
106
|
-
- the wired job runs
|
|
107
|
-
|
|
108
|
-
|
|
106
|
+
- the wired job runs an **exact** version, resolved at run time from the repo: the `YAD_VERSION`
|
|
107
|
+
variable, else `hub.json` `gate_sync_version`, else the `.sdlc/cli-version.json` stamp, else the
|
|
108
|
+
floating `3`. It stopped floating on the major because that let a release change a scheduled job's
|
|
109
|
+
behaviour unattended — how #163's churn reached hubs that never opted in. So upgrading is now a
|
|
110
|
+
deliberate act (`yad update`); if the resolved pin predates 3.15.3, upgrade or disable the
|
|
111
|
+
schedule. Never edit a version into the wired file — `yad check --fix` rewrites it byte-for-byte
|
|
109
112
|
from the template. See `references/bridge.md`.
|
|
110
113
|
2. **GitLab only — two one-time steps** (see the fragment's header for the exact recipes):
|
|
111
114
|
- add `include: - local: '.gitlab/ci/yad-gate-sync.yml'` to the root `.gitlab-ci.yml`, or write
|
|
@@ -111,6 +111,9 @@ login and requested too — otherwise an escalated step is structurally unsatisf
|
|
|
111
111
|
reorder commit per epic (the records are the same; only their order changes), then converges
|
|
112
112
|
permanently. On an older yadflow the workaround is to disable the pipeline schedule — merges still
|
|
113
113
|
advance gates via the push path; only the catch-up for squash merges and bare approvals is lost.
|
|
114
|
+
Since the wired job now runs an exact pin rather than floating on the major, that upgrade is a
|
|
115
|
+
deliberate act: `yad update` (which re-stamps `.sdlc/cli-version.json`), or a `gate_sync_version` in
|
|
116
|
+
`hub.json` — see the version table below.
|
|
114
117
|
|
|
115
118
|
## Contract re-lock invalidates prior platform approvals too
|
|
116
119
|
|
|
@@ -182,18 +185,32 @@ other way — up through its first review PR/MR; see "the seed of a new epic" be
|
|
|
182
185
|
**Which yadflow the wired job runs.** Both fragments resolve the version from a `YAD_VERSION` variable
|
|
183
186
|
and fall back to `3`:
|
|
184
187
|
|
|
185
|
-
|
|
|
188
|
+
| # | Source | Set it in |
|
|
186
189
|
|---|---|---|
|
|
187
|
-
|
|
|
188
|
-
|
|
|
189
|
-
|
|
190
|
-
|
|
191
|
-
|
|
192
|
-
|
|
193
|
-
version.
|
|
194
|
-
|
|
195
|
-
|
|
196
|
-
|
|
190
|
+
| 1 | `YAD_VERSION` — used **verbatim**, the operator's override | GitHub: Settings → Secrets and variables → Actions → **Variables**. GitLab: Settings → CI/CD → **Variables** (beside `SDLC_GATE_TOKEN`) |
|
|
191
|
+
| 2 | `.sdlc/hub.json` → `gate_sync_version` — this hub's committed pin | edit `hub.json`, commit it |
|
|
192
|
+
| 3 | `.sdlc/cli-version.json` → `version` — the yadflow that last wired the hub | `yad update` re-stamps it |
|
|
193
|
+
| 4 | `3` — floating major, only when nothing above resolves | — |
|
|
194
|
+
|
|
195
|
+
Sources 2 and 3 are **validated** before use: an exact `3.x.y` release token, prereleases included
|
|
196
|
+
(`3.16.0-rc.1` is a legitimate pin; `latest` and a bare `3` are not). A `.sdlc/cli-version.json`
|
|
197
|
+
written by a long-untouched project can still say something like `1.0.2`, a version with no `yad gate ci`
|
|
198
|
+
in it at all, and the value is interpolated into `npx -p "yadflow@$V"` on a runner holding a push token —
|
|
199
|
+
so anything that is not an exact release of this major is skipped, loudly, in favour of the next source.
|
|
200
|
+
`YAD_VERSION` is exempt: it is a human's deliberate act, and it is the only way to cross a major.
|
|
201
|
+
|
|
202
|
+
**Why this is no longer a floating major.** It used to be, on the argument that a published fix should
|
|
203
|
+
reach a scheduled job with nobody in the loop — this page's own issue #163 as the example. The same
|
|
204
|
+
mechanism is how #163's churn *arrived*: the CI fragment ran `yadflow@3`, so 3.13.1 rolled onto every
|
|
205
|
+
wired hub automatically and took the reporting one from 20 to 96 churn commits an hour, with nobody
|
|
206
|
+
deciding to upgrade. Issue #163's fourth suggested fix was to stop that. The trade-off is real and cuts
|
|
207
|
+
both ways — a hub is no longer carried onto a fix for free, so **if the resolved pin is older than
|
|
208
|
+
3.15.3, run `yad update` or disable the schedule** (`yad doctor` flags a stale stamp).
|
|
209
|
+
|
|
210
|
+
The pin is **never stamped into the wired file**: `yad` owns that file and `yad check --fix` rewrites it
|
|
211
|
+
byte-for-byte from the template, so a version edited into it would report `outdated` on every check and
|
|
212
|
+
be reverted on the next sync. That is exactly why the job resolves it from committed files at run time
|
|
213
|
+
instead — the fragment itself stays byte-identical to what ships.
|
|
197
214
|
|
|
198
215
|
**Why no pre-merge write fixes the gate.** Keeping CI off the PR head means an in-flight approval is
|
|
199
216
|
never dismissed by a CI commit, and the PR's required checks never strand on a `[skip ci]` CI commit.
|
|
@@ -204,7 +221,10 @@ commit — the advance plus the `draft → approved` status flip — lands on th
|
|
|
204
221
|
|
|
205
222
|
**The ledger is CI-owned (bridge mode only).** Humans never commit gate-state files: the `ledger-guard`
|
|
206
223
|
check (yad-checks) FAILs any commit on a review PR that touches `.sdlc/{state,approvals,comments,hub-prs}
|
|
207
|
-
.json` or `reviews/*.md` (`.sdlc/contract-lock.json` is artifact-side and allowed).
|
|
224
|
+
.json` or `reviews/*.md` (`.sdlc/contract-lock.json` is artifact-side and allowed). "Bridge mode" there
|
|
225
|
+
means the same thing it means everywhere else — a `platform` **and** the bridge flag, `isBridge`'s
|
|
226
|
+
predicate. The gate used to enable itself on the flag alone, which let a platform-less hub reject the
|
|
227
|
+
human's ledger write while the CLI still expected one (#186). Under Path B **no
|
|
208
228
|
CI commit lands in a review PR at all**, so the only ledger change the guard can see there is a human
|
|
209
229
|
edit — which it rejects, with one carve-out for a new epic's seed (below). (The `verified-commits`
|
|
210
230
|
gate still vets every commit's signature + author;
|
|
@@ -23,7 +23,9 @@
|
|
|
23
23
|
# and nothing is committed — re-visiting a merged review for a week costs one no-op read per pass. That
|
|
24
24
|
# last part is load-bearing: before the #163 fix the re-sync re-appended each step's approvals at the
|
|
25
25
|
# tail, so this job rotated approvals.json and committed the reorder every 15 minutes, forever (issue
|
|
26
|
-
# #163).
|
|
26
|
+
# #163). These jobs run an EXACT version resolved from the repo (see the resolver in each job), so a
|
|
27
|
+
# hub sitting on a pre-#163 yadflow keeps that behaviour until someone upgrades it — if the resolved
|
|
28
|
+
# pin is older than 3.15.3, run `yad update` or disable the schedule.
|
|
27
29
|
# On GitHub a scheduled workflow runs automatically once committed (no setup).
|
|
28
30
|
#
|
|
29
31
|
# CI never approves and never merges — the merge click is the human approval act.
|
|
@@ -45,13 +47,16 @@ permissions:
|
|
|
45
47
|
pull-requests: read # gh pr view + reviewThreads GraphQL
|
|
46
48
|
|
|
47
49
|
env:
|
|
48
|
-
#
|
|
49
|
-
#
|
|
50
|
-
#
|
|
51
|
-
#
|
|
52
|
-
#
|
|
53
|
-
#
|
|
54
|
-
|
|
50
|
+
# The manual override for which yadflow these jobs run: set a repository (or organization) Actions
|
|
51
|
+
# **variable** named YAD_VERSION to e.g. `3.15.2`, under Settings → Secrets and variables → Actions →
|
|
52
|
+
# Variables. It lives there and not in this file, which `yad` owns and rewrites byte-for-byte from
|
|
53
|
+
# its template on every sync — a version edited in here would be silently reverted.
|
|
54
|
+
#
|
|
55
|
+
# Left EMPTY the jobs resolve an exact pin from the repo itself instead of floating on the major (see
|
|
56
|
+
# the resolver step in each job). Floating meant a release could change what a scheduled job does with
|
|
57
|
+
# nobody deciding to upgrade — the amplification path in issue #163, where 3.13.1 took one hub from 20
|
|
58
|
+
# to 96 churn commits an hour.
|
|
59
|
+
YAD_VERSION: ${{ vars.YAD_VERSION || '' }}
|
|
55
60
|
|
|
56
61
|
jobs:
|
|
57
62
|
mergesync:
|
|
@@ -77,6 +82,39 @@ jobs:
|
|
|
77
82
|
- uses: actions/setup-node@v7
|
|
78
83
|
with:
|
|
79
84
|
node-version: "20"
|
|
85
|
+
- name: Resolve the yadflow pin
|
|
86
|
+
run: |
|
|
87
|
+
# >>> yad-pin
|
|
88
|
+
# Which yadflow this job runs, most explicit source first:
|
|
89
|
+
# 1. $YAD_VERSION — the platform variable, a human's deliberate override, verbatim
|
|
90
|
+
# 2. .sdlc/hub.json — "gate_sync_version", the committed pin for this hub
|
|
91
|
+
# 3. .sdlc/cli-version.json — the version that last wired it (`yad update` re-stamps this)
|
|
92
|
+
# 4. 3 — floating major, only when nothing above resolves
|
|
93
|
+
# Sources 2 and 3 are machine-written files a stale or hand-edited checkout can get wrong, so
|
|
94
|
+
# they are VALIDATED: an exact release token of the major this fragment was written for. That
|
|
95
|
+
# also keeps the value safe to interpolate into `npx -p "yadflow@$V"` — a repo-controlled
|
|
96
|
+
# string reaching a shell on a runner holding `contents: write` is the same class of hole the
|
|
97
|
+
# HEAD_REF fix closed. Anything unparseable is skipped loudly rather than failing the run.
|
|
98
|
+
# Pipes, not bash here-strings, so the block stays byte-identical to the GitLab fragment's
|
|
99
|
+
# (which must run under `sh` when an image has no bash). `sed` drains its input, so nothing
|
|
100
|
+
# SIGPIPEs `tr`.
|
|
101
|
+
yad_pin_read() { # <file> <key>
|
|
102
|
+
[ -f "$1" ] || return 0
|
|
103
|
+
tr -d '\n' < "$1" 2>/dev/null | sed -nE "s/.*\"$2\"[[:space:]]*:[[:space:]]*\"([^\"]*)\".*/\1/p"
|
|
104
|
+
}
|
|
105
|
+
yad_pin_valid() { printf '%s' "${1:-}" | grep -Eq '^3\.[0-9]+\.[0-9]+(-[0-9A-Za-z.]+)?$'; }
|
|
106
|
+
YAD_PKG="${YAD_VERSION:-}"
|
|
107
|
+
if [ -z "$YAD_PKG" ]; then
|
|
108
|
+
for _cand in "$(yad_pin_read .sdlc/hub.json gate_sync_version)" "$(yad_pin_read .sdlc/cli-version.json version)"; do
|
|
109
|
+
[ -n "$_cand" ] || continue
|
|
110
|
+
if yad_pin_valid "$_cand"; then YAD_PKG="$_cand"; break; fi
|
|
111
|
+
echo "yad-gate-sync: ignoring pin '${_cand}' — not an exact 3.x release." >&2
|
|
112
|
+
done
|
|
113
|
+
fi
|
|
114
|
+
YAD_PKG="${YAD_PKG:-3}"
|
|
115
|
+
echo "yad-gate-sync: running yadflow@${YAD_PKG}"
|
|
116
|
+
# <<< yad-pin
|
|
117
|
+
echo "YAD_PKG=${YAD_PKG}" >> "$GITHUB_ENV"
|
|
80
118
|
- name: Advance the gate on merge
|
|
81
119
|
# The head ref reaches the shell through `env:`, never through `${{ }}` inside `run:`. A
|
|
82
120
|
# branch name may legally contain `$`, backticks and parentheses, so a PR opened from
|
|
@@ -88,7 +126,7 @@ jobs:
|
|
|
88
126
|
run: |
|
|
89
127
|
git config user.name "yad-gate-sync[bot]"
|
|
90
128
|
git config user.email "yad-gate-sync[bot]@users.noreply.github.com"
|
|
91
|
-
npx -y -p "yadflow@${
|
|
129
|
+
npx -y -p "yadflow@${YAD_PKG}" yad gate ci \
|
|
92
130
|
--branch "$HEAD_REF" \
|
|
93
131
|
--pr "$PR_NUMBER" \
|
|
94
132
|
--merged
|
|
@@ -112,6 +150,39 @@ jobs:
|
|
|
112
150
|
- uses: actions/setup-node@v7
|
|
113
151
|
with:
|
|
114
152
|
node-version: "20"
|
|
153
|
+
- name: Resolve the yadflow pin
|
|
154
|
+
run: |
|
|
155
|
+
# >>> yad-pin
|
|
156
|
+
# Which yadflow this job runs, most explicit source first:
|
|
157
|
+
# 1. $YAD_VERSION — the platform variable, a human's deliberate override, verbatim
|
|
158
|
+
# 2. .sdlc/hub.json — "gate_sync_version", the committed pin for this hub
|
|
159
|
+
# 3. .sdlc/cli-version.json — the version that last wired it (`yad update` re-stamps this)
|
|
160
|
+
# 4. 3 — floating major, only when nothing above resolves
|
|
161
|
+
# Sources 2 and 3 are machine-written files a stale or hand-edited checkout can get wrong, so
|
|
162
|
+
# they are VALIDATED: an exact release token of the major this fragment was written for. That
|
|
163
|
+
# also keeps the value safe to interpolate into `npx -p "yadflow@$V"` — a repo-controlled
|
|
164
|
+
# string reaching a shell on a runner holding `contents: write` is the same class of hole the
|
|
165
|
+
# HEAD_REF fix closed. Anything unparseable is skipped loudly rather than failing the run.
|
|
166
|
+
# Pipes, not bash here-strings, so the block stays byte-identical to the GitLab fragment's
|
|
167
|
+
# (which must run under `sh` when an image has no bash). `sed` drains its input, so nothing
|
|
168
|
+
# SIGPIPEs `tr`.
|
|
169
|
+
yad_pin_read() { # <file> <key>
|
|
170
|
+
[ -f "$1" ] || return 0
|
|
171
|
+
tr -d '\n' < "$1" 2>/dev/null | sed -nE "s/.*\"$2\"[[:space:]]*:[[:space:]]*\"([^\"]*)\".*/\1/p"
|
|
172
|
+
}
|
|
173
|
+
yad_pin_valid() { printf '%s' "${1:-}" | grep -Eq '^3\.[0-9]+\.[0-9]+(-[0-9A-Za-z.]+)?$'; }
|
|
174
|
+
YAD_PKG="${YAD_VERSION:-}"
|
|
175
|
+
if [ -z "$YAD_PKG" ]; then
|
|
176
|
+
for _cand in "$(yad_pin_read .sdlc/hub.json gate_sync_version)" "$(yad_pin_read .sdlc/cli-version.json version)"; do
|
|
177
|
+
[ -n "$_cand" ] || continue
|
|
178
|
+
if yad_pin_valid "$_cand"; then YAD_PKG="$_cand"; break; fi
|
|
179
|
+
echo "yad-gate-sync: ignoring pin '${_cand}' — not an exact 3.x release." >&2
|
|
180
|
+
done
|
|
181
|
+
fi
|
|
182
|
+
YAD_PKG="${YAD_PKG:-3}"
|
|
183
|
+
echo "yad-gate-sync: running yadflow@${YAD_PKG}"
|
|
184
|
+
# <<< yad-pin
|
|
185
|
+
echo "YAD_PKG=${YAD_PKG}" >> "$GITHUB_ENV"
|
|
115
186
|
- name: Reconcile recently-merged review PRs
|
|
116
187
|
run: |
|
|
117
188
|
git config user.name "yad-gate-sync[bot]"
|
|
@@ -130,7 +201,7 @@ jobs:
|
|
|
130
201
|
[ -n "$N" ] || continue
|
|
131
202
|
REF="$(gh pr view "$N" --json headRefName --jq '.headRefName' 2>/dev/null)" || rc=1
|
|
132
203
|
case "$REF" in
|
|
133
|
-
review/EP-*) npx -y -p "yadflow@${
|
|
204
|
+
review/EP-*) npx -y -p "yadflow@${YAD_PKG}" yad gate ci --branch "$REF" --pr "$N" --merged || rc=1 ;;
|
|
134
205
|
esac
|
|
135
206
|
done < /tmp/yad-merged-prs
|
|
136
207
|
exit $rc
|
|
@@ -36,12 +36,16 @@
|
|
|
36
36
|
# pipeline or run `yad gate ci --branch <review-branch> --pr <iid> --merged` locally on the default
|
|
37
37
|
# branch (advisory `yad gate sync` is read-only in bridge mode and cannot recover a stuck gate).
|
|
38
38
|
#
|
|
39
|
-
# Which yadflow this job runs:
|
|
40
|
-
#
|
|
41
|
-
#
|
|
42
|
-
#
|
|
43
|
-
#
|
|
44
|
-
#
|
|
39
|
+
# Which yadflow this job runs: an EXACT version resolved from the repo at run time — see the `yad-pin`
|
|
40
|
+
# block in the script below for the precedence. It no longer floats on the major, because floating let a
|
|
41
|
+
# release change what a scheduled job does with nobody deciding to upgrade (issue #163, where 3.13.1
|
|
42
|
+
# took one hub from 20 to 96 churn commits an hour). The trade-off is deliberate and cuts both ways: a
|
|
43
|
+
# hub is no longer carried onto a fix automatically, so if the resolved pin is older than 3.15.3, run
|
|
44
|
+
# `yad update` or disable this schedule.
|
|
45
|
+
#
|
|
46
|
+
# To override it, set a CI/CD variable YAD_VERSION (e.g. `3.15.2`) in project Settings → CI/CD →
|
|
47
|
+
# Variables — the same place SDLC_GATE_TOKEN lives, and deliberately NOT in this file, which `yad` owns
|
|
48
|
+
# and rewrites byte-for-byte from its template on every sync.
|
|
45
49
|
variables:
|
|
46
50
|
GIT_DEPTH: "0" # full history: gate ci pushes the advance to the default branch
|
|
47
51
|
|
|
@@ -82,6 +86,37 @@ yad-gate-sync:
|
|
|
82
86
|
- export GITLAB_TOKEN="$SDLC_GATE_TOKEN" GITLAB_HOST="$CI_SERVER_URL"
|
|
83
87
|
- git fetch origin "$CI_DEFAULT_BRANCH"
|
|
84
88
|
- git checkout -B "$CI_DEFAULT_BRANCH" "origin/$CI_DEFAULT_BRANCH"
|
|
89
|
+
- |
|
|
90
|
+
# >>> yad-pin
|
|
91
|
+
# Which yadflow this job runs, most explicit source first:
|
|
92
|
+
# 1. $YAD_VERSION — the CI/CD variable, a human's deliberate override, verbatim
|
|
93
|
+
# 2. .sdlc/hub.json — "gate_sync_version", the committed pin for this hub
|
|
94
|
+
# 3. .sdlc/cli-version.json — the version that last wired it (`yad update` re-stamps this)
|
|
95
|
+
# 4. 3 — floating major, only when nothing above resolves
|
|
96
|
+
# Sources 2 and 3 are machine-written files a stale or hand-edited checkout can get wrong, so
|
|
97
|
+
# they are VALIDATED: an exact release token of the major this fragment was written for. That
|
|
98
|
+
# also keeps the value safe to interpolate into `npx -p "yadflow@$V"` — a repo-controlled
|
|
99
|
+
# string reaching a shell on a runner holding a push token. Anything unparseable is skipped
|
|
100
|
+
# loudly rather than failing the run. Resolved once here; GitLab runs every `script` line in
|
|
101
|
+
# the same shell, so YAD_PKG carries into the block below.
|
|
102
|
+
# Pipes, not bash here-strings: a GitLab runner falls back to `sh` when the image has no bash,
|
|
103
|
+
# and `<<<` is a bashism. `sed` drains its input (no early exit, so nothing SIGPIPEs `tr`).
|
|
104
|
+
yad_pin_read() { # <file> <key>
|
|
105
|
+
[ -f "$1" ] || return 0
|
|
106
|
+
tr -d '\n' < "$1" 2>/dev/null | sed -nE "s/.*\"$2\"[[:space:]]*:[[:space:]]*\"([^\"]*)\".*/\1/p"
|
|
107
|
+
}
|
|
108
|
+
yad_pin_valid() { printf '%s' "${1:-}" | grep -Eq '^3\.[0-9]+\.[0-9]+(-[0-9A-Za-z.]+)?$'; }
|
|
109
|
+
YAD_PKG="${YAD_VERSION:-}"
|
|
110
|
+
if [ -z "$YAD_PKG" ]; then
|
|
111
|
+
for _cand in "$(yad_pin_read .sdlc/hub.json gate_sync_version)" "$(yad_pin_read .sdlc/cli-version.json version)"; do
|
|
112
|
+
[ -n "$_cand" ] || continue
|
|
113
|
+
if yad_pin_valid "$_cand"; then YAD_PKG="$_cand"; break; fi
|
|
114
|
+
echo "yad-gate-sync: ignoring pin '${_cand}' — not an exact 3.x release." >&2
|
|
115
|
+
done
|
|
116
|
+
fi
|
|
117
|
+
YAD_PKG="${YAD_PKG:-3}"
|
|
118
|
+
echo "yad-gate-sync: running yadflow@${YAD_PKG}"
|
|
119
|
+
# <<< yad-pin
|
|
85
120
|
- |
|
|
86
121
|
rc=0
|
|
87
122
|
if [ "$CI_PIPELINE_SOURCE" = "schedule" ]; then
|
|
@@ -91,7 +126,8 @@ yad-gate-sync:
|
|
|
91
126
|
# unchanged approval record produces an unchanged file and nothing is committed. That last part
|
|
92
127
|
# is load-bearing — before the #163 fix the re-sync re-appended each step's approvals at the
|
|
93
128
|
# tail, so this loop rotated approvals.json and committed the reorder on every pass, forever
|
|
94
|
-
# (issue #163).
|
|
129
|
+
# (issue #163). This job runs an exact pin resolved from the repo, so a hub still sitting on a
|
|
130
|
+
# pre-3.15.3 yadflow keeps that behaviour — upgrade it or disable this schedule.
|
|
95
131
|
# A stuck review MR (a squash merge whose commit dropped the branch name, or a failed merge
|
|
96
132
|
# push) is always RECENT, so sweep a generous recent window and PAGINATE it fully (--paginate)
|
|
97
133
|
# — this bounds cost without the old hard 50-row cap that could permanently strand older MRs.
|
|
@@ -105,7 +141,7 @@ yad-gate-sync:
|
|
|
105
141
|
while read -r IID REF; do
|
|
106
142
|
[ -n "$IID" ] || continue
|
|
107
143
|
git checkout -q -B "$CI_DEFAULT_BRANCH" "origin/$CI_DEFAULT_BRANCH"
|
|
108
|
-
npx -y -p "yadflow@${
|
|
144
|
+
npx -y -p "yadflow@${YAD_PKG}" yad gate ci --branch "$REF" --pr "$IID" --merged || rc=1
|
|
109
145
|
done < /tmp/yad-merged-mrs
|
|
110
146
|
else
|
|
111
147
|
# MERGE push to the default branch whose commit names a review branch: resolve the merged MR's
|
|
@@ -117,7 +153,7 @@ yad-gate-sync:
|
|
|
117
153
|
IID="$(glab api "projects/:id/merge_requests?source_branch=${REVIEW_BRANCH}&state=merged" 2>/dev/null | jq -r '.[0].iid // empty' || true)"
|
|
118
154
|
if [ -n "$IID" ]; then
|
|
119
155
|
# Pass --pr + IID as two distinct args (avoid a fragile, shell-dependent ${IID:+...} split).
|
|
120
|
-
npx -y -p "yadflow@${
|
|
156
|
+
npx -y -p "yadflow@${YAD_PKG}" yad gate ci --branch "$REVIEW_BRANCH" --pr "$IID" --merged || rc=1
|
|
121
157
|
else
|
|
122
158
|
# Without the IID, gate ci cannot re-read approvals — fail visibly (the scheduled sweep
|
|
123
159
|
# retries) rather than running a green no-op that silently leaves the gate unadvanced.
|