Bitbucket Pipelines

Setting up a repository to use with Pipelines. We’ll use State Licensure as an example. Click on Repository settings.

Click on Settings, then slide the toggle to Enable Pipelines

Click SSH Keys to enable communication with the server(s) you’ll be deploying your files to. Enter server name or i/p address then click Fetch. Once you see the returned Fingerprint, click Add Host.

Click Deployments to setup the environments you’ll be using. For this example, we’ll use Test and Production. We’ll see how it’s used in the file, bitbucket-pipelines.yml. You can add additional environments, if needed.

Click the down mark to expand the Test section. We’ll add two variables, SFTP_USER and SFTP_SERVER which will be referenced in the bitbucket-pipelines.yml file. You have the ability to secure the value, if needed.

Click the down mark to expand Production section. You can add the same variable names as in Test, if you want, to be consistent with the bitbucket-pipelines.yml file.

Example bitbucket-pipelines.yml file. This file should be put in the root directory of your files.

Reference Site: https://support.atlassian.com/bitbucket-cloud/docs/step-options/

Layout of file:

size: the minimum required is 4x. 4x and 8x pipelines size options are only available for builds running under a paid Bitbucket Cloud plan (Standard or Premium).

runtime: the runtime configuration to be applied to the step. Use cloud option. Set atlassian-ip-ranges to true.
** Only use the above option if you are deploying your code to a different server.

image: to use a different Docker image.

definitions: starts the YAML file by declaring that we will define steps below

steps: any number of steps or deployment options that will be defined below

step: a deployment option, like deploy-test or deploy-prod.

1. name: a name for the step or stage.

2. deployment: sets the environment for a deployment step or stage. It uses the variable setup in the Deployment step above.

3. script: the script run by the deployment options, containing “pipes” that allow for integration with other services. In the example to the right, we are using two pipes: an SSH and an SCP pipe. Atlassian provides other pipes as needed. Documentation is online.

pipe: list the name and version of the pipe being used, under which contains the variables that will be passed to the pipe. Please see Bitbucket's list of pipeline integrations for all pipe options

• The ssh-run pipe includes the required arguments, many of which should have been defined as variables described earlier. The COMMAND argument accepts the actual command that will be run by the pipe. In this case, we are issuing an rm -rfcommand for the /Apps/StateLicensure/* directory
  https://bitbucket.org/atlassian/ssh-run/src/master/

• The scp-deploy pipe includes similar arguments as the ssh-run pipe, but also requires a REMOTE_PATH and a LOCAL_PATH to be defined. Pipelines has a number of variables that need no definition, including $BITBUCKET_CLONE_DIR, which returns the absolute path of the repository directory.
  https://bitbucket.org/atlassian/scp-deploy/src/master/
  https://support.atlassian.com/bitbucket-cloud/docs/variables-and-secrets/

  • This pipe copies the contents of the entire repository into the /Apps/StateLicensure/ directory. We also pass an optional DEBUG variable of ‘true’ to enable better debugging in case an error is encountered

• Taken together, these two commands delete the content of the remote /Apps/StateLicensure/ directory on the test server and replace it with the repository contents.

pipelines: the start of the process

default: this step will run on any commit to any branch. If you only have one branch, master, it will run immediately after the commit. Using the example from above, it will run &deploy-test step.

custom: will run manually. This will run &deploy-production step from above.

Manually run the custom step. Click Run pipeline, select the Branch, then select default and click Run.

There are two variables set at the workspace for the SSH Key, if required to deploy to an external server as we did with Bamboo.

• $DEPLOY64_KEY is encoded.

• $DEPLOY_KEY is decoded.

Linting/error checking.

Linting/error checking is enabled for the YAML file if you are editing it on Bitbucket, but you might also want to copy and paste the complete contents of the YAML file into their pipelines validator. This will catch any errors and ensure that the YAML file contains valid structure.
https://bitbucket-pipelines.atlassian.io/validator