Skip to content

RUNNER_GROUP is declared but never consumed; RUNNER_LABELS is consumed but undeclared #7

Closed
#8
Closed
RUNNER_GROUP is declared but never consumed; RUNNER_LABELS is consumed but undeclared#7
#8
Assignees
aitrawog

Description

@aitrawog
aitrawog
opened on Oct 5, 2026

Summary

Two registration knobs are misdeclared in charly.yml, in opposite directions. Both were found by reading the candy's own registration hook against its env: block while fixing the missing hostname/tool surface (see the linked PR).

1. RUNNER_GROUP is declared but never consumed

charly.yml:117 declares RUNNER_GROUP: "Default" in the candy's env:, and charly.yml:527 documents it in the skill's environment table. Neither is true: the registration hook is the only path that writes a runner's group, and it passes --name, --labels, --url, --token, --work — and no --runnergroup.

$ grep -n 'runnergroup' charly.yml
NONE

The runner lands in the default group because that is GitHub's default, not because this env var did anything. The operational consequence is worse than a dead knob: a deploy that sets RUNNER_GROUP=some-group believes it moved the runner (for routing, or for the group's access rules), and it did not. Silent divergence between declared intent and live state.

2. RUNNER_LABELS is consumed but undeclared

charly.yml:157 does : "${RUNNER_LABELS:=opencharly}" and passes --labels "${RUNNER_LABELS}". It is a real, working knob — and it is in neither env:, nor the skill's environment table, nor the README. It is discoverable only by reading the hook.

This one is load-bearing for the whole org: every runner in the live fleet registers as

$ gh api "/orgs/opencharly/actions/runners?per_page=100" --jq '.runners[] | "\(.name)\t\([.labels[].name]|join(","))"'
charly-githubrunner-no-1   self-hosted,Linux,X64,opencharly
... (8/8 identical)

so runs-on: [self-hosted, opencharly] is the org's routing contract, and the label that carries it is undocumented.

Impact

  • A runner group set through charly config -e RUNNER_GROUP=… is silently ignored.
  • The org's routing label (opencharly) is not part of the candy's declared interface, so nothing pins it and no check asserts it.

Fix

  • Pass the declared group through: add --runnergroup "${RUNNER_GROUP}" to the post_enable registration in charly.yml, so the declaration becomes true. (Alternative, if the group is meant to be GitHub's default always: delete the env: entry and the skill-table row — R5. Wiring it is preferred, since it is the obvious intent and an org runner group is exactly the kind of thing a deploy needs to choose.)
  • Declare RUNNER_LABELS: "opencharly" in env:, add it to the skill's environment table and the README's property table, and document runs-on: [self-hosted, opencharly] as the org's routing entry point.

Proof plan (and what it cannot be)

The registration hook is token-guarded — with an empty RUNNER_TOKEN it is a clean no-op, which is what lets a check bed deploy the image without registering. A bed therefore cannot execute this path, and a real registration cannot be run in a bed either (it would register a live runner into the org as a side effect).

Honest proof available:

  • a plan: check asserting config.sh --help lists --runnergroup — the real binary, the real flag, so the hook's new argument cannot be one the runner does not understand;
  • the hook text itself, which is the only source of registration behaviour.

That is at most analysed on a live system, not fully tested and validated — stated up front so the tier is not inflated at review time.

Deliberately not folded into the in-flight PR

The linked PR's strength is that its disposable: true bed proves the change. A token-gated hook change is not bed-observable, so bundling it would put an unprovable-by-bed change inside a bed-proven PR and weaken both. It lands separately, with the proof above.

Agent: readme-truth · session 2a317871-ba03-4713-89ba-8edbd4059c27
Assisted-by: Claude Code 2.1.288 deepseek-v4.1-flash:cloud (analysed on a live system)

Activity

  1. aitrawog commented on Oct 5, 2026

    @aitrawog
    aitrawog
    on Oct 5, 2026
    ContributorAuthor

    CLAIM — I am taking this issue.

    I found it while fixing the runner image's missing hostname(1) and near-empty tool surface (PR to follow against this repo, branch feat/hostname-inetutils), and I have the measured evidence for both halves already (the hook text, the fleet's live labels via the org runners API).

    I will land it as its own PR after that one, because the registration hook is token-guarded and therefore not bed-observable — folding it into a bed-proven PR would weaken the bed proof rather than extend it. Proof plan and the honest attribution ceiling are in the issue body.

    No branch exists yet; this is a claim so no other session starts work here.

    Agent: readme-truth · session 2a317871-ba03-4713-89ba-8edbd4059c27
    Assisted-by: Claude Code 2.1.288 deepseek-v4.1-flash:cloud (documentation reviewed)

  2. aitrawog
    self-assigned this
    on Oct 5, 2026

  3. aitrawog commented on Oct 6, 2026

    @aitrawog
    aitrawog
    on Oct 6, 2026
    ContributorAuthor

    STATUS — the fix landed inside PR #8, not as the separate PR this issue planned.

    I am the same session that filed this issue and wrote the CLAIM below, so I owe an account of
    the change of plan rather than a quiet edit of it.

    What #7 predicted. The proof plan above says a registration-hook change is not
    bed-observable, so the fix "lands separately" and its ceiling is analysed on a live system.
    That reasoning holds for the first remedy the issue proposes — adding
    --runnergroup "${RUNNER_GROUP}" to the post_enable hook. A token-guarded hook cannot be
    executed by a disposable bed.

    What the fix actually turned out to be. I took the second remedy the issue lists (delete
    the declaration, R5), plus the matching declaration for RUNNER_LABELS. Neither touches the
    hook: the hook is byte-identical, and its : "${RUNNER_LABELS:=opencharly}" fallback still
    yields opencharly, so the registered label set does not change. What changed is the candy's
    declared interface — and that is bed-observable, because the declarations are emitted into
    the image's own ai.opencharly.* labels, which charly box labels reads back off the built
    artefact. Measured on the image the bed built from the PR head:

    $ charly box labels ghcr.io/opencharly/githubrunner:check-githubrunner-pod-2026.278.2353 | grep -E 'env_accept|env_candy'
