ORCA doesn't install dev dependencies because Composer provides no means of doing so--Composer only recognizes dev dependencies of the root package, which in ORCA's case is the project template. But even if technically possible it would be undesirable on account of the resulting strict but indirect dependency it would create between product teams since a standard fixture would then require the dev dependencies of all packages at once. Two main approaches are available to deal with this limitation:
-
For conditional functionality (i.e., behavior that manifests only in the presence of dependencies, such as optional Drupal modules), move the functionality into a submodule and require those conditions in its
composer.json
. ORCA will automatically discover the submodule and install the dependencies with Composer. This design may be considered an expression of the Common Reuse Principle (CRP) of package cohesion, in which sense the "no dev dependencies" limitation actually encourages good system design. -
Invoke
composer require
manually in your.orca.yml
(or in a script called by it) to add the dependency after it's created, e.g.:install: - ../orca/bin/ci/install.sh # Add the physical dependency to the codebase. - cd "$ORCA_FIXTURE_DIR" - composer require drupal/dev_only_dependency # Install Drupal modules and themes. - cd docroot - ../vendor/bin/drush pm:enable -y dev_only_dependency # Backup the fixture state for ORCA's automatic resets between tests. - ../../orca/bin/orca fixture:backup -f
-
Simply "ignore" tests with unique dependencies and run them apart from ORCA. See Running automated tests.
As an opinionated project template, Acquia CMS (drupal/acquia_cms
) has very tight version constraints that can conflict with your dependencies as depicted in this example error:
Problem 1
- acquia/acquia_cms[v1.2-rc1, ..., 1.2.5.x-dev] require drupal/acquia_connector ^3 -> satisfiable by drupal/acquia_connector[dev-3.x, 3.0.0-rc1, ..., 3.x-dev (alias of dev-3.x)] from composer repo (https://packages.drupal.org/8) but drupal/acquia_connector[dev-8.x-1.x, 1.x-dev (alias of dev-8.x-1.x)] from path repo (/home/runner/build/acquia/acquia_connector) has higher repository priority. The packages with higher priority do not match your constraint and are therefore not installable. See https://getcomposer.org/repoprio for details and assistance.
Acquia CMS is included in ORCA test fixtures by default by way of a requirement in Acquia Drupal Recommended Project. If your package or one of its version branches is not meant to support Acquia CMS, you should use a different project template. Add the following to your .orca.yml
to do so on GitHub Actions:
env:
global:
- ORCA_FIXTURE_PROJECT_TEMPLATE=acquia/drupal-minimal-project
ORCA supports testing using any actively-maintained version of Drupal core, as specified by the Drupal core release policy.
ORCA automatically discovers and enables any subextension that satisfies the following criteria:
- It exists in a subdirectory of a present package (other than
tests
). - It has a valid
composer.json
...- with a
type
value ofdrupal-module
ordrupal-theme
... - and a vendor name of "drupal", i.e., a
name
value beginning withdrupal/
.
- with a
- It has a corresponding
.info.yml
file (e.g., for a Composername
ofdrupal/example
,example.info.yml
). - It doesn't explicitly opt out. See How can I prevent ORCA from enabling my submodule/subtheme?.
Cf. \Acquia\Orca\Fixture\subextensionManager
.
To prevent ORCA from enabling a subextension, add an extra.orca.enable
value of TRUE
to its composer.json
, e.g.:
{
"name": "drupal/example_submodule",
"type": "drupal-module",
"extra": {
"orca": {
"enable": false
}
}
}
Cf. Why doesn't ORCA enable my submodule/subtheme?.
README | Understanding ORCA | Getting Started | CLI Commands | Advanced Usage | Project Glossary | FAQ | Contribution Guide