Helper scripts that ship with Vortex, the Drupal project template by DrevOps. They implement the host-side and in-container operations your project relies on.
This package is distributed via Composer as drevops/vortex-tooling and needs
to be added to your Drupal consumer project site.
composer require drevops/vortex-toolingOnce installed, you run the shipped scripts from
vendor/drevops/vortex-tooling/src/<script-name>.
Important
This repository is a read-only mirror of the
.vortex/tooling/
directory in the drevops/vortex
monorepo. Do not open issues or pull requests here. All development
happens in the parent repository.
| You want to | Go to |
|---|---|
| Report a bug | drevops/vortex/issues |
| Propose a change | drevops/vortex/pulls |
| Browse the source of truth | drevops/vortex/.vortex/tooling |
| Read the documentation | www.vortextemplate.com |
Each commit in this repository corresponds to a commit in the parent repository. The commit message body records the source commit SHA for provenance.
The provision script runs your own scripts after the core provisioning steps
complete (database import or profile install, database updates, configuration
import, cache rebuild, deployment hooks, and sanitisation). This is the
recommended way to add project-specific provisioning logic - enabling modules,
running migrations, seeding content, and so on - without touching the shipped
scripts.
Drop an executable script into your project's scripts/ directory, named with
the provision- prefix and the .sh extension. The provision script
discovers and runs every matching file in filename order; use a two-digit
number to sequence them (provision-10-..., provision-20-...).
The layout looks like this:
your-project/
├── .ahoy.yml
├── composer.json
├── scripts/
│ ├── provision-10-example.sh # shipped example - copy or remove
│ ├── provision-20-migration.sh # shipped example - copy or remove
│ └── provision-30-custom.sh # your own hook script
├── vendor/
│ └── drevops/vortex-tooling/src/provision # runs each provision-*.sh in order
├── web/ # Drupal web root
│ └── ...
└── ...
The template ships runnable examples you can copy or remove -
scripts/provision-10-example.sh
and
scripts/provision-20-migration.sh.
See the
provisioning documentation
for the full reference.
Reach for this only when extending provisioning is not enough - when you need to change how a shipped script itself behaves (alter a step it already runs, change a default, or fix something upstream that no post-provision hook can reach). It is the last resort.
The scripts are installed read-only into vendor/, so do not fork them or edit
them in place: those changes are lost on the next composer update. Instead,
apply a patch managed by
cweagans/composer-patches and
declared in your project's composer.json. The patch is re-applied
automatically whenever the package is installed or updated in your project, so
your customisation survives dependency updates and stays version-controlled
alongside the rest of your project.
The scripts are covered at two levels:
- Unit tests - BATS tests provide
full unit coverage of the scripts, with external commands mocked. They live
in
tests/in the source repository. - Integration tests - end-to-end coverage comes from the parent project that uses these scripts, Vortex. Its functional tests provision a real project and run the scripts to verify they work together.