Fix Dev Center generator breaking on "x.y.0" releases, and ensure only whitelisted series are generated #671
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.
Fix matching of extension requirements against PHP series
There are two kinds of extensions: those bundled with PHP, and those that are separate packages.
The former come in two flavors: bundled and compiled in, or bundled and built as shared.
For compiled in extensions, entries are generated in the
replace
section of the PHP release they belong to.For shared extensions, standalone "virtual" packages are generated during repository generation. They will have a
require
entry for the exact PHP version they are bundled with, since they aren't really packages that get downloaded and installed, but instead only activated in their "parent" PHP package upon installation.As a result, the right package choices are made by the Composer solver during platform package installation.
For third-party extensions, the
require
entry forheroku-sys/php
does not specify an exact version, but a selector like "8.2.*
", since a build of e.g.ext-amqp
version 2.1.1 for PHP series 8.3 is compatible with all 8.3.x builds (due to PHP's extension API and ABI compatibility).This has evolved over time, and the Dev Center generator table only happened to be correct at this point due to the way the extension's requirements for
php
were matched against the known list of PHP series - an "8.2.*
" from a third-party extension would be satisfied by a series entry (those look like "8.2
"), but an8.2.15
would not match. However, "8.2.0
" would match "8.2
", and then all hell breaks loose in the internal database used during generation, and the output results are all over the place (built-in extensions showing up in the third-party list, third-party extensions listed as unavailable even if they're there, etc).This change corrects the loading of and metadata generation for bundled extensions.
GUS-W-14625659
Generate only whitelisted PHP series info
Instead of producing runtime rows, and extension columns, for PHP series that are not whitelisted, we throw a warning.
Now also prints a notice if a whitelisted runtime series isn't in the input (which can happen when e.g. only generating for a single stack, or when a stack goes EOL).
Optional
--strict
mode causes anexit(1)
if warnings are emitted. Useful in tests or workflows.GUS-W-14625693
Comparison of results before/after fixes
Ran against a repository that has PHP 8.3.0 and extensions for it.
PHP series "8.3" not on whitelist
Before
Note a column for 8.3 exists even though it's not whitelisted, but the extension version infos are missing:
After
No column generated for 8.3, and
WARNING: runtime series ignored in input due to missing whitelist entries: 8.3
was emitted tostderr
:PHP series "8.3" added to whitelist
Before
Note how suddenly, built-in extensions start showing up in the third-party extensions table, but only with version data for 8.3:
After
All is as it should be: