Skip to content

Five of the disabled CI jobs go green - #322

Merged
the-homeless-god merged 6 commits into
devfrom
a/five-red-ci-jobs-go-green
Oct 4, 2026
Merged

Five of the disabled CI jobs go green#322
the-homeless-god merged 6 commits into
devfrom
a/five-red-ci-jobs-go-green

Conversation

@the-homeless-god

@the-homeless-god the-homeless-god commented Oct 4, 2026

Copy link
Copy Markdown
Member

Task 1117 measured all 25 jobs of the manually disabled .github/workflows/ci.yml
on 2 October on tree 85cc976a: 18 green, 7 red. This branch takes the five
cheapest reds. The workflow itself stays disabled — turning it on is not this
branch's decision.

What the runs say

Measured with the runner's own shape: every step in its own subshell
(bash --noprofile --norc -e -o pipefail), own RUNNER_TEMP, GITHUB_OUTPUT,
GITHUB_STEP_SUMMARY, GITHUB_ENV, GITHUB_REF=refs/heads/dev,
GITHUB_REF_TYPE=branch, GITHUB_EVENT_NAME=push, steps in order and broken off
at the first red. Local composite actions were expanded from their action.yml
rather than skipped. Two trees: 5604556ef with binary 0.7.23, then
4d76abd53 + this branch with binary 0.7.24 after the rebase (the trunk moved
16 commits, one of them a reseed).

job 2 Oct 0.7.23 0.7.24 after rebase
zadachnik / task-tracker code 2, 0.3 s code 0, 94.0 s code 0, 105.9 s
seed-verdicts code 1, 40.1 s code 0, 212.2 s code 0, 249.6 s
uncalled / checks-nobody-calls code 1, 17.1 s code 0, 19.2 s code 0, 19.1 s
neznanye-storozha / uncalled-guards code 1, 7.2 s code 0, 722.5 s code 1, 397.0 s
klyuchi / cli-keys code 1, 75.7 s code 0, 73.3 s code 0, 73.4 s

Two of the five needed nothing from here. 16729f7f9 had already fixed the
scaffolding of zadachnik and the inverted condition of step 14, and
f909a981f had stopped the key ledger calling five keys strangers. Both were
re-measured, not assumed: checking the trunk before working saved the work twice.

seed-verdicts went green by itself, and the reason is not the one I first
wrote down. It is not commit kinship: on the rebased tree the fingerprint
names a1102df50, which is not an ancestor of HEAD, and the job is green all
the same. The guard judges by the hashes of the print inputs and says so itself —
"the seed is not behind the sources". The correction is written into task 1117
next to the wrong claim.

What this branch changes

  • fix(site) — the glossary sections know follows. The row was written into
    docs/glossary.md by hand on 25 September; the section lists in
    scripts/site/emit-dictionary.fscript, from which the page is printed, were
    never told, so dictionary:check stopped the whole job at step 5 and the other
    24 steps were never seen. The page needed no rebuild — the hand-written row
    stands exactly where the printer puts it.
  • fix(docs) — six reader lines in five pages drop the internal words
    (guard → check, corpus → programs of the repository, printer → code generator), and two repl_call sites in flang/src/emit/c/flang_repl.c go
    into the exceptions of docs/jargon.json: they are names of flang functions at
    flang/self/bootstrap/corpus.flang:270 and :334, which a text ban cannot
    rename — only a reprint can. The debt of that file stays 42.
  • fix(ci) — the length-claims forgery is pinned to the promise text instead
    of to line 75 of flang/self/emit-rust.flang. The promise had moved to line 20,
    sed said nothing, and the step blamed a forgery that was never planted. This
    red was not in the 2 October table; it appeared since.
  • feat(ci) — the kernel-memo probe gets a caller: the shortcut
    script.kernel-memo:probe and a step in job storozha of binary.yml, where
    all twenty of its sisters already stand. ci.yml is no home for a caller: it is
    disabled, and a call there would call nobody. The probe is green today — code 0
    at 177.4 s, peak 0.36 GiB — so task 5310's record of it as "red and expensive"
    no longer holds.

Negative controls

Every fix has one, and each is red as it must be:

broken on purpose ended
zadachnik: one if left without its fi code 2, 0.0 s, the shell will not parse the step
zadachnik: the forgery sed made a no-op code 1, 0.0 s, "the forgery did not apply"
glossary: follows taken back out of the section code 1, the former message word for word
uncalled: both callers of kernel-memo removed code 1, the probe named
step 10: forgery pattern replaced by an absent one code 1, 0.0 s, the promise named

The four probe steps of klyuchi, seed-verdicts and steps 8 and 14 plant their
forgeries themselves and are green, which is the same proof from the other side.
The tree is clean after every run: git status --porcelain is empty.

What stays red, and why

  • neznanye-storozha is red again on the rebased trunk, for a reason that came
    with it.     Step 9 Check jargon, code 1 at 202.9 s, four troubles, all four new:
    docs/site/registry.md (10 internal words where 0 are allowed),
    registry.ru.md (9), packages.md (1), packages.ru.md (1). Those pages
    arrived with ffeca8f82 and are printed by
    scripts/site/registry-page.fscript, so editing the pages would be wiped by the
    next build — the fix belongs in the printer. Opened as task 2325. None of the
    six troubles this branch closed came back, and run step by step the job has 27 of
    its 28 check steps green (759.9 s).
  • links — named debt, continue-on-error: true, blocks neither tag nor push.
    Not measured here: outside this share.
  • stale-pages — course pages on 0.7.22, tag and button only. Not measured
    here    , same reason.
  • The eighth uncalled check is now flang/proof/probes/text-block/tokens.fscript,
    and it gets a ledger entry rather than a caller, with the reason in numbers:
    without --max-steps it gives no verdict at all (code 3 at 78.9 s), and with a
    sample it grows worse than linearly in file size — code 0 at 5.9 s on a 394-byte
    file, while ADR-0052 names 9 min 29 s for one 106 KB file and 78 min for a sample
    of ten (those two numbers come from the decision page, not from a run here). A
    caller over one tiny file would be a check that does not check.
  • Not measured: what 177.4 s of the kernel-memo probe adds to job storozha on
    a runner. That job takes 6 min 47 s and 7 min 01 s there (runs 37223001273,
    37223864296), but one thread of check --proof does not go at this machine's
    speed on two cores. Said out loud in the step's own comment.

Gates

pre-push, 21 checks, all green                                62 s
bootstrap/flang run-script tasks:check                        code 0
bootstrap/flang io scripts/guards/task-numbers-guard.fscript  code 0
bootstrap/flang check scripts/site/emit-dictionary.fscript    code 0
bootstrap/flang run-script scripts:check                      code 0
bootstrap/flang lint                                          code 0

Of the six push jobs that used to block, none blocks now. stale-pages on the tag
is still red, so the table does not yet say "turn CI on".

@the-homeless-god
fix(ci): the length-claims forgery is pinned to the promise, not a line
07986b7 
Job neznanye-storozha / uncalled-guards, step 10 "Probe length claims" was
red for 0.0 s with "the forgery did not apply: line 75 of
flang/self/emit-rust.flang is not that line any more". The promise "the
backend takes exactly five names" moved from line 75 to line 20, and the
sed pinned to the number said nothing, so the step blamed a forgery that
was never planted.

This is the very rake the neighbouring step "Probe blockers table" warns
about two steps above: "pinned to the PATTERN of the table row, not to the
line number: number 40 slid to 42". The forgery now matches the promise
text itself, which occurs once in the file, and the "did not apply"
message names the promise instead of a line number.

