consolidation / 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.
Installs: 32 803 103
Dependents: 6
Suggesters: 0
Security: 0
Stars: 50
Watchers: 6
Forks: 19
Open Issues: 10
Requires
- php: >=8.0.14
- consolidation/config: ^2 || ^3
- consolidation/site-alias: ^3 || ^4
- symfony/console: ^5.4 || ^6 || ^7
- symfony/process: ^6 || ^7
Requires (Dev)
- dev-main / 5.x-dev
- 5.4.2
- 5.4.0
- 5.3.0
- 5.2.0
- 5.1.1
- 5.1.0
- 5.0.0
- 4.x-dev
- 4.2.1
- 4.2.0
- 4.1.3
- 4.1.2
- 4.1.1
- 4.1.0
- 4.0.0
- 4.0.0-alpha1
- 2.x-dev
- 2.1.0
- 2.0.4
- 2.0.3
- 2.0.2
- 2.0.1
- 2.0.0
- 2.0.0-beta6
- 2.0.0-beta5
- 2.0.0-beta4
- 2.0.0-beta3
- 2.0.0-beta2
- 2.0.0-beta1
- 1.1.2
- 1.1.1
- 1.1.0
- 1.0.0
- 0.3.1
- 0.3.0
- 0.2.0
- 0.1.19
- 0.1.18
- 0.1.17
- 0.1.16
- 0.1.15
- 0.1.14
- 0.1.13
- 0.1.12
- 0.1.11
- 0.1.10
- 0.1.9
- 0.1.8
- 0.1.7
- 0.1.6
- 0.1.5
- 0.1.4
- 0.1.3
- 0.1.2
- 0.1.1
- 0.1.0
- dev-test-on-8.4
- dev-larowlan-symfony7
- dev-site-alias-4-for-4.x
- dev-bump-site-alias
- dev-symfony-6
- dev-fix-bindto
- dev-terse-exception
- dev-php-8.1
- dev-enable-bc-check
- dev-php-8
- dev-terse
- dev-symfony5
- dev-symfony-4
- dev-better-json-error-reporting
- dev-add-transports
- dev-code-cleanup
- dev-site-alias-with-config
- dev-fix-json-cleanup
- dev-appveyor
- dev-config-aware
- dev-lessWin
- dev-unOS
- dev-inject-config
- dev-true
- dev-process-from-transport
- dev-transport-manager
- dev-deps/update-a40b2665
- dev-test-scenarios-3
- dev-deps/update-39079f79
- dev-site-alias-lowest
- dev-sdterr-marker-on-every-line
- dev-php5
- dev-command-specific
- dev-ProcessBase
This package is auto-updated.
Last update: 2024-12-13 19:26:20 UTC
README
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.
Overview
Site Process is 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.
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:
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:
local: uri: http://localhost vagrant:
Docker Compose
Wraps a command so that it runs on a remote system via docker-compose.
Example:
local: host: localhost uri: http://localhost docker: service: drupal compose: version: 1 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
docker.compose.version
defaults to 1
. Set to 2
to use the new syntax:
docker compose --project dockerComposeProjectName --file docker-compose.yml --project-directory dockerComposeWorkDir exec --user www-data -T drupal
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 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:
Deployment
- Run
composer release
Contributing
Please read CONTRIBUTING.md for details on the process for submitting pull requests to us.
Versioning
We use SemVer for versioning. For the versions available, see the releases page.
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
See also the list of contributors who participated in this project.
License
This project is licensed under the MIT License - see the LICENSE file for details
Acknowledgments
- Thanks to PurpleBooth for the example README template