- About redeployment hooks
- Adding Redeployment Hooks
- Invoking your redeployment hook manually
About redeployment hooks
Redeployment hooks allow you to achieve continuous deployment by deploying your stack when you push a change to your Git repository or have a CI push success. Redeployment hooks differ slightly for Rails/Rack and Docker Stacks see sections below.
Where to find your redeployment hook?
Your redeployment hook URL is automatically generated for each of your stacks. You can find your unique redeployment hook URL on your stack information page (available via the settings & information link on the main stack page's right hand navigation menu)
For Docker Stacks
Docker Stacks can have multiple services which can rely on a combination of either Image or Git sources. Furthermore, the Git sources can be the same or different branches, or even completely different repositories. To handle this, we have introduced and addition services modifier that can be appended to the redeployment hook to specify which services to redeploy (the services modifier is a query string parameter).
When a redeployment hook is invoked:
- If the commit hook payload includes Git information (Git source, branch and/or reference) then we will attempt to find a matching service on your stack that corresponds to the above information. If there is a match then we will deploy only the services that have a Git type (not the Image based services). Note that the matching service will also build based on the Git ref that is present in the payload.
- If the commit hook payload does not include Git information, then we will automatically redeploy all services defined on your stack.
- If you use the services modifier to specify which specific services you want to deploy when the commit hook is invoked, then the same logic applies as in 1) and 2) above, the only difference being that we will always deploy the services you have specified if deployment will occur.
Some examples below will illustrate how to add a services modifier. Note that the xxxx/yyyy in the examples is for illustrative purposes only and should be replaced with your redeployment URL on your stack information page. An example redeployment hook without a services modifier:
An example redeployment hook with a single services modifier:
An example redeployment hook with a many-service modifier:
For Rails/Rack Stacks
All Rails/Rack Stacks are based on a Git repository and branch. Pushing code to the same branch as your stack Git branch will invoke your stack redeployment. If you push code to another branch, nothing will happen - this allows you to push code to your development branch without an automatic redeploy on your production stack for example. If it is available in the payload, the Git Ref of the latest commit will be used for the stack redeployment.
In the case where the payload of the commit hook does not contain any branch information (Github and Bitbucket payload formats are supported) then the stack will redeploy without attempting to match branch
Users who have signed in through Github (and who have enough access to create and edit deployment events for their stacks on GitHub) can activate continuous deployments on GitHub. To do this: access your Stack settings via the toolbelt and set continuous.deploy to true.
$ cx settings set -s my_stack continuous.deploy true
This will create a new webhook for your repository on GitHub or simply modify and existing one to let Cloud66 receive deployment events as well.
With this feature enabled, whenever you push new commit, Cloud 66 will automatically generate a new deployment event based on receiving the push event from GitHub. We will also send deployment status events on different deployment statuses, such as started, cancelled, succeeded and failed.
For more information please refer to the Github Deployment API.
Adding Redeployment Hooks
The process of adding the hook differs by your Git host, so we will guide you through doing this with GitHub, Bitbucket and a generic solution.
On your stack detail page, click Stack information in the right sidebar and copy the URL provided in the Redeployment hook field. Next, visit your GitHub repository, click Settings in the right sidebar, and then Webhooks & Services in the left sidebar.
In the Webhooks window, click Add webhook and paste the redeployment hook URL into the Payload URL field. When you confirm by clicking Add webhook, GitHub will automatically test your hook with a Ping and you should get a green HTTP200 response.
On your stack detail page, click Stack information in the right sidebar and copy the URL provided in the Redeployment hook field. Next, visit your Bitbucket repository, click Settings in the left sidebar, and then Hooks in the settings menu that appears. In the Select a hook field, select a POST hook, click Add hook and paste your redeployment hook URL into the field provided. Click Save to confirm.
Most Git providers have a commit hook mechanism that you can use to post to the Cloud 66 redeployment hook URL. Please check your Git provider documentation for this information. If your Git provider has a non-conforming payload format (not compatible with Github or BitBucket formats) then please get in touch and we can extend our payload support!
Invoking your redeployment hook manually
To invoke the redeployment hook manually, you can POST an HTTP request to your redeployment hook URL. You can do this in curl like this:
curl -X POST [your redeployment hook URL]
If you are manually invoking redeployments you should consider using the Cloud 66 CommandLine Tool instead, as it has additional features!