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.

[ozbillwang]

I saw the same error as well, it looks like a bug for me. 

  default:
    - step:
        <<: *mvn-verify
        deployment: test
    - step:
        <<: *lambda-deploy
        deployment: test
        trigger: manual

How could we report this issue to Atlassian?

[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.

[JPadda]

You can store your Environment specific variables in an artifact in the initial step and then use that file to retrieve those variables in the next steps.

[ozbillwang]

normally we saved secrets, such as api key, in deployment, we don't want it to be saved as artifact, it can be exposed easily.