ci: include Xtensa in binary size comparisons

[jakebailey]

This pulls out the llvm build stuff from assert-linux into a composite local workflow then reuses that for sizediff, such that a build of llvm with xtensa support is available.

[deadprogram]

@jakebailey here is a brief automated review:

1. Blocker: sizediff does not install ninja

.github/actions/setup-llvm runs make llvm-build, which calls cmake -G Ninja (make/llvm.mk:92). Every other job that builds LLVM installs ninja first (linux.yml:243, :414, :434, build-macos.yml:83, windows.yml:25). sizediff.yml installs only llvm-20-dev, clang-20, libclang-20-dev, and lld-20. So the LLVM build step fails on a cache miss. This is the LLVM bump case that the new "Set up LLVM for the dev branch" step exists for. Add ninja-build to the sizediff apt step, or install it in the composite action.

2. The shared cache key does not identify the runner image

assert-test-linux runs on ubuntu-latest (linux.yml:223). sizediff pins ubuntu-24.04. Both jobs now read and write llvm-build-22-linux-asserts-v1-<hash>. The llvm-build directory holds binaries and static libraries that link against the image libstdc++ and glibc. Today the two images are the same. When ubuntu-latest moves to the next release, the two jobs exchange incompatible build directories, and the failure is not obvious. Put the runner image in cache-suffix, or pin both jobs to the same image.

3. The apt LLVM packages are now unnecessary

make tinygo builds with the byollvm tag and takes all flags from llvm-build/bin/llvm-config (make/build.mk:41, make/llvm.mk:66-75). It no longer uses the apt LLVM 20 packages. Both "Install apt dependencies" steps and sizediff-install-pkgs.sh can go, together with the comment in that script about the dev branch checkout. This removes two apt runs from each sizediff job.

4. Small points

• make tinygo ASSERT=1: ASSERT only sets LLVM_ENABLE_ASSERTIONS for the LLVM build (make/config.mk:52). It has no effect on the tinygo target. Remove it to prevent confusion.
• The composite action has independent assertions and cache-suffix inputs, with the defaults 1 and linux-asserts-v1. A caller that sets assertions: "0" and keeps the default suffix writes a non assert build under the assert key. A note in the input description prevents this.
• git reset --hard origin/dev before git checkout "${{ github.event.pull_request.base.sha }}" is now only a way to clean the tree. git checkout -f shows the intent more clearly.
• The composite action always saves the caches. On a PR the cache write is scoped to the PR branch, so a multi gigabyte upload helps only re runs of the same branch. An optional save: false input for the sizediff caller would save time and cache quota.

[deadprogram]

@jakebailey please see generated comments above.

[jakebailey]

Done plus other fixes

[deadprogram]

@jakebailey here is a brief automated review of the current head.

All checks pass, and sizediff completes in 23 minutes. The change removes about 50 duplicated lines and gives sizediff an LLVM build with Xtensa support, so XTENSA=0 is no longer necessary.

1. The base commit changes meaning

sizediff.yml replaces this:

git reset --hard origin/dev
git checkout --no-recurse-submodules `git merge-base HEAD origin/dev`

with git checkout --force "${{ github.event.pull_request.base.sha }}".

pull_request.base.sha is the tip of the base branch in the event payload. It is not the merge base. If dev moves forward after the merge base, the dev side of the comparison then holds commits that the PR branch does not have. Size changes from those commits show in the diff. The merge base form kept the diff limited to the changes of the PR. If the goal is only a clean tree, git checkout --force $(git merge-base HEAD origin/dev) keeps both properties.

Please confirm if the new behavior is intentional.

2. The shared cache key does not identify the runner image

The pin of assert-test-linux to ubuntu-24.04 corrects the immediate problem. But the key llvm-build-22-linux-asserts-v1-<hash> still has no image name in it. The llvm-build directory holds binaries and static libraries that link against the libstdc++ and the glibc of the image. Nothing prevents a change of one runs-on value without the other, and that failure is difficult to identify. Put the image name in the key, or add a short comment at both runs-on lines.

3. The LLVM bump path is not tested and it is expensive

The setup-llvm-base steps run only when llvm-version.txt is different. The successful run of this PR does not use them. On that path, sizediff builds LLVM two times from source. Each build takes approximately 40 minutes, as assert-test-linux shows. It also writes two caches of several gigabytes that are scoped to the PR branch. These caches use the 10 GB cache quota of the repository and can remove the dev branch caches that other jobs need. An optional save input on the composite action, set to false for sizediff, prevents the write.

4. The copy of the action needs a comment

cp -r .github/actions/setup-llvm .github/actions/setup-llvm-base is correct because the copy is untracked and stays after the base checkout. This is not clear to a reader. The deleted sizediff-install-pkgs.sh file had a comment for the same purpose. One line is sufficient.

Good changes

• set -o pipefail on the three | tee pipelines. Before, a failure of make smoke-test or of sizediff was hidden.
• Separate GOCACHE and XDG_CACHE_HOME for the base build. The two tinygo builds can no longer share a build cache.
• git clean -fdX src/device with make gen-device correctly makes the device files again. These files are in .gitignore.
• The removal of the github-actions-saved-HEAD branch is safe. It has no other references.

Verdict

The change is correct and it is a good cleanup. Item 1 is the only item that changes the results and needs an answer. Items 2 to 4 are possible follow-ups. The other inline LLVM build blocks, in the alpine job of linux.yml and in the macOS and Windows workflows, are not changed. More deduplication is possible later.

[jakebailey]

pull_request.base.sha is the tip of the base branch in the event payload. It is not the merge base. If dev moves forward after the merge base, the dev side of the comparison then holds commits that the PR branch does not have.

This should actually just use the first parent of the PR's merge commit, yes.

I'll look into the rest.

[deadprogram]

Ping me when ready for another review @jakebailey if you please.

[jakebailey]

By all means, take a look

[deadprogram]

Thanks for making this work @jakebailey and also for handling all the various changes requested. Ready to go! Now merging.