# Site Process A thin wrapper around the Symfony Process Component that allows applications to use the Site Alias library to specify the target for a remote call. [![ci](https://github.com/consolidation/site-process/workflows/CI/badge.svg)](https://travis-ci.org/consolidation/site-process) [![scrutinizer](https://scrutinizer-ci.com/g/consolidation/site-process/badges/quality-score.png?b=master)](https://scrutinizer-ci.com/g/consolidation/site-process/?branch=master) [![codecov](https://codecov.io/gh/consolidation/site-process/branch/main/graph/badge.svg?token=CAaB7ofhxx)](https://codecov.io/gh/consolidation/site-process) [![License](https://img.shields.io/badge/license-MIT-408677.svg)](LICENSE) ## Overview Site Process is a thin wrapper around the [Symfony Process Component](https://symfony.com/doc/3.4/components/process) that allows applications to use the [Site Alias library](https://github.com/consolidation/site-alias) to specify the target for a remote call. For comparison purposes, the `Process` object may be created to run an application on the local system using the standard Symfony Process Component API like so: ``` $process = new Process(['ls', '-lsa']); ``` Similarly, a remote call can be done using the general-purpose `SiteProcess` API, which is accessible via the ProcessManager object: ``` $processManager = ProcessManager::createDefault(); $process = $processManager->siteProcess($site_alias, ['ls', '-lsa', '{root}']); ``` In this example, if `$site_alias` represents a site on the same system, then the `ls -lsa` command will run locally. If, on the other hand, it represents a remote site, then the `ls -lsa` command will be wrapped in an ssh call to the remote system. In either case, the `{root}` reference will be replaced with the value of the attribute of the site alias named `root`. An exception will be thrown if the named attribute does not exist. Options may also be specified as an associative array provided as a third parameter: ``` $process = $processManager->siteProcess($site_alias, ['git', 'status'], ['untracked-files' => 'no']); ``` This is equivalent to: ``` $process = $processManager->siteProcess($site_alias, ['git', '--untracked-files=no', 'status']); ``` ### Transports #### SSH Wraps a command so that it runs on a remote system via the ssh cli. Example: ```yaml local: host: localhost uri: http://localhost ssh: options: -o PasswordAuthentication=no -i $HOME/.ssh/id_rsa ``` ### Vagrant Wraps commands so they run with `vagrant ssh -c`. Example: ```yaml local: uri: http://localhost vagrant: ``` #### Docker Compose Wraps a command so that it runs on a remote system via docker-compose. Example: ```yaml local: host: localhost uri: http://localhost docker: service: drupal compose: options: --project dockerComposeProjectName --file docker-compose.yml --project-directory dockerComposeWorkDir exec: options: --user www-data ``` The above would execute commands prefixed with: ``` docker-compose --project dockerComposeProjectName --file docker-compose.yml --project-directory dockerComposeWorkDir exec --user www-data -T drupal ``` `docker.project` and `compose.options --project` do the same thing, docker.project existed before options. `docker.service` is the exact name of the service as it appears in docker-compose.yml The default behaviour is to use `docker-compose exec` to invoke a command on a running container. You can change this to use `docker-compose run` for containers which by default are not running, with the property `compose.command`. Check the [docker-compose](https://docs.docker.com/compose/reference/overview/) manual for all available options. #### Local Runs the command on the local system. ## Running the tests The test suite may be run locally by way of some simple composer scripts: | Test | Command | ---------------- | --- | Run all tests | `composer test` | PHPUnit tests | `composer unit` | PHP linter | `composer lint` | Code style | `composer cs` | Fix style errors | `composer cbf` ## Deployment - Run `composer release` ## Contributing Please read [CONTRIBUTING.md](CONTRIBUTING.md) for details on the process for submitting pull requests to us. ## Versioning We use [SemVer](http://semver.org/) for versioning. For the versions available, see the [releases](https://github.com/consolidation/site-process/releases) page. | Branch | Symfony Versions | PHP Versions | ------------ | ---------------- | ------------ | main (5.x) | ^5 | ^6 | 8.0+ | 4.x | ^4 | 7.1+ | 2.x | ^2 | ^3 | 5.6+ Note that all 3.x releases of consolidation/site-process were skipped simply to align the 4.x versions with Symfony 4.x support. Note that the API of consolidation/site-process itself is compatible between the 2.x and 4.x versions, so most clients that work with both Symfony 3 and Symfony 4 should be able to require `"consolidation/site-process": "^2 | ^4"` without problems. ## Authors * [Greg Anderson](https://github.com/greg-1-anderson) * [Moshe Weitzman](http://weitzman.github.com) See also the list of [contributors](https://github.com/consolidation/site-process/contributors) who participated in this project. ## License This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details ## Acknowledgments * Thanks to PurpleBooth for the [example README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2)