Trigger your E2E tests from another repo's Bitbucket Pipeline build

There are two school of thoughts on whether End-to-end (E2E) tests should be on same repository or on a separate repository. If its taking you weeks or months to debate on that with your team, then there could be a middle-ground 🤠.

If there is a separate team / resource working on the E2E tests and another team / resources working on the source code, then how about a compromise to make it work? This is by simply triggering the E2E tests on any changes made in the source code.

This is highly possible by using Atlassian's Pipe - trigger pipeline.

On the application / source code's bitbucket-pipeline.yml file, simply add the following as a step:

    - step: &run-automated-tests
        name: Run E2E and API automated tests
        script:
          - pipe: atlassian/trigger-pipeline:4.2.1 # https://bitbucket.org/product/features/pipelines/integrations?p=atlassian/trigger-pipeline
            variables:
              BITBUCKET_USERNAME: $BITBUCKET_USERNAME
              BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD
              REPOSITORY: 'my-cypress-tests'
              # ACCOUNT: '<string>' # Optional
              BRANCH_NAME: 'master' # Optional
              # CUSTOM_PIPELINE_NAME: '<string>' # Optional
              # PIPELINE_VARIABLES: '<json>' # Optional
              # WAIT: 'true' # Optional - if set to true, it waits for the triggered pipeline to complete. If the triggered pipeline fails, this pipe will also fail.
              # WAIT_MAX_TIMEOUT: '<string>' # Optional
              # DEBUG: '<boolean>' # Optional

BITBUCKET_USERNAME can be hard-coded to your Atlassian username or this can be set under the Repository settings > Repository variables section of Bitbucket to encrypt secrets.
BITBUCKET_APP_PASSWORD would need to be generated via Personal settings > App passwords then creating a new app password.

Alternatively, a shared account can be created by your Atlassian administrator that can be used across CI/CD pipeline and would not need dependency on resources going in and out of the team / company.

To add alerting, simply integrate the tests with Slack (include as many stakeholders as possible 😂

This is a good opportunity to say "Sorry Mr. Software Engineer, you can't proceed until you fix your breaking changes (and no, I'm not fixing my tests either!) Just kidding! Collaborate with your developers as much as possible to resolve the issues 😇