The deployment environment 'test' in your bitbucket-pipelines.yml file occurs multiple times

glamit_dorquin

I'm new to Bitbucket pipelines and maybe I don't understand the concept very well yet. My use case is the following:

We have a testing environment, let's call it UAT. I want all branches that aren't master to be deployed to this Lambda testing environment OPTIONALLY (hence the manual trigger).

For our production environment, I want master to be verified and then deployed to Lambda production.

I also want ALL branches, including master, to be verified before proceeding to the next step.

I made use of some deployment variables because configurations obviously change between test and production.

 

My bitbucket-pipelines.yml looks like this:

image: maven:3.6.1

definitions:
caches:
mvnrepo-build: /root/.m2/repository
steps:
    - step: &mvn-verify
        name: Maven verify
caches:
          - maven
script:
          - echo $FLYWAY_CONFIG > src/main/resources/flyway.conf
          - tr ' ' '\n' < src/main/resources/flyway.conf > src/main/resources/temp.txt && mv src/main/resources/temp.txt src/main/resources/flyway.conf
          - mvn -B verify
    - step: &lambda-deploy
        caches:
          - mvnrepo-build
script:
          - echo $CONFIG_FILE > src/main/resources/config.xml
          - echo $FLYWAY_CONFIG > src/main/resources/flyway.conf
          - tr ' ' '\n' < src/main/resources/flyway.conf > src/main/resources/temp.txt && mv temp.txt src/main/resources/flyway.conf
          - mvn -B clean install
          - pipe: atlassian/aws-lambda-deploy:0.4.2
variables:
AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
AWS_DEFAULT_REGION: $AWS_DEFAULT_REGION
FUNCTION_NAME: $FUNCTION_NAME
COMMAND: 'update'
              ZIP_FILE: 'target/vtex.jar'
pipelines:
default:
    - step:
<<: *mvn-verify
        deployment: test
    - step:
<<: *lambda-deploy
        name: Deploy to UAT
deployment: test
trigger: manual
branches:
master:
      - step:
<<: *mvn-verify
          deployment: production
      - step:
<<: *lambda-deploy
          name: Deploy to Prod
deployment: production

In each of the deployment environments, mvn-verify needs values according to its environment, that's why I added deployment: {{environment}} to each step.

However, even though the yml file itself is valid, Bitbucket won't even start to run the pipeline and output the error in the title.

glamit_dorquin

I found a solution that matches what I'm trying to do. Here's the bitbucket-pipelines.yml that I came up with. Creating new environments was required.

 

Test-Verify

This one has the configuration file as a variable that I need for the Maven verification step.

Test-Lambda

This one has the Lambda Function name for the Test environment.

 

Production-Verify

This one has the configuration file as a variable that I need for the Maven verification step.

Production-Lambda

This one has the Lambda Function name for the Production environment.

 

There's also an additional mandatory first step at the beginning where I take the opportunity to load up all the necessary configurations (using deployment variables) and save them as artifacts to be used in the following steps.

 

image: maven:3.6.1

definitions:
caches:
mvnrepo-build: /root/.m2/repository
steps:
    - step: &load-configurations
        name: Load configurations
script:
          - mkdir configurations
          - echo $FLYWAY_CONFIG > configurations/flyway.conf
          - tr ' ' '\n' < configurations/flyway.conf > configurations/temp.txt && mv configurations/temp.txt configurations/flyway.conf
          - echo $CONFIG_FILE > configurations/config.xml
artifacts:
          - configurations/**
    - step: &mvn-verify
        name: Maven verify
caches:
          - maven
script:
          - cat configurations/flyway.conf > src/main/resources/flyway.conf
          - cat configurations/config.xml > src/main/resources/config.xml
          - mvn -B verify
    - step: &lambda-deploy
        caches:
          - mvnrepo-build
script:
          - cat configurations/flyway.conf > src/main/resources/flyway.conf
          - cat configurations/config.xml > src/main/resources/config.xml
          - mvn -B clean install
          - pipe: atlassian/aws-lambda-deploy:0.4.2
variables:
AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
AWS_DEFAULT_REGION: $AWS_DEFAULT_REGION
FUNCTION_NAME: $FUNCTION_NAME
COMMAND: 'update'
              ZIP_FILE: 'target/vtex.jar'
pipelines:
default:
    - step:
<<: *load-configurations
        deployment: test-verify
    - step: *mvn-verify
    - step:
<<: *lambda-deploy
        name: Deploy to UAT
trigger: manual
deployment: test-lambda
branches:
master:
      - step:
<<: *load-configurations
          deployment: production-verify
      - step: *mvn-verify
      - step:
<<: *lambda-deploy
          name: Deploy to Prod
deployment: production-lambda

 

I know this maybe isn't the most elegant solution and perhaps it's not even conceptually correct, but it works. Regardless, I'm open to feedback and corrections.