ai.opencharly.env_accept=[{"name":"RUNNER_LABELS","description":"Labels the runner registers under (`config.sh --labels`), i.e. what a job's `runs-on:` selects on. The post_enable hook falls back to `opencharly` when unset. Pass via: charly config githubrunner -e RUNNER_LABELS=\u003clabel\u003e[,\u003clabel\u003e]"},{"name":"RUNNER_ORG","description":"GitHub org/user to register the runner with (e.g. opencharly). Pass via: charly config githubrunner -e RUNNER_ORG=\u003corg\u003e"}]
ai.opencharly.env_candy={"BUILDAH_ISOLATION":"chroot","CHARLY_BUILD_ENGINE":"podman","CHARLY_RUN_ENGINE":"podman","DBUS_SESSION_BUS_ADDRESS":"unix:path=/tmp/dbus-session","EXAMPLEDEPLOY_STEP_ENV":"present","LANG":"C.UTF-8","RUNNER_WORK_DIR":"${HOME}/actions-runner/_work","TZ":"UTC","XDG_RUNTIME_DIR":"/tmp/xdg-runtime","_CONTAINERS_USERNS_CONFIGURED":""}

    Before the change, on this branch's earlier head, the same read-back showed
    env_accept carrying only RUNNER_ORG and env_candy still carrying "RUNNER_GROUP":"Default".
    So both halves of this issue are visible in a built artefact and are proved there — the
    attribution tier is fully tested and validated, not analysed on a live system.

    Why not a separate PR (R2). The reason is not convenience. PR #8 edits the very
    skill-entity table that carried the dead RUNNER_GROUP row — the row it deletes sits inside
    the block that PR adds its LANG/TZ rows to. Landing that PR with the dead row still in the
    table it is extending, and then filing a second PR to remove it, is precisely the
    parking-of-a-known-defect that R2 forbids.

    Corrections I owe this issue's own text. Two details in the body above are wrong and are
    corrected by measurement, not by preference:

    Next. PR #8 carries the fix, the R8 label read-back, and the disposable: true bed that
    builds the branch's bytes (14/14 steps PASS, BED_EXIT=0, run 2026.278.2353). This issue
    closes by hand when #8 merges — Closes #7 in a PR body does not close an issue on its own.

    Agent: readme-truth · session 2a317871-ba03-4713-89ba-8edbd4059c27
    Assisted-by: Claude Code ollama-cloud/deepseek-v4.1-flash (fully tested and validated)

  4. aitrawog commented on Oct 6, 2026

    @aitrawog
    aitrawog
    on Oct 6, 2026
    ContributorAuthor

    STATUS — correction to the line numbers in my comment directly above.

    My own comment above says the two sites are "charly.yml:121 … and charly.yml:533". That is
    wrong in both places, and it is wrong in the same way the issue body is: both were read off a
    moving working tree instead of a fixed revision. Corrected here rather than left standing (R1).

    Measured against the merge base origin/main = 197aed5, the dead knob is at three sites,
    not two — the issue body and my comment both missed the README:

    $ git grep -n RUNNER_GROUP origin/main -- . ; echo "origin_main_grep_exit=$?"
origin/main:README.md:22:| Env | `RUNNER_WORK_DIR=~/actions-runner/_work`, `RUNNER_GROUP=Default` |
origin/main:charly.yml:53:            RUNNER_GROUP: "Default"
origin/main:charly.yml:258:            | `RUNNER_GROUP` | `Default` |
origin_main_grep_exit=0

    So the three sites are charly.yml:53 (the env: declaration), charly.yml:258 (the skill
    entity's environment table) and README.md:22 (the README's property table). The issue body's
    charly.yml:117 and charly.yml:527 match none of them.

    PR #8 deletes all three in one commit, and the sweep is complete rather than partial:

    $ git grep -n RUNNER_GROUP -- . ; echo "grep_exit=$?"
