Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Dev Center generator breaking on "x.y.0" releases, and ensure only whitelisted series are generated #671

Merged
merged 3 commits into from
Dec 7, 2023

Conversation

dzuelke
Copy link
Contributor

@dzuelke dzuelke commented Dec 7, 2023

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 for heroku-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 an 8.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 an exit(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:

tpe-missing

After

No column generated for 8.3, and WARNING: runtime series ignored in input due to missing whitelist entries: 8.3 was emitted to stderr:

tpe-82

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:

tpe-broken

After

All is as it should be:

tpe-83

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 for `heroku-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 an `8.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
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).

GUS-W-14625693
Causes an exit(1) if warnings are emitted. Useful in tests or workflows.

GUS-W-14625693
@dzuelke dzuelke requested a review from a team as a code owner December 7, 2023 16:41
Copy link
Member

@joshwlewis joshwlewis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great PR description and great code comments!

@dzuelke dzuelke merged commit 44801c0 into main Dec 7, 2023
4 checks passed
@dzuelke dzuelke deleted the devcenter-generator-fixes branch December 7, 2023 18:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants