Feat: Add support for additional metapackages (closes #238) #271
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.
Resolves #238
Overview
Substantial refactor replacing hardcoded metapackage flags with flexible configuration system.
Key Changes
Configuration Architecture
magentoCommunityEditionProjectandmagentoCommunityEditionMetapackagefromrepositoryBuildDefinitionextraMetapackagesarray accepting metapackage definitions with:name,type(project/metapackage),descriptionfromTag(optional starting version)transform[](array of transformation functions)Refactored Methods
Eliminated specialized functions:
createMagentoCommunityEditionMetapackage()createMagentoCommunityEditionProject()createProjectPackagesSinceTag()createMagentoCommunityEditionMetapackagesSinceTag()Replaced with generic
createMetaPackagesSinceTag()that iteratesextraMetapackages[]Transform Functions
New dedicated modules for composition-based transforms:
src/build-metapackage/magento-community-edition.jstransformMagentoCommunityEditionProject()transformMagentoCommunityEditionProduct()src/build-metapackage/mage-os-community-edition.jstransformMageOSCommunityEditionProject()transformMageOSCommunityEditionProduct()Transforms now async, called sequentially:
for (const fn of metapackage.transform) { composerConfig = await fn(...); }Configuration Examples
packages-config.js (Magento):
mageos-release-build-config.js (Mage-OS - chained transforms):
Context Propagation
releaseContext(buildState withcomposerRepoUrl) now passed toprocessMirrorInstruction()and downstreamsetMageosPackageRepoUrl()in favor of explicit contextHistorical Data
Added
magento_versionto Mage-OS product metapackage history files for upstream reference tracking.Benefits
createMetaPackagesSinceTag()handles all metapackagesAdditional notes
Build issues
In the process of refactoring and testing, I found some issues with the prior build setup that this fixes.
projectpackages weren't being given the proper separate description to match upstreammagento/magento2-baserequirement version tonull; it now properly matches the release versionmagento_versionin theproductcomposer.json for reference info, but historical Mage-OS versions have not, meaning each new release removed the info from the prior one. That'll no longer be the case. I added it to the release history file, and set it to copyextradata in too if present.Adding metapackages
The ultimate point of this was to be able to add more metapackages to the Mage-OS release process, as situations may warrant.
At least for now, I opted to do it via transform functions, rather than some system of include or exclude or add lists.
This is limited to changes to project and product composer files. If we want different code for one versus another, it would require a separate fork or bigger changes where packages are actually built.
I tested with these added metapackages, purely for demonstration: