Integrated Composer
Custom Upstream Usage
Learn how to use an Upstream with Integrated Composer.
This section provides usage and maintenance information for composer-managed Custom Upstreams on Pantheon, including steps to add upstream dependencies.
Custom Upstreams
An Upstream refers to the source code in Git that shares a Git history with "downstream" individual sites made from it. Upstreams includes the core code for Drupal, WordPress, and some customizations for the Pantheon platform.
Create Your Integrated Composer Custom Upstream
Follow the steps to Create a Custom Upstream to create and connect a new integrated composer custom upstream.
Custom Upstream and Site Structure
The upstream has the following directory structure:
.gitignore: Prevents build artifacts generated by Composer from being committed to the upstream or site code repositories. Note that changing the tracking status of Composer-managed files and directories can result in build failures or lead to unexpected errors.composer.json: The two differentcomposer.jsonfiles allows you to customize individual sites without inherent merge conflicts and enables one-click updates.- Root-level: Site-level customizations.
upstream-configuration/: Composer automatically updatescomposer.jsonwith customizations for the upstream. Avoid manually modifying this file.
pantheon.upstream.yml: Thebuild_step: truedirective inpantheon.upstream.ymlenables the build step.
When a site is created, Pantheon runs composer install, generates a composer.lock file, and commits it back to the site’s code repository. To avoid potential merge conflicts after applying an upstream update, do not commit the composer.lock file from your upstream root to the upstream repository.
The composer.lock file should not be listed in your .gitignore file because it must be committed for individual sites created from your custom upstream. Use the command below to avoid accidentally committing a composer.lock file when working directly with your custom upstream.
The command has the same effect as ignoring the file in the top-level .gitignore file, except that the exclude file is not saved in the repository when you push changes back to the remote origin. You must re-run this command every time you make a new local clone of your upstream if you would like to protect against inadvertently committing a composer.lock file.
Build artifacts are stored in a Git tag like pantheon_build_artifacts_$BRANCHNAME, where $BRANCHNAME is the name of the environment or Multidev feature branch.
It is a requirement that all build artifacts should be ignored in the .gitignore file. Ensure you add entries to the .gitignore any time you modify the build to move installation files to a new locations.
Add Dependencies to Your Upstream
-
Clone the Git repository for your Custom Upstream.
-
Require the Custom Upstream management package if you have not already:
-
Run the
composer upstream:requirecommand for each dependency: -
Commit and push your changes to your
composer.jsonfile. Remember to not commit thecomposer.lockfile.The
composer.lockfile should not be added to your.gitignorefile, since it must still be committed for individual sites created from your Custom Upstream. Instead, run the following command to prevent yourself from accidentally committing it while working directly in the Custom Upstream repository:
Update Dependencies in Your Upstream
You may need to pin specific versions of your dependencies in your Custom Upstream. This is normally done with the composer.lock file. However, including the composer.lock file in the root of the Custom Upstream causes merge conflicts with your downstream sites. You can use the upstream:update-dependencies composer command to solve this problem.
-
Run
composer update-upstream-dependenciesin your custom upstream repository. Theupstream:update-dependenciescommand will:-
Create or update a
upstream-configuration/composer.lockfile. -
Create or update a
upstream-configuration/locked/composer.jsonfile with all packages fromcomposer.lockand their pinned versions. -
Update the top-level
composer.jsonrepositories section forupstream-configurationto useupstream-configuration/lockedinstead of justupstream-configuration(if not done previously).
-
-
Commit the changes and begin using the pinned versions in your downstream sites. This allows you to make sure that you use specific versions for the packages in your Custom Upstream.
Add a Composer Plugin to Your Upstream
Composer loads plugin code once, when Composer starts, from the vendor directory that is on disk at that moment. A plugin that arrives in the same upstream update that first needs it is not installed yet, so it does not run.
Add the plugin to your upstream in one release, then run an upstream update on all sites created from that upstream. Once the plugin is deployed everywhere, add the change that uses it in a later release. The example below uses mglaman/composer-drupal-lenient, which relaxes a contributed module's published drupal/core constraint so that the module can install on a newer version of Drupal core.
config and repositories are root-only properties. Composer reads them from the root composer.json and nowhere else, so a plugin added to upstream-configuration/composer.json has no effect.
-
In the root
composer.jsonof your Custom Upstream, require the plugin and add it to theallow-pluginslist: -
Commit and push this release to your Custom Upstream, then apply the upstream update to each site and let the build finish.
-
Confirm that the plugin is installed before you rely on it. Connect to an environment over SFTP and list the vendor directory:
-
In a later upstream release, add the change that depends on the plugin. For
composer-drupal-lenient, that is the module itself inupstream-configuration/composer.json:Along with an
extra.drupal-lenient.allowed-listentry in the rootcomposer.jsonthat names the same module: -
Apply the upstream update to your sites again. Composer now loads the plugin from
vendorand resolves the module.
A change to the root composer.json in your Custom Upstream replaces edits that individual sites have made to their own root composer.json. This happens without a merge conflict and without failing the build. Review your sites for local changes before you push. For more information, see Changes Lost During Upstream Updates.
Maintain Your Integrated Composer Custom Upstream
There are some special considerations to keep in mind if you intend to make modifications to your upstream based on this repository.
-
Increase the version number listed in the
upstream-configuration/composer.jsonfile each time you make edits.- Composer checks the contents of the root
/composer.jsonfile for changes that should be pushed to your upstream configuration.
- Composer checks the contents of the root
-
Verify your changes to the
upstream-configuration/composer.jsonfile by runningcomposer installorcomposer updatein theupstream-configurationdirectory.- Be careful not to rely on "root-only" properties of composer.json.