compiler-explorer / compiler-explorer/infra

Library build workflows fetch start-builder over HTTP instead of checking it out

Open
#2,273 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
434
Forks
429
Avg merge
4d 21h
Merged PRs (30d)
38

Description

`lin-lib-build.yaml:75` bootstraps the build by curling the script from
raw.githubusercontent rather than checking the repo out:

curl -sL "https://raw.githubusercontent.com/compiler-explorer/infra/refs/heads/${{ inputs.branch || 'main' }}/init/start-builder.sh" -o "/tmp/start-builder.sh"

The script then does its own `git clone --branch "$BRANCH"` for the rest of
infra. So the job pulls the same commit-ish through two different transports:
the bootstrap script over cacheable HTTP, the tree over git. Those can disagree.

They did on 2026-08-05. Two consecutive runs dispatched after a push to a
branch ran the *previous* commit's script while cloning the current tree; a
third run against an identical commit under a fresh branch name picked the new
script up immediately. Chased that as a code bug for a while before spotting the
old PATH in the `set -x` output.

The job has no `actions/checkout` at all -- the only `uses:` in the file is
upload-artifact.

Suggested fix: `actions/checkout` with `ref: ${{ inputs.branch || 'main' }}` and
run `init/start-builder.sh` from the workspace. No HTTP, nothing cacheable in
front of it, and the script version matches the tree version by construction.
The `git clone` inside start-builder.sh may then be redundant.

`win-lib-build.yaml:32` does the same thing for `start-builder.ps1` and is
worse off: the URL is hardcoded to `main`, so the `branch` input cannot reach
it and Windows library builds cannot be branch-tested at all.

Not urgent -- it only bites when iterating on start-builder itself. But it makes
that iteration actively misleading, and it means the script that runs is not the
one under review in a PR.

Contributor guide

Open the contributing guide

Research direction

Read lin-lib-build.yaml:75 and win-lib-build.yaml:32, then inspect init/start-builder.sh and init/start-builder.ps1 to understand their current bootstrap and clone behavior. Run the affected library workflows with a branch input; done means both workflows check out the requested ref, run the workspace script, avoid fetching it over HTTP, and use the matching script version.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, github-actions, powershell, shell
Domain
ci-cd, devops, infrastructure
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.