packfs/.gitea/workflows/ci.yml

# Gitea Actions workflow (not GitHub Actions — this project is hosted on
# Gitea, see CONTRIBUTING.md). Gitea Actions' YAML is GitHub-Actions-
# compatible, but two things here are Gitea-specific and need to match
# your actual instance, not just this repo:
#   - `runs-on: ubuntu-latest` must match a label your registered Gitea
#     runner (act_runner) actually advertises; there is no GitHub-hosted-
#     runner equivalent, this is entirely self-hosted.
#   - `uses: actions/checkout@v4` resolves against whatever action source
#     your instance's runner is configured with (by default, Gitea Actions
#     fetches actions from github.com unless DEFAULT_ACTIONS_URL is
#     overridden); use `https://gitea.com/actions/checkout@v4` instead if
#     your runner is configured to disallow GitHub as an action source.
name: CI

on:
  push:
  pull_request:

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build static + shared library
        run: make all

      - name: Run test suite
        run: make test

      - name: Build and run under AddressSanitizer + UndefinedBehaviorSanitizer
        run: |
          # Two independent problems, both fixed below, confirmed by
          # actually reproducing each rather than assumed fixed by
          # inspection:
          #
          # 1. This step's default shell runs under `set -e`: a bare
          #    `"./binary"` whose exit code is never captured (as an
          #    earlier version of this loop did) aborts the *entire*
          #    step the instant any single binary returns nonzero --
          #    including the documented, non-fatal DEADLYSIGNAL sandbox-
          #    startup flake (CONTRIBUTING.md), which would then read as
          #    a real build failure. Confirmed directly: a two-line
          #    reproduction of the same unwrapped-`OUT=$(cmd)` pattern
          #    aborts under `-e` before the very next line, even one
          #    that only reads $?, ever runs.
          #
          # 2. The flake's worse form is an *unbounded* repeating print
          #    loop, not a clean single-line failure -- capturing that
          #    into a shell variable via `OUT=$(cmd)` (an earlier version
          #    of this fix did exactly that) is not just slow, it
          #    reproduced as a genuine several-hundred-megabyte shell
          #    string in one run, at which point this script's own
          #    string classification stopped behaving reliably. Output is
          #    redirected straight to a file instead (bounded disk I/O,
          #    not an unbounded in-memory shell string), and only a
          #    bounded prefix of that file is ever read back for
          #    classification or printed -- generously sized (64 KiB) to
          #    comfortably hold any real ASan/UBSan report this project
          #    has actually produced (historically a few dozen lines),
          #    while nowhere near what the runaway-loop flake produced.
          mkdir -p build/san
          for f in src/*.c; do
            cc -std=c11 -Wall -Wextra -O1 -g -fPIC -Iinclude -Isrc -D_GNU_SOURCE \
               -fsanitize=address,undefined -c "$f" -o "build/san/$(basename "${f%.c}").o"
          done
          FAIL=0
          for t in tests/test_*.c; do
            name=$(basename "${t%.c}")
            cc -std=c11 -O1 -g -Iinclude -Isrc -D_GNU_SOURCE -fsanitize=address,undefined \
               "$t" build/san/*.o -lpthread -o "build/san/$name"
            OK=0
            LOG="build/san/$name.out"
            for attempt in 1 2 3 4 5; do
              if timeout 30 "./build/san/$name" > "$LOG" 2>&1; then
                RC=0
              else
                RC=$?
              fi
              head -c 65536 "$LOG" > "$LOG.head"
              if [ $RC -eq 0 ] && grep -q "^OK$" "$LOG.head"; then
                cat "$LOG.head"
                OK=1
                break
              fi
              if grep -q "AddressSanitizer:DEADLYSIGNAL" "$LOG.head" \
                 && ! grep -qE "ERROR: AddressSanitizer|runtime error:" "$LOG.head"; then
                # 3 retries turned out not to be enough in practice: this
                # sandbox's actual flake rate is meaningfully higher than
                # the "roughly 1 in 5-10" CONTRIBUTING.md documents
                # elsewhere (observed directly: 3 consecutive flake hits
                # on the same binary, purely by chance, within just a
                # handful of full-suite runs during this workflow's own
                # development) -- 5 attempts reduces the chance of
                # exhausting the budget on bad luck alone without making
                # a real failure take meaningfully longer to report.
                echo "::warning::$name attempt $attempt/5 hit the known DEADLYSIGNAL sandbox-startup flake (CONTRIBUTING.md), not a real finding — retrying"
              else
                echo "::error::$name — real ASan/UBSan failure (exit $RC), first 64KiB:"
                cat "$LOG.head"
                break
              fi
            done
            rm -f "$LOG" "$LOG.head"
            if [ $OK -ne 1 ]; then
              echo "::error::$name failed all 3 attempts (or failed with a real finding on one of them)"
              FAIL=1
            fi
          done
          if [ $FAIL -ne 0 ]; then
            echo "One or more binaries had a real ASan/UBSan failure. Failing the build."
            exit 1
          fi

      - name: Build and run under ThreadSanitizer
        run: |
          # TSan needs personality(ADDR_NO_RANDOMIZE) to disable ASLR for
          # itself; some containerized runners (including this project's
          # own registered Gitea runner, confirmed empirically, not just
          # hypothesized — see CONTRIBUTING.md and CLAUDE.md) block that
          # syscall outright via their default seccomp profile, in which
          # case every TSan binary fails identically with `FATAL:
          # ThreadSanitizer: unexpected memory mapping`, regardless of
          # PackFS's own correctness. Treating that exact, specific
          # failure signature as fatal would make CI permanently red for
          # a reason that has nothing to do with the code under test — so
          # this step distinguishes it from a real finding (a genuine data
          # race, a crash, or any other failure) rather than either
          # blanket-ignoring TSan failures (which would also hide a real
          # race) or blanket-failing the build on an environment limitation
          # this repository doesn't control.
          #
          # This step's default shell runs under `set -e`. The very first
          # version of this script assigned OUT via a bare, unwrapped
          # `OUT=$("./binary" 2>&1)` — under `-e`, that command's own
          # nonzero exit status aborts the whole script immediately,
          # *before* the next line (even `RC=$?`) ever runs, which means
          # none of the classification logic below ever executed: the
          # first binary to hit the FATAL/exit-66 case (all of them, on
          # this runner) killed the step outright with that raw exit code
          # as if it were a real failure, exactly the outcome this step
          # exists to avoid. Confirmed directly (not just theorized): a
          # two-line reproduction of the same pattern under `set -e`
          # aborts before printing a line straight after it. Fixed by
          # wrapping the invocation in `if ... ; then ... else RC=$?; fi`,
          # which bash's `-e` rules exempt from triggering an abort.
          #
          # Output is also captured to a file and only a bounded prefix
          # (64 KiB) is ever read back or printed, not the whole thing
          # into a shell variable — the same fix the ASan/UBSan step
          # above needed after that approach reproduced as a several-
          # hundred-megabyte shell string when the flake's unbounded-
          # repeating-loop form hit during this file's own development.
          mkdir -p build/tsan
          for f in src/*.c; do
            cc -std=c11 -Wall -Wextra -O1 -g -fPIC -Iinclude -Isrc -D_GNU_SOURCE \
               -fsanitize=thread -c "$f" -o "build/tsan/$(basename "${f%.c}").o"
          done
          KNOWN_FLAKE=0
          REAL_FAILURE=0
          for t in tests/test_*.c; do
            name=$(basename "${t%.c}")
            cc -std=c11 -O1 -g -Iinclude -Isrc -D_GNU_SOURCE -fsanitize=thread \
               "$t" build/tsan/*.o -lpthread -o "build/tsan/$name"
            LOG="build/tsan/$name.out"
            if timeout 30 "./build/tsan/$name" > "$LOG" 2>&1; then
              RC=0
            else
              RC=$?
            fi
            head -c 65536 "$LOG" > "$LOG.head"
            rm -f "$LOG"
            # The known-limitation signature has two observed forms, both
            # confirmed by direct, repeated reproduction on this runner
            # (not assumed): (a) a clean `FATAL: ThreadSanitizer:
            # unexpected memory mapping` message then exit 66, and (b)
            # TSan's broken startup segfaulting outright instead of
            # printing that message — confirmed to be the same underlying
            # cause, not a real per-binary bug, by hitting three
            # *different* binaries (test_journal_failure in one run,
            # test_crash_consistency and test_dir together in another)
            # across repeated full-suite runs, with zero reproductions
            # tied to any specific binary's own code. Form (b) is
            # recognized by the log containing only `timeout`'s own
            # "dumped core" notice and nothing else — meaning the crash
            # happened before any of the program's own output (or a real
            # WARNING/SUMMARY ThreadSanitizer race report) had a chance
            # to be written at all.
            if [ $RC -eq 0 ]; then
              cat "$LOG.head"
            elif grep -q "FATAL: ThreadSanitizer: unexpected memory mapping" "$LOG.head" \
                 && ! grep -qE "WARNING: ThreadSanitizer: |SUMMARY: ThreadSanitizer:" "$LOG.head"; then
              echo "::warning::$name — known runner limitation (TSan can't start here), not a code finding:"
              cat "$LOG.head"
              KNOWN_FLAKE=1
            elif grep -q "dumped core" "$LOG.head" \
                 && [ "$(grep -vc "dumped core" "$LOG.head")" -eq 0 ]; then
              echo "::warning::$name — known runner limitation (TSan's broken startup segfaulted instead of printing its usual FATAL message this time; same cause, confirmed by hitting other, unrelated binaries too), not a code finding:"
              cat "$LOG.head"
              KNOWN_FLAKE=1
            else
              echo "::error::$name — real ThreadSanitizer failure, first 64KiB:"
              cat "$LOG.head"
              REAL_FAILURE=1
            fi
            rm -f "$LOG.head"
          done
          if [ $REAL_FAILURE -ne 0 ]; then
            echo "One or more binaries failed ThreadSanitizer for a reason other than the known runner limitation. Failing the build."
            exit 1
          fi
          if [ $KNOWN_FLAKE -ne 0 ]; then
            echo "ThreadSanitizer could not run at all on this runner (known limitation, not a code issue) — this step is not treated as a build failure, but TSan verification did NOT happen this run. See CONTRIBUTING.md."
          fi