ci-aarch64-fresh-install.yml

name: ci-aarch64-fresh-install

# End-to-end "fresh install" of the whole ecosystem on a NATIVE aarch64 host,
# exactly as a new aarch64-Linux / Termux(-proot) user would:
#
#   curl quick_install.sh | bash     -> installs aarch64 xlings (static musl)
#   xlings install mcpp              -> installs aarch64 mcpp (static musl)
#   mcpp new / build / run           -> NATIVE aarch64 build (pulls the native
#                                       musl-gcc toolchain from the ecosystem)
#
# Validates that every published aarch64 asset (xlings, mcpp, musl-gcc) lines
# up and that mcpp can build & run a real `import std` program natively on
# aarch64 — no cross, no qemu. Runs on GitHub's native ARM64 runner.

on:
  workflow_dispatch:
  schedule:
    - cron: '0 6 * * 1'   # weekly Mon 06:00 UTC
  pull_request:
    branches: [ main ]
    paths:
      - 'src/build/build_program.cppm'
      - 'src/platform/process.cppm'
      - 'tests/e2e/168_build_mcpp_musl_host_static.sh'
      - '.github/workflows/ci-aarch64-fresh-install.yml'
  push:
    branches: [ main ]
    paths:
      - '.github/workflows/ci-aarch64-fresh-install.yml'

permissions:
  contents: read

concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  fresh-install:
    name: fresh install + native build (aarch64 / glibc)
    runs-on: ubuntu-24.04-arm
    timeout-minutes: 60
    env:
      # Verbose every mcpp invocation — cold bootstrap path (src/cli.cppm).
      MCPP_VERBOSE: "1"
    steps:
      # NB: the checkout deliberately comes LAST, after every fresh-install
      # step below — see the comment above it.
      - name: System info
        run: |
          uname -a
          echo "arch: $(uname -m)"   # aarch64 on this runner

      - name: Fresh-install xlings (curl | bash)
        env:
          XLINGS_NON_INTERACTIVE: '1'
        run: |
          curl -fsSL https://raw.githubusercontent.com/openxlings/xlings/main/tools/other/quick_install.sh | bash
          echo "$HOME/.xlings/subos/current/bin" >> "$GITHUB_PATH"
          echo "$HOME/.xlings/bin" >> "$GITHUB_PATH"

      - name: Verify xlings + GLOBAL mirror
        run: |
          xlings --version
          xlings config --mirror GLOBAL 2>/dev/null || true
          xlings update -y 2>/dev/null || xlings update 2>/dev/null || true

      - name: Fresh-install mcpp via xlings
        run: |
          xlings install mcpp -y
          mcpp --version
          mcpp self config --mirror GLOBAL 2>/dev/null || true

      - name: Refresh mcpp package index (force latest xim-pkgindex)
        run: |
          # mcpp seeds a baseline index with a freshness TTL marker, so a plain
          # `index update` can no-op within the window. Force the latest index
          # so this run validates the native build against current packages.
          mcpp index update || true
          idx="$HOME/.mcpp/registry/data/xim-pkgindex"
          rm -rf "$idx"
          # A bare `git clone` here fails the whole job on a runner DNS
          # hiccup. The policy lives in .github/tools/git_clone_retry.sh —
          # but this job checks the repository out LAST ON PURPOSE (a
          # `.xlings.json` in the workspace re-points where `xlings install`
          # writes, so an early checkout silently changes what the
          # fresh-install steps above are testing). The helper therefore does
          # not exist on disk yet, and the retry is spelled inline. Same
          # policy: retry every failure, bounded, git's own message survives.
          clone_retry() {
            local rc dest="${@: -1}"
            for i in 1 2 3 4; do
              rc=0; git clone "$@" || rc=$?
              [ "$rc" = 0 ] && return 0
              [ "$i" = 4 ] && return "$rc"
              [ -e "$dest" ] && rm -rf -- "$dest"
              echo "clone_retry: attempt $i failed (exit $rc); retrying" >&2
              sleep $((i * 5))
            done
          }
          clone_retry --depth 1 https://github.com/openxlings/xim-pkgindex "$idx"
          grep -n "skipping relocation\|os.isfile(path.join(bindir" "$idx/pkgs/m/musl-gcc.lua" | head -2 || true

      - name: Native build + run an `import std` program
        run: |
          work=$(mktemp -d); cd "$work"
          mcpp new hello
          cd hello
          # default src uses import std (C++23)
          mcpp build
          out=$(mcpp run 2>/dev/null || true)
          echo "program output: $out"
          bin=$(find target -type f -path '*/bin/hello' | head -1)
          file "$bin"
          file "$bin" | grep -q "ARM aarch64" || { echo "expected aarch64 ELF"; exit 1; }

      - name: Self-host — build mcpp + xlings from source natively
        run: |
          # mcpp/xlings manifests pin a glibc default toolchain; on aarch64 the
          # musl-static target is the published path, so build with --target.
          #
          # On a pull_request, self-host the code UNDER REVIEW rather than
          # upstream main. Cloning main meant this gate never saw the PR at
          # all: a change that breaks the from-source build passed here and
          # only failed after merge, and — the way this surfaced — a fix to
          # the repo's own bootstrap pin was untestable, because the fix was
          # on the branch while the clone was of main. Outside a PR there is
          # no head ref and main is exactly right.
          ref='${{ github.event.pull_request.head.sha }}'
          repo='${{ github.event.pull_request.head.repo.clone_url }}'
          [ -n "$ref" ]  || ref='${{ github.sha }}'
          [ -n "$repo" ] || repo='https://github.com/mcpp-community/mcpp'
          # fetch-by-sha rather than `clone --depth 1`, which cannot take one.
          git init -q /tmp/mcpp-src
          cd /tmp/mcpp-src
          git remote add origin "$repo"
          git fetch -q --depth 1 origin "$ref"
          git checkout -q FETCH_HEAD
          echo "self-hosting $repo @ $ref"
          # The clone's .xlings.json declares `workspace.mcpp` — the BOOTSTRAP
          # pin, hand-maintained and deliberately lagging the newest release.
          # It is scoped to the working directory and beats anything installed,
          # so every `mcpp` below resolved the bootstrap version, which the
          # fresh-install steps above never installed:
          #
          #     [error] xlings: version '2026.8.6.2' not found for 'mcpp'
          #     [error]   available: 2026.8.8.2
          #
          # "newest release != bootstrap pin" is the NORMAL state, so this step
          # failed on every run from the moment the two diverged — and it is
          # weekly, so nothing pointed at it. This step tests the freshly
          # installed RELEASED binary against a source tree; the bootstrap pin
          # has no standing in that question. install_released_mcpp.sh removes
          # it for exactly this reason on the x86_64 legs (its point 1); this
          # leg was written separately and never got it.
          rm -f .xlings.json
          mcpp self config --mirror GLOBAL 2>/dev/null || true
          mcpp build --target aarch64-linux-musl
          # Absolute: it is used again after `cd /tmp/xlings-src` below.
          m=$(find "$PWD/target/aarch64-linux-musl" -type f -path '*/bin/mcpp' | head -1)
          file "$m" | grep -q "ARM aarch64" || { echo "expected aarch64 mcpp"; exit 1; }
          "$m" --version
          # MCPP_HOME must be carried over explicitly: mcpp derives it from the
          # BINARY's location, so a binary sitting in /tmp/mcpp-src/target would
          # otherwise adopt an empty home and re-bootstrap the whole ecosystem
          # instead of reusing what the fresh-install steps above provisioned.
          #
          # Resolved HERE, before the cd below, and that placement is load-
          # bearing: `mcpp` is the shim, so it obeys whatever workspace pin the
          # CURRENT DIRECTORY carries — and the xlings checkout declares one too
          # (`workspace.mcpp = 2026.8.6.1`, its own bootstrap). Run from there,
          # this resolves a version nothing installed, MCPP_HOME comes back
          # empty, and the step dies on the guard below instead of on the real
          # cause. /tmp/mcpp-src has had its pin removed above, so ask from here.
          export MCPP_HOME=$(mcpp self env | awk -F'= *' '/^MCPP_HOME/{print $2; exit}')
          echo "reusing MCPP_HOME=$MCPP_HOME"
          test -d "$MCPP_HOME" || { echo "could not determine MCPP_HOME"; exit 1; }
          # Same inline retry as the index clone above, and for the same
          # reason — the checkout that would provide the shared helper is
          # deliberately the last step in this job.
          clone_retry() {
            local rc dest="${@: -1}"
            for i in 1 2 3 4; do
              rc=0; git clone "$@" || rc=$?
              [ "$rc" = 0 ] && return 0
              [ "$i" = 4 ] && return "$rc"
              [ -e "$dest" ] && rm -rf -- "$dest"
              echo "clone_retry: attempt $i failed (exit $rc); retrying" >&2
              sleep $((i * 5))
            done
          }
          clone_retry --depth 1 https://github.com/openxlings/xlings /tmp/xlings-src
          cd /tmp/xlings-src
          # "$m", not `mcpp`: the just-built binary is the code under review,
          # and building xlings with the INSTALLED one meant this half of the
          # gate never saw the PR — the same defect the clone-ref comment above
          # records, one line further down. It surfaced the same way: a fix for
          # an aarch64-only failure in exactly this build could not be
          # validated here, because the binary running it predated the fix.
          "$m" build --target aarch64-linux-musl
          x=$(find target/aarch64-linux-musl -type f -path '*/bin/xlings' | head -1)
          file "$x" | grep -q "ARM aarch64" || { echo "expected aarch64 xlings"; exit 1; }
          "$x" --version

      # ── PR regression gate ────────────────────────────────────────────────
      # Everything above is the fresh-install charter: it must run exactly as a
      # new user's machine does. Check out only NOW — this repo's .xlings.json
      # declares an `mcpp` WORKSPACE pin, so with the checkout present in
      # $GITHUB_WORKSPACE `xlings install mcpp` installs workspace-scoped
      # instead of globally: the steps above would silently validate the pinned
      # version rather than the freshly published one, and bare `mcpp` stops
      # resolving anywhere outside the workspace.
      - uses: actions/checkout@v4
        with:
          persist-credentials: false

      # The PR's own source, then the musl host-helper regression against it.
      # This is the only runner where a musl toolchain is the NATIVE one, so it
      # is the only place #295 can actually be reproduced.
      - name: Build current mcpp source for native regression tests
        run: |
          # Third site of the same pin, and the reason to remove it here too:
          # this job installs `xlings install mcpp` (bare = latest) and NOTHING
          # else, so the bootstrap version the checkout pins is never on this
          # runner. Obeying the pin here does not select an older builder — it
          # selects one that does not exist. Same removal as the self-host step
          # above, same reason as install_released_mcpp.sh point 1.
          rm -f .xlings.json
          mcpp build --target aarch64-linux-musl
          self=$(find target/aarch64-linux-musl -type f -path '*/bin/mcpp' | head -1)
          test -x "$self"
          self=$(realpath "$self")
          "$self" --version
          echo "MCPP_SELF=$self" >> "$GITHUB_ENV"

      - name: "Regression: build.mcpp host helper is self-contained (#295)"
        run: MCPP="$MCPP_SELF" bash tests/e2e/168_build_mcpp_musl_host_static.sh