Pin the build's inputs and tag by Flarum version (closes #2) - #6
Merged
Conversation
Three things, all closing #2. Extension Manager is now tested. It is the one behaviour baking Flarum into the image could plausibly disturb: the volume is still meant to be a writable Composer project, merely SEEDED from the image instead of resolved from the network, and a wrong owner or mode on the copied tree would leave the forum serving perfectly while silently refusing every extension install. roundtrip now installs fof/doorman the same way the Extension Manager does — composer, as www-data, against the volume — enables it, and checks the forum still serves. Build inputs pinned. redis came from pecl.php.net unpinned, which is why v1.0.0 needed three attempts while PECL returned 504s; a pin does not make PECL reliable but it does mean a retry produces the same extension rather than whatever is newest by then. Composer was worse: the installer was piped into php unverified and unversioned, so two builds of one commit could ship different Composers. It is now pinned to 2.10.2 with the signature check the Composer project publishes for this. Tags now name the forum. flarum-<version> is read from the committed lock, so the tag answers the question users actually have — which Flarum is this — which a wrapper version number never could. Also emitted as image labels.
The first version of this step used fof/doorman and failed — but not because the seeded volume was wrong. composer require, extension:enable and cache:clear all succeeded; the forum then 500'd because doorman's Flarum 2 release is a beta against an RC core. Note the stable 2.0.0 is the Flarum 1.3 build, so composer had picked correctly. That conflated two things: whether the Extension Manager can write into a volume seeded from the image, and whether some third-party extension works on 2.0.0-rc.5. Only the first has anything to do with baking Flarum in, and only the first should be able to fail here. linkrobins/clipboard declares flarum/core ^2.0, has no dependencies of its own, and runs on a live 2.0 forum. It is installed, enabled, checked, then disabled and removed — the restore steps rebuild the volume from the image, which would not carry a third-party extension the backup's database still had enabled.
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 last three items on #2.
Extension Manager is now tested
This is the one behaviour baking Flarum in could plausibly disturb. The volume is still meant to be a writable Composer project — merely seeded from the image rather than resolved from the network — and a wrong owner or mode on the copied tree would leave the forum serving perfectly while silently refusing every extension install. That is not a failure anyone would attribute to this change months later.
roundtripnow installsfof/doormanthe same way the Extension Manager does (composer, aswww-data, against the volume), enables it, and confirms the forum still serves.Build inputs pinned
redis(PECL)6.3.02.10.2+ signature checkinstall-php-extensionsredisis the one that bit:v1.0.0needed three attempts whilepecl.php.netreturned 504s. Pinning doesn't make PECL reliable, but it means a retry produces the same extension rather than whatever is newest by then.Composer was worse — the installer was piped straight into
php, unverified and unversioned, so two builds of the same commit could ship different Composer versions. Now pinned, with the signature check the Composer project publishes for exactly this.Tags name the forum
flarum-<version>, read from the committed lock, plus image labels. An image tag that only versions the wrapper can't answer the question users actually have — which Flarum is this? — and nothing else in the tag list ever would.