Run terminus self:info to confirm you are running the latest version before opening a new issue.
- Clone this Git repository on your local machine.
- Install Composer if you don't already have it.
- Install Box if not already installed.
- Run
composer installto fetch all the dependencies. - Run
./bin/terminus --helpto test that everything was installed properly.
Whether you want to fix a bug or implement a new feature, the process is pretty much the same:
- Search existing issues; if you can't find anything related to what you want to work on, open a new issue so that you can get some initial feedback.
- Fork the repository.
- Push the code changes from your local clone to your fork.
- Open a pull request.
It doesn't matter if the code isn't perfect. The idea is to get it reviewed early and iterate on it.
If you're adding a new feature, please add one or more functional tests for it in the tests/Functional/ directory. See below. Also, keep the documentation up-to-date by running:
cd /install/location/terminus
composer docsLastly, please follow PSR-2. You can test for conformance via:
cd /install/location/terminus
composer csThe PHP code beautifier can automatically fix a number of style issues. Run it via:
cd /install/location/terminus
composer cbfTerminus is built into a PHAR package using Box, which must be installed first.
From the root directory, build the package with:
composer build
This terminus.phar file is required to be built prior to running tests. Running the build will
first clear out dev dependencies that were added via composer install and those will need to be
reinstalled before continuing development.
Terminus uses functional tests implemented using PHPUnit
A .env file is required which can be based on .env.dist and must contain a site name for testing
which has a paid plan enabled for multidev, specify an environment to use for the tests, a user
account that owns that site, a machine token (TERMINUS_TOKEN) for that user, and an organization.
A PHAR file must also be built before running tests.
The functional test files are in the tests/Functional directory.
The Terminus 4.x functional tests can be run via:
cd /install/location/terminus
composer test:functionalThis will take some time to complete and will produce a report at the end with any failed or
skipped tests. To run a specific test, find the test's group in the comments above the test and
use the command specified in composer.json under test:functional with --group=<the-group>
Tests are grouped by short and long tests. The short tests are those that can be run in about a minute or less and are run by on every push. The long tests are those that take longer to run and are only run on merge.
In keeping with the standards of semantic versioning, backward-incompatible fixes are targeted to "major" versions. "Minor" versions are reserved for significant feature/bug releases needed between major versions. "Patch" releases are reserved only for critical security issues and other bugs critical to stabilizing the release.
After a new major version is released, previous major versions are actively supported for one year.
Our initial commitment will be to command compatibility and parameter compatibility. However, since on the command line STDOUT and STDERR are essentially APIs we will make a best effort to keep machine-readable output compatibility, meaning if your code interfaces with Terminus via --format=json or --format=bash formatting, we will try our best to ensure these are stable and compatible between minor release. However, changes to the STDOUT, like success and fail messages, should not be assumed to be compatible.
If you are using Terminus in a production environment, you should be deploying the executable for the latest release.
Ongoing development on the next planned release will be on the master branch and should not be considered stable, as changes will be taking place on a daily basis.
Writing for Terminus should be fun. If you find any of this hard to figure out, let us know so we can improve our process or documentation!