Pantheon Cloud Integration Examples
This repo contains example scripts for use with Quicksilver Platform Hooks. These will allow you to automate more of your workflow, and integrate better with other cloud services.
The current release of Quicksilver supports one utility operation:
webphp. This invokes a PHP script via the same runtime environment as the website itself.
php scripts are subject to the same limits as any code on the platform, like timeouts, and cannot be batched.
This initial release makes four platform workflows eligible for Quicksilver operations:
deploy: when code is deployed to Test or Live.
webphpscripts run on the target environment.
sync_code: code is pushed via Git or committed in the Pantheon dashboard.
webphpscripts run on the committed-to environment (dev or multidev).
clone_database: data is cloned between environments.
webphpscripts run on the target (to_env) environment.
clear_cache: the most popular workflow of them all!
webphpscripts run on the cleared environment.
Quicksilver is configured via a
pantheon.yml file, which lives in the root of your repository (
~/code/). When this file is first pushed to an environment, it will set up the workflow triggers.
The format for
pantheon.yml is as follows:
# Always start with an API version. This will increment as Quicksilver evolves. api_version: 1 # Now specify the workflows to which you want to hook operations. workflows: deploy: # Each workflow can have a before and after operation. after: # For now, the only "type" available is webphp. - type: webphp # This will show up in output to help you keep track of your operations. description: Log to New Relic # This is (obviously) the path to the script. script: private/scripts/new_relic_deploy.php
Note that if you want to hook onto deploy workflows, you'll need to deploy your
pantheon.yml into an environment first. Likewise, if you are adding new operations or changing the script an operation will target, the deploy which contains those adjustments to
pantheon.yml will not self-referentially exhibit the new behavior. Only subsequent deploys will be affected.
When Updating: pantheon.yml: Updates will fire on the next sequential workflow, not post-deploy. scripts: Updates will fire post-deploy. script location: Updates will fire on next sequential workflow, not post-deploy.
When Adding: pantheon.yml: Updates will fire on the next sequential workflow, not post-deploy. scripts: Updates will fire on the next sequential workflow.
When getting started with Quicksilver scripts, you'll want to first create two
private directories on your website instance.
private directory should be created in your
~/files/ directory via SFTP (e.g.
~/files/private/). This directory is not included in your source code and is used to store a
secrets.json file where you can confidently store sensitive information like API keys and credentials. You will need to create a separate
private directory (and subsequent
secrets.json) for each environment as this directory isn't included in source and will not propagate during deployments. You can easily manage the key-value pairs in the
secrets.json file per environment (after initially creating the file via SFTP) using Terminus after installing the Terminus Secrets Plugin. The Slack notification example uses this pattern. For high-security keys, we recommend a third party secrets lockbox like Lockr.
private directory should be created in your project's web root (e.g.
~/code/web/private/ depending on the
web_docroot setting in your
pantheon.yml file). This
private directory is part of your repository, so it should not hold any sensitive information like API keys or credentials. Once you've created the
private directory, we recommend creating a
scripts directory within it to store all of your Quicksilver scripts.
Pantheon automatically limits public access to both of these
private directories, so no special configuration in
pantheon.yml is required. Scripts stored here can only be executed by the Pantheon platform.
Developers making use of Quicksilver will want to make sure they are Terminus savvy. Get the latest release, and a few new commands are included:
$ terminus help workflows ##NAME terminus workflows ##DESCRIPTION Actions to be taken on an individual site ##SYNOPSIS <command> ##SUBCOMMANDS list List workflows for a site show Show operation details for a workflow watch Streams new and finished workflows to the console
show commands will allow you to explore previous workflows and their Quicksilver operations. The
watch command is a developers best friend: it will set up Terminus to automatically "follow" the workflow activity of your site, dumping back any Quicksilver output along with them.
To discover what environment variables are available to your scripts then take a look at the debugging_example script and instructions.
- While your scripts can live anywhere, we recommend
privatesince that will prevent the contents from ever being directly accessed via the public internet.
- You'll know
pantheon.ymlhas been added correctly, and your quicksilver actions are registered when you see a message like the following on
remote: PANTHEON NOTICE: remote: remote: Changes to `pantheon.yml` detected. remote: remote: Successfully applied `pantheon.yml` to the 'dev' environment.