Deploy CloudFormation Template From Bitbucket Repository

The workflow allows you to launch a CloudFormation Stack containing the code that you commit each time to your Bitbucket Repository.

The Workflow

Setting Up Webhook On Bitbucket

For the workflow to be triggered every time a new push to the Bitbucket repository happens, we must configure a webhook.

  • Open your repository on Bitbucket

  • Go to Repository settings --> Webhooks --> Add Webhook

  • Paste the URL that is generated when activating the HTTP trigger of the TotalCloud workflow

  • Create the Webhook

Getting The Bitbucket Username And App Password For HTTP Node

  • On Bitbucket, go to Settings --> Personal Settings (on the bottom left corner)

  • App passwords --> Create app password --> Check Pull requests - read, and create the app password, and copy it. This will be used in the HTTP Node.

For the Username,

  • Go to Settings --> Personal Settings

Updating Bitbucket Details In The Workflow

  • Edit the HTTP Node (second node)

  • For the endpoint URL enter: https://api.bitbucket.org/2.0/repositories/<org_or_username>/<repo_name>/src/master/<cloudformation_template_filename>

  • For Basic Auth - Username and Password, enter what you have just got from Bitbucket in the previous steps

Validating the Push To The Repository

  • You can also set validations for when you want the actions to be carried out

  • The workflow is triggered every time there is a commit to the Bitbucket Repository

  • The commited code is then tested against the validation given in the Variables section

  • Once the validation passes, a CloudFormation Stack is launched using the code that is committed

Here are a few examples of how you can use the validation:

  • Case 1: For a specific Instance type and for all CidrIp values except one

    • Here the validations are for if the InstanceType is t2.small and if the CidrIp is not 0.0.0.0/0

    • If either of these two, or any other validation added fails, the CloudFormation Stack will not be launched, and you will get an error describing the reason for the failure

  • Case 2: For any of the Instance types in a set of values, and for all CidrIp values except one

    • For the workflow to validate, the Instance type can be either t2.small or t2.micro and the CidrIp value can be anything other than 0.0.0.0/0

  • Case 3: For any of the Instance types in a set of values, and for a specific CidrIp value

    • For the workflow to validate, the Instance type can be either t2.small or t2.micro and the CidrIp value has to be 172.16.16.1

Choosing Whether The CloudFormation Stack Is Created/Updated

There are two Action Nodes in the Workflow - one is to create a CloudFormation Stack, and the other is to update an existing Stack

  • The first will happen if there is no existing stack with the name given in the Variables section under validation

  • If there is an existing stack, the create action is skipped, and instead an update stack occurs

When you open the first "Create Stack" action node, and click on Set Conditional, you can see the parameter used to decide whether the Node should execute or not

  • The node will parse through the list of Stacks returned by the CloudFormation Stacks Resource Node. If there exists a CloudFormation stack with the name set in the Variables section, it will skip this create Stack and move onto updating the Stack

  • The opposite of this condition is set in the Update Stack Action Node

Using The Workflow

  • Once the workflow is saved and deployed, it will be triggered every time there is a push to the Bitbucket repository

  • After the push, the CloudFormation template is validated, and then the CloudFormation Stack using the template is launched

  • The launched resources are then presented to the User in a report format: