release-targets: introduce per-scope DEBIAN/UBUNTU codename substitution

[igorpecovnik]

Summary

Replace literal Debian / Ubuntu codenames in release-targets/*.manual and the hardcoded sections of scripts/generate_targets.py with two symbolic tokens — DEBIAN and UBUNTU — that get substituted with real codenames at generation time. Each of the four output files gets its own (debian, ubuntu) flag pair, so promoting any release line is a single CLI flag flip instead of a multi-place rename.

What gets templated

Symbol → was-literal:

Token	Was	Locations
DEBIAN	trixie	1 in stable + 1 in community + 3 in apps
DEBIAN	forky	1 in nightly
UBUNTU	noble	8 in stable + 5 in community
UBUNTU	resolute	4 in nightly

RELEASE: sid (apps-kali) stays literal — Kali tracks Debian unstable forever, that's not a "current Debian stable" pin.

Per-scope flags

--debian-standard  / --ubuntu-standard   (default: trixie / noble)
--debian-nightly   / --ubuntu-nightly    (default: forky  / resolute)
--debian-community / --ubuntu-community  (default: trixie / noble)
--debian-apps      / --ubuntu-apps       (default: trixie / noble)

Defaults reproduce the previous literal pins exactly — running with no flags is bit-identical to the pre-refactor output (modulo the symbolic-token round-trip).

exposed.map follows too

generate_exposed_map regex patterns previously had _trixie_ and _noble_ hardcoded — separate from the YAML-output flags. Promoting via --*-standard would then update the *.yaml files but exposed.map would keep matching old codenames, and "recommended images" on the website would silently drop off.

Now generate_exposed_map takes the four codenames (debian/ubuntu × standard/community) as keyword args; per-board it picks the right pair based on board_type (stable boards → standard flags; community boards → community flags) and bakes that pair into the regex pattern strings. A single flag flip atomically updates both the build matrix and the recommended-images filter.

Workflow

.github/workflows/generate-build-lists.yaml exposes all 8 as workflow_dispatch.inputs with matching defaults. The Run generate_targets.py step uses ${{ inputs.X || 'default' }} so push / repository_dispatch triggers (which don't carry inputs) still get the right defaults.

Promoting Ubuntu standard to resolute, for example, becomes:

• Trigger workflow manually
• Set ubuntu_standard input to resolute
• Done

No code changes, no PR, no rename.

Substitution mechanics

resolve_release_tokens() uses re.sub(r'RELEASE:\s*<TOKEN>\b', ...) — handles RELEASE: UBUNTU, RELEASE: UBUNTU, etc., refuses to touch block keys / comments that happen to contain the literal word "noble" or "trixie", and the \b anchor prevents false-matching UBUNTU_FOO-style identifiers.

Commit history

• e1e5c5d — first attempt at the wrong abstraction (manual stable/oldstable block split pinned to literal codenames). Made obsolete by the next four.
• 6590973 — substitution refactor: symbolic tokens + per-scope CLI flags + workflow inputs.
• a880d47 — descriptive YAML comments lose their codename word now that the codename is dynamic.
• e7f6df2 — generate_exposed_map threaded with the per-scope codenames so its regex patterns track the YAML output.
• ea38a33 — drop e1e5c5d's structural additions (the stable/oldstable block split is duplicate output under the substitution model).

Test plan

• python3 scripts/generate_targets.py --help lists all 8 per-scope flags with correct defaults
• resolve_release_tokens round-trip verified on UBUNTU / DEBIAN tokens, whitespace variants, word-boundary safety, and block-key safety
• generate_exposed_map smoke test confirmed: stable board uses --*-standard codenames, community board uses --*-community codenames, defaults produce the same patterns as before
• Workflow run with all defaults produces YAML byte-identical to pre-refactor (modulo the substitution)
• Workflow run with ubuntu_nightly=oracular produces nightly YAML targeting oracular while standard stays on noble

[coderabbitai]

Walkthrough

Manual release-target files were updated to replace literal Debian/Ubuntu codenames with symbolic RELEASE tokens (DEBIAN, UBUNTU) and to add DESKTOP_TIER: "mid" to several desktop targets. The generator script (scripts/generate_targets.py) was refactored to use argparse, added per-scope --debian-* and --ubuntu-* flags, a resolve_release_tokens() step to substitute tokens with provided codenames, and updated exposed.map generation to reflect per-scope codenames. The GitHub Actions workflow (.github/workflows/generate-build-lists.yaml) now exposes workflow_dispatch inputs for these codenames and passes them to the generator. README examples and comments were adjusted to document the token substitution model.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~40 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely summarizes the main change: introducing symbolic DEBIAN/UBUNTU token substitution for codenames across release targets.
Description check	✅ Passed	The description is comprehensive and directly related to the changeset, explaining the motivation, implementation details, per-scope flags, workflow integration, substitution mechanics, and test plan.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch release-targets-promote-resolute-to-stable

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@release-targets/targets-release-standard-support.manual`:
- Around line 100-102: The release manifest is missing thinkpad-x13s (BRANCH
sc8280xp) in the stable GNOME targets though it exists in the noble GNOME and
Cinnamon blocks; verify whether omission is intentional and if not, add
thinkpad-x13s with BRANCH: sc8280xp to the items list in
release-targets/targets-release-standard-support.manual so it mirrors the noble
entries, or add a comment explaining why sc8280xp is deferred (e.g., not
validated on resolute) to avoid regressions and maintain parity with oldstable
GNOME.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 7779469e-84ef-446d-9542-b99c6de1c5f0

📥 Commits

Reviewing files that changed from the base of the PR and between f767489 and e1e5c5d.

📒 Files selected for processing (1)

• release-targets/targets-release-standard-support.manual

[coderabbitai]

🧹 Nitpick comments (2)

scripts/generate_targets.py (1)

43-65: resolve_release_tokens is correct; one fragility worth keeping in mind.

The regex RELEASE:\s*DEBIAN\b is unanchored and applied to the assembled YAML text, so it would also match RELEASE: DEBIAN if it ever showed up inside a YAML comment or a quoted string value. There are no such occurrences in the current generated/manual content (the PR explicitly removed bare codename words from comments), so this is safe today — just be aware that a future "describe a target with RELEASE: DEBIAN in a comment" could silently get rewritten. If you ever want to harden this, anchoring on indentation (^\s+RELEASE:\s*DEBIAN\b with re.MULTILINE) would restrict to map keys.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/generate_targets.py` around lines 43 - 65, The current
resolve_release_tokens uses unanchored regexes that can match RELEASE:
DEBIAN/UBUNTU inside comments or quoted strings; to harden it, anchor the
patterns to line starts and use re.MULTILINE (e.g., change the two re.sub calls
in resolve_release_tokens to match
r"^\s*RELEASE:\s*"+re.escape(RELEASE_TOKEN_DEBIAN)+r"\b" and
r"^\s*RELEASE:\s*"+re.escape(RELEASE_TOKEN_UBUNTU)+r"\b" and pass
flags=re.MULTILINE or compile with re.MULTILINE) so only YAML map keys are
replaced.

.github/workflows/generate-build-lists.yaml (1)

94-110: Pass inputs.* via env: rather than direct expression interpolation.

The current "${{ inputs.debian_standard || 'trixie' }}" form expands inside the shell script before bash quoting, so any "/`/$ in a dispatched value can break out of the quoted argument and inject shell. Dispatch is gated by team membership so the practical risk is low, but this is the GitHub-recommended pattern for any user-controlled inputs.* reaching run:.

♻️ Suggested refactor

       - name: Run generate_targets.py
         # `inputs.*` is only populated on workflow_dispatch; push /
         # repository_dispatch fire with empty inputs, so each `||`
         # falls back to the same default the script's argparse uses.
         # Net effect: codename promotion is a workflow_dispatch knob;
         # automatic re-runs use the script's pinned defaults.
+        env:
+          DEBIAN_STANDARD:  ${{ inputs.debian_standard  || 'trixie'   }}
+          UBUNTU_STANDARD:  ${{ inputs.ubuntu_standard  || 'noble'    }}
+          DEBIAN_NIGHTLY:   ${{ inputs.debian_nightly   || 'forky'    }}
+          UBUNTU_NIGHTLY:   ${{ inputs.ubuntu_nightly   || 'resolute' }}
+          DEBIAN_COMMUNITY: ${{ inputs.debian_community || 'trixie'   }}
+          UBUNTU_COMMUNITY: ${{ inputs.ubuntu_community || 'noble'    }}
+          DEBIAN_APPS:      ${{ inputs.debian_apps      || 'trixie'   }}
+          UBUNTU_APPS:      ${{ inputs.ubuntu_apps      || 'noble'    }}
         run: |
           python3 scripts/generate_targets.py image-info.json release-targets \
-            --debian-standard  "${{ inputs.debian_standard  || 'trixie'   }}" \
-            --ubuntu-standard  "${{ inputs.ubuntu_standard  || 'noble'    }}" \
-            --debian-nightly   "${{ inputs.debian_nightly   || 'forky'    }}" \
-            --ubuntu-nightly   "${{ inputs.ubuntu_nightly   || 'resolute' }}" \
-            --debian-community "${{ inputs.debian_community || 'trixie'   }}" \
-            --ubuntu-community "${{ inputs.ubuntu_community || 'noble'    }}" \
-            --debian-apps      "${{ inputs.debian_apps      || 'trixie'   }}" \
-            --ubuntu-apps      "${{ inputs.ubuntu_apps      || 'noble'    }}" \
+            --debian-standard  "$DEBIAN_STANDARD"  \
+            --ubuntu-standard  "$UBUNTU_STANDARD"  \
+            --debian-nightly   "$DEBIAN_NIGHTLY"   \
+            --ubuntu-nightly   "$UBUNTU_NIGHTLY"   \
+            --debian-community "$DEBIAN_COMMUNITY" \
+            --ubuntu-community "$UBUNTU_COMMUNITY" \
+            --debian-apps      "$DEBIAN_APPS"      \
+            --ubuntu-apps      "$UBUNTU_APPS"      \
             2>&1 | tee -a generation.log

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/generate-build-lists.yaml around lines 94 - 110, The Run
generate_targets.py step is interpolating inputs directly into the run script
which risks shell injection; change to pass each inputs.* into the job
environment and reference those env vars inside the run command. Add an env:
block on the step mapping each input (e.g. DEBIAN_STANDARD from
inputs.debian_standard with the same fallback, UBUNTU_STANDARD, DEBIAN_NIGHTLY,
etc.), then in the run string replace the "${{ inputs... }}" expansions with
their corresponding "$DEBIAN_STANDARD", "$UBUNTU_STANDARD", "$DEBIAN_NIGHTLY",
"$UBUNTU_NIGHTLY", "$DEBIAN_COMMUNITY", "$UBUNTU_COMMUNITY", "$DEBIAN_APPS",
"$UBUNTU_APPS" variables (keeping proper double quotes around each) so the
values are expanded by the shell from env vars rather than by GitHub before
shell parsing.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/generate-build-lists.yaml:
- Around line 94-110: The Run generate_targets.py step is interpolating inputs
directly into the run script which risks shell injection; change to pass each
inputs.* into the job environment and reference those env vars inside the run
command. Add an env: block on the step mapping each input (e.g. DEBIAN_STANDARD
from inputs.debian_standard with the same fallback, UBUNTU_STANDARD,
DEBIAN_NIGHTLY, etc.), then in the run string replace the "${{ inputs... }}"
expansions with their corresponding "$DEBIAN_STANDARD", "$UBUNTU_STANDARD",
"$DEBIAN_NIGHTLY", "$UBUNTU_NIGHTLY", "$DEBIAN_COMMUNITY", "$UBUNTU_COMMUNITY",
"$DEBIAN_APPS", "$UBUNTU_APPS" variables (keeping proper double quotes around
each) so the values are expanded by the shell from env vars rather than by
GitHub before shell parsing.

In `@scripts/generate_targets.py`:
- Around line 43-65: The current resolve_release_tokens uses unanchored regexes
that can match RELEASE: DEBIAN/UBUNTU inside comments or quoted strings; to
harden it, anchor the patterns to line starts and use re.MULTILINE (e.g., change
the two re.sub calls in resolve_release_tokens to match
r"^\s*RELEASE:\s*"+re.escape(RELEASE_TOKEN_DEBIAN)+r"\b" and
r"^\s*RELEASE:\s*"+re.escape(RELEASE_TOKEN_UBUNTU)+r"\b" and pass
flags=re.MULTILINE or compile with re.MULTILINE) so only YAML map keys are
replaced.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1e41a98f-99e8-4247-a38d-509a2748195e

📥 Commits

Reviewing files that changed from the base of the PR and between e1e5c5d and a880d47.

📒 Files selected for processing (3)

• .github/workflows/generate-build-lists.yaml
• release-targets/targets-release-standard-support.manual
• scripts/generate_targets.py

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

release-targets/targets-release-nightly.manual (1)

38-77: ⚠️ Potential issue | 🟡 Minor

Default-run output for the legacy *-trixie / *-noble blocks now changes (intentional collapse — please confirm).

Pre-PR, minimal-cli-stable-debian-cloud-trixie emitted RELEASE: trixie and minimal-cli-stable-ubuntu-cloud-noble emitted RELEASE: noble. With the new substitution model and the nightly defaults (--debian-nightly=forky, --ubuntu-nightly=resolute), both legacy blocks now resolve to the same codename as minimal-cli-unstable-debian-cloud / minimal-cli-stable-ubuntu-cloud, making them byte-for-byte duplicate target stanzas (same vars, same items). Two implications worth confirming:

1. The "unflagged run is byte-identical to previous output" property in the PR description does not hold for these two stanzas — their RELEASE: flips from trixie/noble to forky/resolute at defaults. If the byte-identical check still passes, it's likely because these blocks were already changed (or compared post-substitution); worth double-checking what the reference output actually contains.
2. Two identical stanzas under different YAML keys means CI will build the same image twice per nightly run. The comments correctly flag this; just want to make sure that's an acceptable cost until the planned follow-up drops them or introduces a DEBIAN_TESTING/DEBIAN_STABLE token split.

The comments on Lines 38–42 and 59–62 already document this clearly, so this is a heads-up rather than a blocker.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@release-targets/targets-release-nightly.manual` around lines 38 - 77, The
legacy targets minimal-cli-stable-debian-cloud-trixie and
minimal-cli-stable-ubuntu-cloud-noble now resolve to the same RELEASE values as
their unstable counterparts, causing byte-identical duplicate builds; update
these stanzas to restore explicit codenames or deduplicate them: either set
explicit vars RELEASE: trixie and RELEASE: noble in the
minimal-cli-stable-debian-cloud-trixie and minimal-cli-stable-ubuntu-cloud-noble
blocks respectively, or remove one of each duplicate block (or introduce
distinct tokens like DEBIAN_STABLE/DEBIAN_TESTING) so CI does not build the same
image twice under different keys and the unflagged default output remains
byte-identical to previous runs.

🧹 Nitpick comments (1)

scripts/generate_targets.py (1)

43-65: Substitution is not actually comment-safe — anchor the regex to the line start.

The PR description claims "block-key/comment safety", but the current pattern r"RELEASE:\s*DEBIAN\b" has no anchor and will rewrite the token wherever it appears, including inside YAML comments. Concrete examples in this PR:

• release-targets/targets-release-nightly.manual Lines 38–42 and 59–62 contain comments like # both blocks resolve to RELEASE: DEBIAN under the substitution model — after resolve_release_tokens() runs, those comments become RELEASE: forky (or whatever --debian-nightly is), so the meta-documentation about the substitution model itself gets rewritten and loses its explanatory value.
• Per the AI summary, similar wording exists in release-targets/README.md.

It's not a correctness bug for YAML loaders (comments are still comments), but it directly contradicts the stated guarantee and silently mutates documentation. A line-anchored variant fixes both:

♻️ Anchor to start-of-line so only real YAML keys are substituted

     yaml_text = re.sub(
-        r"RELEASE:\s*" + re.escape(RELEASE_TOKEN_DEBIAN) + r"\b",
+        r"^(\s*)RELEASE:(\s*)" + re.escape(RELEASE_TOKEN_DEBIAN) + r"\b",
         f"RELEASE: {debian}",
         yaml_text,
+        flags=re.MULTILINE,
     )
     yaml_text = re.sub(
-        r"RELEASE:\s*" + re.escape(RELEASE_TOKEN_UBUNTU) + r"\b",
+        r"^(\s*)RELEASE:(\s*)" + re.escape(RELEASE_TOKEN_UBUNTU) + r"\b",
         f"RELEASE: {ubuntu}",
         yaml_text,
+        flags=re.MULTILINE,
     )

(If you want to preserve the original indent/spacing in the substitution, switch the replacement to r"\1RELEASE:\2{debian}" style. The simpler anchored form above is enough to keep comments untouched and still matches every real YAML stanza in generate_*_yaml() and the manual files, since they all use RELEASE: TOKEN at the start of the line.)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/generate_targets.py` around lines 43 - 65, The substitution in
resolve_release_tokens currently matches RELEASE tokens anywhere (including in
comments); change the regexes to anchor to the start of a line (allowing
optional leading indentation) and run with the re.MULTILINE flag so only actual
YAML key lines are replaced; update the two calls that match
RELEASE_TOKEN_DEBIAN and RELEASE_TOKEN_UBUNTU in resolve_release_tokens to use a
start-of-line pattern (optionally capturing the leading whitespace so you can
preserve indentation in the replacement) and pass re.MULTILINE to re.sub.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@release-targets/targets-release-nightly.manual`:
- Around line 38-77: The legacy targets minimal-cli-stable-debian-cloud-trixie
and minimal-cli-stable-ubuntu-cloud-noble now resolve to the same RELEASE values
as their unstable counterparts, causing byte-identical duplicate builds; update
these stanzas to restore explicit codenames or deduplicate them: either set
explicit vars RELEASE: trixie and RELEASE: noble in the
minimal-cli-stable-debian-cloud-trixie and minimal-cli-stable-ubuntu-cloud-noble
blocks respectively, or remove one of each duplicate block (or introduce
distinct tokens like DEBIAN_STABLE/DEBIAN_TESTING) so CI does not build the same
image twice under different keys and the unflagged default output remains
byte-identical to previous runs.

---

Nitpick comments:
In `@scripts/generate_targets.py`:
- Around line 43-65: The substitution in resolve_release_tokens currently
matches RELEASE tokens anywhere (including in comments); change the regexes to
anchor to the start of a line (allowing optional leading indentation) and run
with the re.MULTILINE flag so only actual YAML key lines are replaced; update
the two calls that match RELEASE_TOKEN_DEBIAN and RELEASE_TOKEN_UBUNTU in
resolve_release_tokens to use a start-of-line pattern (optionally capturing the
leading whitespace so you can preserve indentation in the replacement) and pass
re.MULTILINE to re.sub.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: e74419e7-3753-4e17-8ecd-2c54ca457557

📥 Commits

Reviewing files that changed from the base of the PR and between a880d47 and e165068.

📒 Files selected for processing (5)

• release-targets/README.md
• release-targets/targets-release-community-maintained.manual
• release-targets/targets-release-nightly.manual
• release-targets/targets-release-standard-support.manual
• scripts/generate_targets.py

✅ Files skipped from review due to trivial changes (2)

• release-targets/README.md
• release-targets/targets-release-community-maintained.manual

🚧 Files skipped from review as they are similar to previous changes (1)

• release-targets/targets-release-standard-support.manual

[coderabbitai]

🧹 Nitpick comments (5)

scripts/generate_targets.py (4)

29-30: Ruff S105 here is a false positive — safe to ignore or silence.

Ruff is flagging RELEASE_TOKEN_DEBIAN/RELEASE_TOKEN_UBUNTU as possible hardcoded passwords because of the _TOKEN_ substring in the name. These are obviously placeholder strings, not credentials. If the noise is unwanted, a # noqa: S105 on each line (or a per-file ignore in your ruff config) clears it without renaming.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/generate_targets.py` around lines 29 - 30, Ruff is flagging
RELEASE_TOKEN_DEBIAN and RELEASE_TOKEN_UBUNTU as S105 false positives; to
silence this, add a per-line noqa comment by appending "# noqa: S105" to the
RELEASE_TOKEN_DEBIAN and RELEASE_TOKEN_UBUNTU definitions, or alternatively add
a per-file or project-level S105 ignore in your ruff config if you prefer to
suppress this rule for the file.

---

1192-1192: Target names still hardcode codenames (forky, resolute, trixie, noble) — flag-flip promotion is incomplete.

The PR's stated goal is that "Promoting nightly to a new Debian … becomes a single flag flip, not a 30-place codename rename." But target keys like nightly-forky-all, nightly-resolute-gnome, nightly-resolute-xfce, nightly-resolute-riscv64-xfce, nightly-resolute-minimal, community-trixie-all, community-noble-gnome, community-noble-kde-neon, community-noble-xfce, community-noble-riscv64-xfce, and community-noble-minimal are emitted as static strings and are not run through resolve_release_tokens (which only matches RELEASE: <token>). After flipping --debian-nightly from forky to (say) trixie, the YAML will contain nightly-forky-all: with RELEASE: trixie — internally inconsistent, and any downstream tooling/dashboards keyed on these target names will silently break or need a parallel rename.

Two reasonable options:

• Make target names codename-agnostic (e.g., nightly-debian-all, nightly-ubuntu-gnome, community-debian-all, community-ubuntu-gnome, …) — this also matches what the manual/standard side already does (minimal-stable-debian, desktop-stable-ubuntu-xfce).
• Or substitute the codename into the name at generate time using the same per-scope codenames already threaded through main().

Option 1 is the cheaper and more consistent fix and aligns nightly/community naming with the rest of the file.

Also applies to: 1217-1217, 1239-1239, 1261-1261, 1283-1283, 1458-1458, 1503-1503, 1529-1529, 1555-1555, 1582-1582, 1609-1609

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/generate_targets.py` at line 1192, The generated target keys are
hardcoded with codenames (e.g., nightly-forky-all, community-noble-gnome)
causing mismatch after a RELEASE token flip; update the generator in
scripts/generate_targets.py (where targets are emitted in the same scope as
resolve_release_tokens and main()) to produce codename-agnostic keys (e.g.,
nightly-debian-all, nightly-ubuntu-gnome, community-debian-all) instead of
embedding the codename, or alternatively substitute the codename at generation
time using the per-scope codename passed through main() and the same token
resolution machinery; change the static string keys referenced around the
existing occurrences (nightly-forky-all, nightly-resolute-*, community-trixie-*,
community-noble-*) to the chosen codename-agnostic names (or build them from the
resolved codename) so emitted YAML keys remain consistent with RELEASE values
and downstream tooling.

---

1128-1138: Docstrings/comments still pin specific codenames (Forky, Resolute, Noble, bookworm).

generate_nightly_yaml docstring (1130–1138) and generate_community_yaml docstring (1308–1313) describe the output in terms of Forky/Resolute/Noble, and the inline notes at lines 1297 and 1628 refer to resolute/noble/bookworm. After this PR, those codenames are runtime-configurable via --debian-{nightly,community} / --ubuntu-{nightly,community}, so the docs are now stale and misleading. Also, bookworm is no longer used anywhere in the generator, so the loongarch notes are doubly wrong.

Suggest making these generic (e.g., "Debian minimal CLI", "Ubuntu desktop", "loongarch boards only get the Debian minimal image").

Also applies to: 1297-1297, 1307-1314, 1628-1628

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/generate_targets.py` around lines 1128 - 1138, Update the stale
hard-coded release codenames in the generate_nightly_yaml and
generate_community_yaml docstrings and any inline comments that reference
"Forky", "Resolute", "Noble", or "bookworm" to use generic descriptions (e.g.,
"Debian minimal CLI", "Ubuntu desktop", "Debian minimal for loongarch") because
Debian/Ubuntu codenames are now runtime-configurable via the
--debian-{nightly,community} and --ubuntu-{nightly,community} flags;
specifically, edit the docstrings in generate_nightly_yaml and
generate_community_yaml and the nearby inline notes that currently mention
resolute/noble/bookworm to remove codename assertions and to state that
codenames are configurable at runtime and that loongarch boards receive the
Debian minimal CLI image.

---

54-64: Regex isn't anchored before RELEASE:, so it can match a suffix of an unrelated key.

The pattern RELEASE:\s*DEBIAN\b has a \b after the token but no anchor before RELEASE. A YAML key like KERNEL_RELEASE: DEBIAN (or any future *_RELEASE: DEBIAN) would still be substituted because _RELEASE: ends with the same characters. The PR description claims "word-boundary and block-key/comment safety", which would require (?<!\w)RELEASE: (or ^\s*RELEASE: per-line) to actually hold.

No such key exists today, so no current breakage — but worth tightening defensively since the cost is one lookbehind.

♻️ Suggested tightening

     yaml_text = re.sub(
-        r"RELEASE:\s*" + re.escape(RELEASE_TOKEN_DEBIAN) + r"\b",
+        r"(?<!\w)RELEASE:\s*" + re.escape(RELEASE_TOKEN_DEBIAN) + r"\b",
         f"RELEASE: {debian}",
         yaml_text,
     )
     yaml_text = re.sub(
-        r"RELEASE:\s*" + re.escape(RELEASE_TOKEN_UBUNTU) + r"\b",
+        r"(?<!\w)RELEASE:\s*" + re.escape(RELEASE_TOKEN_UBUNTU) + r"\b",
         f"RELEASE: {ubuntu}",
         yaml_text,
     )

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/generate_targets.py` around lines 54 - 64, The current re.sub calls
replace any occurrence of "RELEASE: TOKEN" even when it's part of a longer key
(e.g., "KERNEL_RELEASE: DEBIAN"); tighten the regex in the two replacements so
it only matches a block key by anchoring before RELEASE, e.g. use a multiline
start anchor or negative-word lookbehind (patterns like (?m)^\s*RELEASE:\s* +
re.escape(RELEASE_TOKEN_DEBIAN) + \b and similarly for RELEASE_TOKEN_UBUNTU) and
apply them to the same yaml_text variables so only top-level RELEASE keys are
substituted.

.github/workflows/generate-build-lists.yaml (1)

10-42: Defaults are duplicated three times — workflow input defaults, inline || fallbacks, and SCOPE_DEFAULTS in the script.

Each codename default now lives in three places:

1. workflow_dispatch.inputs.*.default (lines 14, 18, 22, 26, 30, 34, 38, 42)
2. ${{ inputs.* || '<literal>' }} fallback in the run step (lines 102–109)
3. SCOPE_DEFAULTS in scripts/generate_targets.py

If any of these drift (e.g., a future codename promotion updates only the workflow input default but forgets the inline fallback), push / repository_dispatch runs and workflow_dispatch runs will silently produce different outputs. Two cheaper alternatives:

• Drop the || '<literal>' fallbacks and just pass "${{ inputs.* }}" — argparse in the script will fall back to SCOPE_DEFAULTS when the value is empty… but only if you also handle empty strings in argparse (currently default=... only kicks in when the flag is absent, not when it's passed as ""). So this needs a small tweak in the script (e.g., type=lambda v: v or defaults["debian"]).
• Or, simpler and zero script change: drop the inputs.*.default block and rely on the || fallback as the single source of truth for non-script defaults. The dispatch UI will show empty fields, which is mildly less friendly but eliminates one of the three copies.

Not a blocker for this PR, but worth a note before the next codename promotion lands.

Also applies to: 100-110

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/generate-build-lists.yaml around lines 10 - 42, Remove the
duplicated inline "|| '<literal>'" fallbacks in the workflow run step and pass
the raw inputs (e.g., use "${{ inputs.debian_standard }}" etc.), and update the
script's argparse logic in scripts/generate_targets.py to treat empty strings as
missing by using a small type/coerce function (e.g., change the
argparse.add_argument for each scope to use type=lambda v: v or
SCOPE_DEFAULTS["debian"/"ubuntu"/...]) or equivalent post-processing so
SCOPE_DEFAULTS is the single source of truth; reference the workflow input names
(debian_standard, ubuntu_standard, debian_nightly, ubuntu_nightly,
debian_community, ubuntu_community, debian_apps, ubuntu_apps) and the
SCOPE_DEFAULTS mapping when making the change.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/generate-build-lists.yaml:
- Around line 10-42: Remove the duplicated inline "|| '<literal>'" fallbacks in
the workflow run step and pass the raw inputs (e.g., use "${{
inputs.debian_standard }}" etc.), and update the script's argparse logic in
scripts/generate_targets.py to treat empty strings as missing by using a small
type/coerce function (e.g., change the argparse.add_argument for each scope to
use type=lambda v: v or SCOPE_DEFAULTS["debian"/"ubuntu"/...]) or equivalent
post-processing so SCOPE_DEFAULTS is the single source of truth; reference the
workflow input names (debian_standard, ubuntu_standard, debian_nightly,
ubuntu_nightly, debian_community, ubuntu_community, debian_apps, ubuntu_apps)
and the SCOPE_DEFAULTS mapping when making the change.

In `@scripts/generate_targets.py`:
- Around line 29-30: Ruff is flagging RELEASE_TOKEN_DEBIAN and
RELEASE_TOKEN_UBUNTU as S105 false positives; to silence this, add a per-line
noqa comment by appending "# noqa: S105" to the RELEASE_TOKEN_DEBIAN and
RELEASE_TOKEN_UBUNTU definitions, or alternatively add a per-file or
project-level S105 ignore in your ruff config if you prefer to suppress this
rule for the file.
- Line 1192: The generated target keys are hardcoded with codenames (e.g.,
nightly-forky-all, community-noble-gnome) causing mismatch after a RELEASE token
flip; update the generator in scripts/generate_targets.py (where targets are
emitted in the same scope as resolve_release_tokens and main()) to produce
codename-agnostic keys (e.g., nightly-debian-all, nightly-ubuntu-gnome,
community-debian-all) instead of embedding the codename, or alternatively
substitute the codename at generation time using the per-scope codename passed
through main() and the same token resolution machinery; change the static string
keys referenced around the existing occurrences (nightly-forky-all,
nightly-resolute-*, community-trixie-*, community-noble-*) to the chosen
codename-agnostic names (or build them from the resolved codename) so emitted
YAML keys remain consistent with RELEASE values and downstream tooling.
- Around line 1128-1138: Update the stale hard-coded release codenames in the
generate_nightly_yaml and generate_community_yaml docstrings and any inline
comments that reference "Forky", "Resolute", "Noble", or "bookworm" to use
generic descriptions (e.g., "Debian minimal CLI", "Ubuntu desktop", "Debian
minimal for loongarch") because Debian/Ubuntu codenames are now
runtime-configurable via the --debian-{nightly,community} and
--ubuntu-{nightly,community} flags; specifically, edit the docstrings in
generate_nightly_yaml and generate_community_yaml and the nearby inline notes
that currently mention resolute/noble/bookworm to remove codename assertions and
to state that codenames are configurable at runtime and that loongarch boards
receive the Debian minimal CLI image.
- Around line 54-64: The current re.sub calls replace any occurrence of
"RELEASE: TOKEN" even when it's part of a longer key (e.g., "KERNEL_RELEASE:
DEBIAN"); tighten the regex in the two replacements so it only matches a block
key by anchoring before RELEASE, e.g. use a multiline start anchor or
negative-word lookbehind (patterns like (?m)^\s*RELEASE:\s* +
re.escape(RELEASE_TOKEN_DEBIAN) + \b and similarly for RELEASE_TOKEN_UBUNTU) and
apply them to the same yaml_text variables so only top-level RELEASE keys are
substituted.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c2a2585f-238d-449f-b333-e75eb8c32157

📥 Commits

Reviewing files that changed from the base of the PR and between e165068 and 6507ea0.

📒 Files selected for processing (5)

• .github/workflows/generate-build-lists.yaml
• release-targets/README.md
• release-targets/targets-release-community-maintained.manual
• release-targets/targets-release-standard-support.manual
• scripts/generate_targets.py

🚧 Files skipped from review as they are similar to previous changes (2)

• release-targets/targets-release-standard-support.manual
• release-targets/README.md