Bake Flarum into the image and seed the volume from it (#2) - #5
Merged
Conversation
The image now contains Flarum. Until this commit the Dockerfile had zero references to flarum/flarum: it was a PHP runtime that downloaded a forum when a container first started, at ^2.0 with beta stability plus six extensions at bare '*'. Seven floating constraints, so the same tag could produce different forums a week apart, and there was no offline install. Build time resolves from the committed lock, which is fine and reproducible — the lock decides. create-project supplies the skeleton's own files (index.php, the flarum CLI, public/, storage/) since those belong to the flarum/flarum package and never appear in vendor/; --no-install skips its resolution because the committed lock replaces its composer.json immediately after. The build fails if the ARG and the lock disagree about flarum/core, because nothing else would notice them drifting apart. First boot with an empty volume copies that skeleton in. Nothing is fetched: the six extensions are already in the skeleton's composer.json, so the existing composer_require calls short-circuit as "already present". Setting TARGET_FLARUM_VERSION is now the deliberate opt-out — it means "resolve this from Packagist instead", the old behaviour, still supported. Images built before the skeleton existed take that path automatically, since the guard tests for the directory. An existing volume is untouched, exactly as before. Whether a running forum should adopt a new skeleton on image update is a separate decision and deliberately not made here.
roundtrip passing proved nothing about where Flarum came from. The runner has network, so the old Packagist path satisfies every check in the job just as well as the baked one — the pin could stop being load-bearing and the suite would stay green. Now it reads the container log and fails if the fresh install did not seed from the skeleton, or if it resolved over the network at all.
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.
The image now contains Flarum. Until this PR the Dockerfile had zero references to
flarum/flarum— it was a PHP runtime that downloaded a forum when a container first started.Build time
Resolves from the committed lock. Build-time network is fine and reproducible; the lock decides what gets installed.
create-project --no-installsupplies the skeleton's own files (index.php, theflarumCLI,public/,storage/) — those belong to theflarum/flarumpackage and never appear invendor/, socomposer installalone would not produce a working root.--no-installskips its resolution because the committed lock replaces itscomposer.jsonimmediately after.The build fails if the
FLARUM_VERSIONARG and the lock disagree aboutflarum/core. The ARG picks the package supplying the root files, the lock picks everything else, and nothing else would notice them drifting apart.First boot
An empty volume is seeded by copying the baked skeleton. Nothing is fetched — the six extensions are already in the skeleton's
composer.json, so the existingcomposer_requirecalls short-circuit as "already present". That makes a fresh install fully offline.TARGET_FLARUM_VERSIONbecomes the deliberate opt-out: setting it means "resolve from Packagist instead", the old behaviour, still supported. Images built before the skeleton existed take that path automatically, since the guard tests for the directory.Deliberately not in scope
An existing volume is untouched, exactly as today. Whether a running forum should adopt a new skeleton on image update is the open question in #2 and is not decided here — this PR is the fresh-install half, which is where the value is and which has no ambiguity.
What proves it
roundtripbuilds the image, installs a forum from scratch, plants a marker, backs it up, destroys the volumes and restores. If seeding from the skeleton were wrong in any way, a fresh install would not come up and that job fails.