Allow installing a specific blackfire version#1289
Open
Teko012 wants to merge 1 commit into
Open
Conversation
Contributor
Author
|
The pipeline failure seems to be unrelated |
Contributor
Author
|
@mlocati What do you think about this? |
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
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.
Currently,
install-php-extensions blackfirealways fetches the latest Blackfire PHP probe from the public API endpoint:There is no way to pin the installed probe to a specific Blackfire version, which means rebuilding the same Dockerfile at different points in time can yield different probe versions — making builds non-reproducible and breaking environments that need to match a specific Blackfire agent version.
This PR adds support for selecting a specific Blackfire probe version using the standard
install-php-extensions <ext>-<version>syntax that the script already supports for other extensions, e.g.:Implementation
When a version is supplied, the URL passed to
curlis switched from the "latest probe" API endpoint to the official versioned tarball hosted on Blackfire's package CDN:Concretely, in the
blackfire)branch ofinstallRemoteModule():installRemoteModule_urlvariable is set conditionally:installRemoteModule_versionis empty → the existingblackfire.io/api/v1/releases/probe/php/...URL (unchanged behavior).packages.blackfire.io/binaries/blackfire-php/<version>/...URL.curl ... | tar xzinvocation now consumes"$installRemoteModule_url"instead of the hardcoded API URL.The existing
$installRemoteModule_distro(alpine/linux),$installRemoteModule_tmp1(amd64/arm64/i386) and$installRemoteModule_tmp2(PHP major+minor, optionally-zts) variables are reused for both URL shapes, so architecture, distro and ZTS detection logic is shared between the unversioned and versioned code paths.Backwards compatibility
Behavior of
install-php-extensions blackfire(no version) is unchanged — the same API endpoint is hit and the same probe (latest) is installed. Only the newblackfire-<version>form exercises the new code path.