grep_exit=1

    Everything else in the comment above stands: the fold-in reasoning, the R8 label read-back
    that makes this bed-observable, and the tier. The numbers quoted there are the only part that
    was wrong, and they are corrected here.

    Agent: readme-truth · session 2a317871-ba03-4713-89ba-8edbd4059c27
    Assisted-by: Claude Code ollama-cloud/deepseek-v4.1-flash (fully tested and validated)

  5. aitrawog commented on Oct 6, 2026

    @aitrawog
    aitrawog
    on Oct 6, 2026
    ContributorAuthor

    RESOLVED — both halves of this issue shipped in opencharly/pod-github-runner#8, which merged.

    The fix did not go out as the separate PR this issue predicted. It went in with PR #8, because
    the fix is bed-observable through the built image's own labels — so a separate PR would have been
    parking a defect the candy PR was standing on (R2). The full rationale and the label read-back are
    in the STATUS comment above.

    What shipped. Merge commit 297c9eac7f514e2978d41d2aabdb4e6e7b9bb3ce, squash-merged to main
    at 2026-10-06T00:28:03Z, tag-on-merge v2026.279.0028, changelog CHANGELOG/2026.279.0028.md.

    Half 1 — the dead knob is gone. RUNNER_GROUP was declared in env: and read by nothing:
    the registration hook passes --name/--labels/--work and never --runnergroup. It is deleted
    at all three sites that named it in one commit (env, skill entity table, README) — the R5 cutover,
    no transitional path:

    $ git grep -n RUNNER_GROUP -- . ; echo "grep_exit=$?"
grep_exit=1

    Half 2 — the live knob is declared. RUNNER_LABELS is consumed by the hook
    (--labels "${RUNNER_LABELS}") and was declared nowhere, so the one value every self-hosted job
    selects on had no supported way of being set. It is now an env_accept entry beside RUNNER_ORG:

    $ git grep -n RUNNER_LABELS -- .
README.md:33:| env_accept | `RUNNER_ORG` — the org/user to register with; `RUNNER_LABELS` — the labels a job's `runs-on:` selects on (defaults to `opencharly`) |
charly.yml:139:            - name: RUNNER_LABELS
charly.yml:140:              description: "Labels the runner registers under (`config.sh --labels`), i.e. what a job's `runs-on:` selects on. The post_enable hook falls back to `opencharly` when unset. Pass via: charly config githubrunner -e RUNNER_LABELS=<label>[,<label>]"
charly.yml:167:                : "${RUNNER_LABELS:=opencharly}"
charly.yml:172:                  --labels "${RUNNER_LABELS}" \
charly.yml:538:            | `RUNNER_LABELS` | `env_accept` — the labels a job's `runs-on:` selects on; the hook defaults to `opencharly` |

    Behaviour is unchanged: the hook's : "${RUNNER_LABELS:=opencharly}" fallback still yields
    opencharly when nothing sets it, so the registered label set is byte-identical to before. The
    hook itself is untouched.

    Proved on the built artefact, before and after. charly box labels on the branch's first head
    carried "RUNNER_GROUP":"Default" in env_candy and only RUNNER_ORG in env_accept; on the
    final bed run it is gone from env_candy and RUNNER_LABELS is present in env_accept with the
    description from the diff.

    $ charly box labels ghcr.io/opencharly/githubrunner:check-githubrunner-pod-2026.279.0009 | grep -E 'env_accept|env_candy'
ai.opencharly.env_accept=[{"name":"RUNNER_LABELS","description":"Labels the runner registers under (`config.sh --labels`), i.e. what a job's `runs-on:` selects on. The post_enable hook falls back to `opencharly` when unset. Pass via: charly config githubrunner -e RUNNER_LABELS=\u003clabel\u003e[,\u003clabel\u003e]"},{"name":"RUNNER_ORG","description":"GitHub org/user to register the runner with (e.g. opencharly). Pass via: charly config githubrunner -e RUNNER_ORG=\u003corg\u003e"}]
ai.opencharly.env_candy={"BUILDAH_ISOLATION":"chroot","CHARLY_BUILD_ENGINE":"podman","CHARLY_RUN_ENGINE":"podman","DBUS_SESSION_BUS_ADDRESS":"unix:path=/tmp/dbus-session","EXAMPLEDEPLOY_STEP_ENV":"present","LANG":"C.UTF-8","RUNNER_WORK_DIR":"${HOME}/actions-runner/_work","TZ":"UTC","XDG_RUNTIME_DIR":"/tmp/xdg-runtime","_CONTAINERS_USERNS_CONFIGURED":""}

    R10 bed on the merged tree. charly check run check-githubrunner-pod on head 49822b8:
    BED_EXIT=0, all 14 steps PASS (check-live 1m21.536s, check-live-rebuild 1m19.001s,
    feature-run 1m22.506s, feature-run-rebuild 1m16.992s), 28 branch-only checks, 0 FAIL.

    Closing, since both halves are on main.

    Agent: readme-truth · session 2a317871-ba03-4713-89ba-8edbd4059c27
    Assisted-by: Claude Code ollama-cloud/deepseek-v4.1-flash (fully tested and validated)

  6. aitrawog
    closed this as completedon Oct 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions