Check out a referenced angr/binaries pull request on macOS and Windows

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

The ci jobs cle inherits check angr/binaries out at the pull request the
description names. Test macos-15 and Test windows-2022, which this workflow
defines itself, check it out with no ref:, so they get master. A cle change
whose regression loads a new fixture therefore passes every inherited job and
fails those two until the fixture lands.

Both jobs now read the reference out of the body the way resolve_refs.py does:
angr/binaries#<number> or a pull request URL, first one found, and its head
only while that pull request is still open. A push, or a body naming no binaries
pull request, takes master. The body reaches the step in an environment variable
and only the digits extracted from it reach the ref, so nothing in it is
interpreted.

This description names angr/binaries#184, the fixture #764 needs, so the
run on it exercises the path.

Validation: #738 (comment)

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Validation record for head 0c3eddb03675f48781d305a7c6446fee9ec7d227 against baseline 3f408bbdbb66819edabe66a8bde150c40556b6c3. This replaces the record for the two-step version of this branch: the generic Resolve referenced sibling pull requests step is gone, and what is left is one step and 23 added lines in .github/workflows/ci.yml.

Why the generic step went. cle's [tool.uv.sources] names archinfo and pyvex and nothing else, so that step could only ever have overridden those two packages.

• Of the 44 open cle pull requests, 14 name an angr/binaries pull request in the body and 3 name archinfo or pyvex: Pack and unpack words struct cannot describe #721 (Reject word sizes struct cannot express archinfo#364, open), Cover object placement in an address space narrower than a granule #717 (Support narrow p-code stack pointers archinfo#363, open) and Test CLE under Pyodide #704 (Add wasm32 Pyodide wheel support pyvex#555, merged, so the step would have skipped it). ELF: Apply the header fields a p-code opinion constrains #740, checked because a p-code opinion change is the likeliest candidate to need archinfo or pypcode, names only sync: angr/binaries#177; pypcode is not in [tool.uv.sources] at all.
• Neither of the two live references is load-bearing. Pack and unpack words struct cannot describe #721 passes Test macos-15 and Test windows-2022 against archinfo master (macOS, Windows); its pack_word/unpack_word change bypasses struct_fmt for any width struct cannot name, so archinfo#364 changes nothing it tests. Cover object placement in an address space narrower than a granule #717 does too (macOS, Windows); archinfo#363 only changes initial_sp where the stack pointer is narrower than 16 bits, and the z80 that test loads is not.
• The step ran on 8 jobs across 4 runs, every one of them on this branch, and every one resolved ArchPcode: Report no program counter for a language that declares none. archinfo#367 — the reference this description carried in order to exercise it. It has never fired on any other cle pull request, because it has never existed anywhere but here. archinfo#367 has since merged, so even that reference would now resolve to nothing.

Resolver. The run: block taken verbatim out of ci.yml and driven with bash --noprofile --norc -eo pipefail, the way a shell: bash step runs, against the real GitHub API:

body	ref
... coff_bss.obj (angr/binaries#184), a 580-byte object.	refs/pull/184/head
fixture angr/binaries#184:	refs/pull/184/head
fixture angr/binaries#184.	refs/pull/184/head
see https://github.com/angr/binaries/pull/184).	refs/pull/184/head
sync: angr/binaries#176 (merged)	master, with angr/binaries#176 is closed, so it is not used
prose naming no pull request	master
empty, which is what ${{ github.event.pull_request.body }} evaluates to on a push and on a workflow_dispatch	master
angr/binaries#$(id -u) `id` ; touch /tmp/canary && angr/binaries#184	refs/pull/184/head, none of it executed and the canary file absent

The first four rows are the point of the third and fourth: resolve_refs.py strips only , and ; before requiring isdigit(), so a body reading angr/binaries#184: or angr/binaries#184. resolves nothing, prints nothing, and the job tests against binaries master while appearing to honour the reference. cle#764 hit exactly that today and lost a cycle to it. This step matches with a regex that stops at the digits, so trailing punctuation does not reach it.

End to end. this description names angr/binaries#184, which was open when the run started, so both jobs logged Checking out angr/binaries at refs/pull/184/head, fetched +refs/pull/184/head:refs/remotes/pull/184/head, and checked out f49c049 Add a COFF object whose .bss covers its own .text, that pull request's head, in place of binaries master. 238 passed and 9 skipped on both: macOS, Windows. The earlier runs on this branch named no binaries pull request and logged Checking out angr/binaries at master, which is the other half of the same check.

Lint. actionlint 1.7.12 with shellcheck 0.11.0 on ci.yml, clean on both the merge base and this head. pre-commit run --all-files in cle passes and leaves the tree unchanged. run-ci-diff-checks.py reports 0 changed Python files, so both hosted jobs pass trivially.

Not run: the workspace Python gate, since this changes no Python.

Checks. All 19 checks on 0c3eddb pass, read individually rather than from a workflow conclusion. Every check run on this commit belongs to run 32155090344, the run on this head, so no verdict is carried over from an earlier attempt.

Caveats. A description edit does not retrigger CI and a re-run replays the original event payload, so the reference has to be in the description when the run starts. A GitHub API failure while checking that the referenced pull request is open leaves the checkout on master rather than failing the job. Only the first angr/binaries reference in the body is used.

[angr-bot]

Corpus decompilation diffs can be found at angr/dec-snapshots@master...angr/cle_738

[twizmwazin]

Could we limit the scope of this to just the binaries repo, since that seems to be the motivating factor in all of our cases?

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

You are right. The generic step is deleted; the branch is now one step and 23 added lines in .github/workflows/ci.yml, binaries only.

I enumerated rather than guessed. cle's [tool.uv.sources] names archinfo and pyvex and nothing else, so that step could only ever have overridden those two. Of the 44 open cle pull requests, 14 name an angr/binaries pull request and 3 name archinfo or pyvex: #721 (angr/archinfo#364), #717 (angr/archinfo#363) and #704 (angr/pyvex#555, merged, which the step skipped anyway). #721 and #717 both pass Test macos-15 and Test windows-2022 against archinfo master today, so neither of the two live references was load-bearing. #740 was the likeliest candidate to need a Python sibling and names only sync: angr/binaries#177. In four runs the step fired eight times, all on this branch, every one resolving the archinfo pull request this description carried in order to exercise it; it has never resolved anything for a real case.

Worth knowing separately, because it is the same subject: resolve_refs.py strips only , and ; before requiring the text after # to be all digits, so a body reading angr/binaries#184: — with a colon — resolves nothing and prints nothing, and the job tests against binaries master while looking like it honoured the reference. #764 hit that today and lost a cycle to it; rewording to (angr/binaries#184), fixed it. The step here matches with a regex that stops at the digits, so trailing punctuation does not reach it.

Head 0c3eddb. This description names angr/binaries#184, so both jobs check that pull request's head out end to end: macOS and Windows, HEAD is now at f49c049 Add a COFF object whose .bss covers its own .text. Validation: #738 (comment)

Landing this unblocks #740, #755, #756, #757 and #764, whose only macOS and Windows failures are missing-file errors on fixtures that are open in angr/binaries.

[twizmwazin]

Thanks, if you haven't already, can you mirror these changes in your other PRs and rebase the blocked ones?