Measured on dev 5604556, binary 0.7.23, each step in its own subshell
the way the runner calls it (bash --noprofile --norc -e -o pipefail), own
RUNNER_TEMP and GITHUB_OUTPUT, GITHUB_REF=refs/heads/dev:

  before   Probe length claims   code 1    0.0 s
  after    Probe length claims   code 0   96.0 s

Negative control, which must be red and is: the pattern replaced by one
absent from the file gives code 1 at 0.0 s and names the promise.

The tree is clean after every run: git status --porcelain is empty.
@the-homeless-god
fix(site): the glossary sections know the syllogism conclusion
5742ff2 
Job neznanye-storozha / uncalled-guards stopped at step 5 "Check glossary"
(dictionary:check) with code 1 and one disagreement: "the notion follows is
in the language table and is written into no section of the glossary: the
page would print half of it and say nothing". Every step after it -- 24 of
them -- was therefore never seen in CI at all.

The row was written by hand into docs/glossary.md on 25 September
(5c640f2), and the section lists in scripts/site/emit-dictionary.fscript,
from which the page is printed, were never told. The notion goes into the
seventh section, "legacy of the former surface", next to therefore, which
is where the hand-written row already sits: the promise of the list length
rises from 64 to 65, and the example that copies the body sign for sign
gets the same entry.

The page needed no rebuild: the hand-written row stands exactly where the
printer puts it, so the comparison matched sign for sign and
docs/glossary.md is untouched by this commit.

Measured on dev 5604556, binary 0.7.23:

  before   dictionary:check   code 1   3.4 s
  after    dictionary:check   code 0   4.7 s
           "glossary: clean -- docs/glossary.md agrees with the table,
            notions 156"

  flang check scripts/site/emit-dictionary.fscript   code 0
           "functions 58, of them with proved termination 58"

Negative control, which must be red and is: with follows taken back out of
the section the check gives code 1 and the former message word for word.
@the-homeless-god
fix(docs): six reader pages and two call sites drop the internal words
a036b6f 
Job neznanye-storozha / uncalled-guards, step 9 "Check jargon"
(jargon:check) was red with code 1 at 196.3 s, peak 3.57 GiB, and six
troubles, not the five task 1117 recorded on 2 October: docs/site/roadmap.ru.md
had joined them with five internal words where four are allowed.

The troubles are of two kinds and are closed differently.

PROSE FOR THE READER, six lines in five files. The word is replaced by the
outside one the guard itself suggests:

  "guard"   -> "check"            docs/site/roadmap.ru.md:83
                                  docs/course/03-totality.md:104
                                  docs/guide/how-to-write-flang.ru.md:44
  "corpus"  -> "programs of the   docs/course/03-totality.md:105
               repository"        docs/course/13-where-next.md:112
  "printer" -> "code generator"   docs/course/09-eight-targets.md:280

NAMES OF FLANG FUNCTIONS, two lines in flang/src/emit/c/flang_repl.c. These
are not prose at all: repl_call("Katalogi mimo korpusa") and
repl_call("Otbor korpusa") name functions that live at
flang/self/bootstrap/corpus.flang:270 and :334. A text ban cannot rename
them -- only a reprint can. They go into the "exceptions" section of
docs/jargon.json with that reason, the same breed and the same wording as
the repl_call("Svesti korpus") entry already sitting there. The debt of the
file stays 42 and the ratchet still forbids it to grow.

Measured on dev 5604556, binary 0.7.23:

  before   jargon:check   code 1   196.3 s   peak 3.57 GiB   troubles 6
  after    jargon:check   code 0   182.5 s   peak 3.62 GiB
           "internal words 992 (debt over 34 files, no right to grow), new 0"

Negative control, which must be red and is: step 8 "Probe jargon guard" of
the same job appends an internal word to CONTRIBUTING.md and demands the
guard go red. It is green, code 0 at 195.3 s, so the guard does redden on a
planted word and the tree is left clean.
@the-homeless-god
feat(ci): the kernel memo probe gets a caller and a name to call it by
4b05c2b 
Job uncalled / checks-nobody-calls was red with code 1 at 17.1 s: "A NEW
CHECK WITH NO CALLER: flang/proof/probes/kernel-memo/run.fscript lies in
the tree and no CI job, no short command, no hook and no other script runs
it."

ASKED THE PROBE FIRST. It is green today, and the record task 5310 took on
2 October -- "code 1 at 306.7 s, KERNEL MEMO CHANGES THE ANSWER" -- no
longer holds: the memo wrappers have reached the seed.

  cd flang/proof/probes/kernel-memo && ../../../../bootstrap/flang io run.fscript
  "kernel memo: runs 6, memo on and audit answer byte for byte as memo off"
                                  code 0 at 175.5 s, peak 0.36 GiB
  the same with --trust            code 0 at 175.5 s, peak 0.36 GiB

So it gets a CALLER, not a ledger entry: the shortcut
script.kernel-memo:probe in .flangrc beside its sibling plan-rules:probe,
and the step "Check kernel memo does not change the answer" in job
storozha of binary.yml, where all twenty of its sisters from
flang/proof/probes/** already stand. ci.yml is no home for a caller: it is
disabled, and a call there would call nobody. The path is counted from the
root, the way the sibling plan-rules-asked is called -- the probe resolves
its order paths from its own directory and needs no cd.

THE PRICE IS SAID OUT LOUD AND ONE NUMBER IS NOT MEASURED. Job storozha
takes 6 min 47 s and 7 min 01 s on the runner (runs 37223001273 and
37223864296). What 175.5 s from this machine adds to it is NOT MEASURED: I
did not run the job on a runner, and one thread of check --proof does not
go at this speed on a two-core one.

THE EIGHTH UNCALLED CHECK IS NOW A DIFFERENT ONE, and it gets a ledger
entry rather than a caller, with the reason in numbers:
flang/proof/probes/text-block/tokens.fscript arrived with the lexer edit
(ADR-0052) and was never called. Without --max-steps it gives no verdict at
all (code 3 at 78.9 s, "the function Skleit exhausted the step limit"), and
with a sample it grows worse than linearly in file size: on a 394-byte file
code 0 at 5.9 s, while ADR-0052 names 9 min 29 s for one 106 KB file and
78 min for a sample of ten (those two numbers are taken from the decision
page, not measured here). A caller over one tiny file would be a check that
does not check.

  before   job uncalled   code 1   17.1 s
  after    job uncalled   code 0   19.2 s
           "checks in the tree 104, without a caller 8, all named in the
            ledger -- agrees"

Negative control, which must be red and is: with both callers removed, the
guard answers code 1 and names the probe. Its own forgery probe, step 4 of
the job, plants a forged probe set and is green at 10.4 s.
@the-homeless-god
docs(tasks): five of the disabled CI jobs are re-measured and go green
ca6347e 
Task 1117 measured all 25 jobs of the disabled ci.yml on 2 October on tree
85cc976: 18 green, 7 red. The five cheapest red ones are re-measured here
on dev 5604556 with the same rig, and all five are green. The numbers of
the earlier measurement are not rewritten: they were taken on another tree.

  zadachnik          code 2    0.3 s  ->  code 0    94.0 s
  seed-verdicts      code 1   40.1 s  ->  code 0   212.2 s
  uncalled           code 1   17.1 s  ->  code 0    19.2 s
  neznanye-storozha  code 1    7.2 s  ->  code 0   722.5 s, all 26 check
                                          steps green, no break
  klyuchi            code 1   75.7 s  ->  code 0    73.3 s

Two of the five needed nothing from this branch: 16729f7 fixed the
scaffolding of zadachnik and the inverted condition of step 14, f909a98
stopped the key ledger calling five keys strangers. Checking the trunk
before working saved the work twice.

seed-verdicts went green by itself: the seed fingerprint now names
843c429, git merge-base --is-ancestor answers code 0, and both verdicts
answer code 0 rather than code 3 "cannot judge".

A RAKE OF THE RIG, NOT OF THE TREE, worth one false red: my first run of
seed-verdicts gave code 1 at 38.5 s. The reason was my own YAML reading --
"${{ runner.temp }}" was substituted only inside the "run:" body and stayed
literal text in the step "env:", so the guard answered "mktemp: failed to
create directory via template". All four steps of that job carry
FLANG_TMP in "env:". Whoever measures the jobs of this file by hand must
substitute expressions there too.

Task 5310 gets the same re-measure from its own side: kernel-memo is green
and called, and the eighth uncalled check is now
flang/proof/probes/text-block/tokens.fscript, with its cost in numbers.

Of the six push jobs that used to block, none blocks now. Two of the seven
reds are untouched and are NOT MEASURED here, being outside this share:
links (named debt, continue-on-error) and stale-pages (course pages on
0.7.22, tag and button only). The workflow stays disabled: turning it on is
not this branch's decision.

  bootstrap/flang run-script tasks:check   code 0
@the-homeless-god
docs(tasks): the printed registry page keeps the uncalled-guards job red
e52790c 
The branch was rebased onto a trunk that had moved 16 commits, one of them
a reseed (d26780e), so the binary is 0.7.24 now. All five jobs were run
again on that tree. Four of the five stay green:

  zadachnik          code 0   105.9 s
  seed-verdicts      code 0   249.6 s
  uncalled           code 0    19.1 s   checks 105, without a caller 8
  klyuchi            code 0    73.4 s
  neznanye-storozha  code 1   397.0 s   stops at step 9 again

The fifth is red for a reason that came with the trunk, not from here, and
it is opened as task 2325. Step 9 "Check jargon" gives code 1 at 202.9 s
with four troubles, all four new: docs/site/registry.md (10 internal words
where 0 are allowed), registry.ru.md (9), packages.md (1) and
packages.ru.md (1). The pages arrived with ffeca8f and are PRINTED by
scripts/site/registry-page.fscript, so a hand edit of the pages would be
wiped by the next build -- the fix belongs in the printer. None of the six
troubles this branch closed came back.

Run step by step rather than by the break, the job has 31 steps now, and
27 of its 28 check steps are green (759.9 s in total). Both fixes of this
branch hold on the new tree: step 5 "Check glossary" code 0 at 4.7 s, step
10 "Probe length claims" code 0 at 96.5 s. The pair "Probe/Check guards
without forgery probe" is new from the trunk and green, 15.4 s and 16.2 s.

A CORRECTION TO MY OWN EARLIER NOTE, and it matters more than the seconds.
I wrote that seed-verdicts is green because the fingerprint names a live
commit and git merge-base --is-ancestor answers code 0. That reason is
WRONG. On the new tree the fingerprint names a1102df, which is NOT an
ancestor of HEAD (code 1: the reseed was printed in a row that the rebase
turned into d5a0a470) -- and the job is green all the same. The guard
judges by the hashes of the print inputs, not by commit kinship, and says
so itself: "the seed is not behind the sources: proven:check". Kinship is
only the explanation it offers once the hashes disagree. Ask the guard, not
merge-base.

The kernel memo probe on binary 0.7.24: code 0 at 177.4 s, peak 0.36 GiB,
the same answer sign for sign. The step comment in binary.yml carries the
0.7.23 number, 175.5 s; the 1.9 s are machine noise under foreign load.

  bootstrap/flang run-script tasks:check                          code 0
  bootstrap/flang io scripts/guards/task-numbers-guard.fscript    code 0
@the-homeless-god
the-homeless-god merged commit 6b459de into dev Oct 4, 2026
32 checks passed
@the-homeless-god
the-homeless-god deleted the a/five-red-ci-jobs-go-green branch October 4, 2026 20:15
@the-homeless-god the-homeless-god mentioned this pull request Oct 4, 2026
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@the-homeless-god