Docker: link system libffi instead of fetching from GitHub#4
Merged
Conversation
Alien::FFI in share mode (the global ALIEN_INSTALL_TYPE=share) fetches a libffi tarball from a GitHub release page to build it from source. That download is fragile and rate-limited — Alien::Build itself warns the release-page download negotiator "will typically not work" — and it broke the Docker image build intermittently in CI (identical Alien-FFI-0.27 / FFI-Platypus-2.11 succeeded ~16h earlier, then failed with no code change). Install Alien::FFI up front with ALIEN_INSTALL_TYPE=system against the packaged libffi (apt libffi-dev), so it links the system library and never touches GitHub. The libgit2 vendoring (share build) is left untouched, so the runtime stays self-contained; libffi8 is added to the runtime image for the now-dynamically-linked FFI::Platypus. Verified end-to-end with a multi-stage build mirroring the Dockerfile: Alien::FFI links system libffi (no fetch), libgit2 still vendors, and the runtime loads Git::Native + FFI::Platypus + libgit2 + libffi cleanly. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A push trigger with branches: ['*'] only matches single-segment branch names; a branch like fix/foo (with a slash) never fires the push event, so feature branches silently get no on-push CI. ['**'] matches across slashes. pull_request already covered PRs; this fixes direct branch pushes too. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Was war kaputt
Der CI-Build von
e7c2e5eschlug im Docker-Image-Build (@Author::GETTY::Docker) fehl — nicht in den Tests. Die Fehlerkette:Der Commit selbst (
.claude/-Agent-Struktur) hat weder Code,cpanfile,dist.ininochDockerfileangefasst. Beweis: Der grüne Run ~16 h zuvor baute dieselben Versionen (Alien-FFI-0.27,FFI-Platypus-2.11,Git-Native-0.003) erfolgreich. Also transient.Ursache
Der Docker-
buildersetzt globalALIEN_INSTALL_TYPE=share. Das zwingt auchAlien::FFIin den share-Modus, wo es ein libffi-Tarball von einer GitHub-Release-Seite lädt und aus Quellcode baut. Alien::Build warnt selbst:Dieser Download ist rate-limited / unzuverlässig → intermittierende Build-Fehler.
Fix
libffi-devim builder ergänzt undAlien::FFIvorab mitALIEN_INSTALL_TYPE=systeminstalliert → linkt das System-libffi, kein GitHub-Download mehr.libgit2-Vendoring-Pfad (share) bleibt unverändert → runtime bleibt self-contained.libffi8ins runtime-Image, daFFI::Platypusjetzt dynamisch gegen System-libffi.solinkt.Verifikation
Lokaler Multi-Stage-Build, der den Dockerfile-Aufbau spiegelt:
Alien-FFI-0.27baut in ~1,5 s ohne libffi-Fetch (vorher ~30–60 s Source-Build im share-Modus).Alien-Libgit2baut weiter vendored (~70 s via cmake).perl -MGit::Nativelädt FFI::Platypus + vendored libgit2 + system libffi sauber → SMOKE OK.🤖 Generated with Claude Code