Parallel custom pipelines triggered through API: Bug???

Question

I'll try explain my situation in as much detail as possible below. I'm not sure if I'm missing something or if there is a bug in the `atlassian/trigger-pipeline:5.3.0` pipe. You are welcome to ask any questions below if anything is unclear.

I have the following parallel steps in my pipeline

custom:
Project 1 pipeline
  - step: (whatever pipeline 1 does)
Project 2 pipeline
  - step: (whatever pipeline 2 does)

default:
 - parallel: 
   steps:
   - step:
       name: trigger for project 1
       script:
       - pipe: atlassian/trigger-pipeline:5.3.0
         variables:
           BITBUCKET_USERNAME: $BITBUCKET_USER
           BITBUCKET_APP_PASSWORD: $BITBUCKET_PASSWORD
           REF_TYPE: 'branch'
           REF_NAME: $BITBUCKET_BRANCH
           CUSTOM_PIPELINE_NAME: "Project 1 pipeline"
           ACCOUNT: "myaccount"
           WAIT: "true"
           DEBUG: "false"
           REPOSITORY: "myrepository"
      condition:
        changesets:
          includePaths:
          - "apps/project1/**"
   - step:
       name: trigger for project 2
       script:
       - pipe: atlassian/trigger-pipeline:5.3.0
         variables:
            BITBUCKET_USERNAME: $BITBUCKET_USER
            BITBUCKET_APP_PASSWORD: $BITBUCKET_PASSWORD
            REF_TYPE: 'branch'
            REF_NAME: $BITBUCKET_BRANCH
            CUSTOM_PIPELINE_NAME: "Project 2 pipeline"
            ACCOUNT: "myaccount"
            WAIT: "true"
            DEBUG: "false"
            REPOSITORY: "myrepository"
      condition:
        changesets:
          includePaths:
          - "apps/project1/**"
          - "apps/project2/**"

I have two projects in my monorepo, Project 1 and Project 2. I want the pipeline to run on every commit and it should trigger the two custom pipelines Ive listed above based on the following conditions.

* Trigger Project 1 custom pipeline if there are any changes to Project 1.
* Trigger Project 2 custom pipeline if there are changes to Project 1 or Project 2

While the pipelines run the merge button should be disabled until all of the pipelines pass, if any of them fail it should fail the overall pipeline.

When I make a commit the custom pipelines get triggered correctly with the conditions above, and the merge button gets enabled when all the triggered pipelines pass.

The problem I'm having is that since Project 2 pipeline has fewer steps and runs quicker than Project 1 pipeline, if its pipeline passes, the main pipeline is marked as passed and the merge button gets enabled (This shouldn't happen). When Project 1 pipeline eventually finishes and the project fails, it then changes the main pipeline result to failed and correctly disables the merge button.

The strange thing is this works correctly the other way round, If Project 2 pipeline fails first, main pipeline is marked is marked as failed and merge button is disabled, even if Project 1 pipeline passes afterwards, main pipeline remains as failed.

Note: The end result of the main pipeline is correct, if one of the pipelines fail the end result after all the triggered pipelines have run will be failed. The only problem is that if the shortest triggered pipeline passes there is a moment when a developer can merge their PR even if the rest of the triggered pipelines are not yet completed.

This seems like a bug to me, but if it isn't can anyone see if there is anything wrong with my implementation

Saxea _Flowie_ · Answer

@Mnoto Nyembe  I believe the 'no build in progress build' is checking for commit build status in progress - not actually for running pipelines.

As a workaround, I think you could try to setting the build status to 'in progress' in the first pipeline via a API call. Probably using 'after-script', get the current build key and update the status. Note that the PR would still be mergeable for a short period.

Another option, is to create a new build status at the start and end of the main pipeline, and change your check to require 2 builds. This would avoid the mergeable window.

Alternatively, I think we might be able to help with Flowie as it should be able to check for running pipelines. If you are interested, contact support via support@flowie.app and we can assist you.

Igor Stoyanov · Answer

@Mnoto Nyembe hi. I do not know how to fix the issue you described. But maybe i could suggest you a workaround. Lets say repoA is a repo where you initiate pipelines to trigger. And repoB is a repo where pipelines automatically triggered. You wrote a pipeline for repoA: - parallel: steps: - step: name: trigger for project 1 script: - pipe: atlassian/trigger-pipeline:5.3.0 variables: BITBUCKET_USERNAME: $BITBUCKET_USER BITBUCKET_APP_PASSWORD: $BITBUCKET_PASSWORD REF_TYPE: 'branch' REF_NAME: $BITBUCKET_BRANCH CUSTOM_PIPELINE_NAME: "Project 1 pipeline" ACCOUNT: "myaccount" WAIT: "true" DEBUG: "false" REPOSITORY: "myrepository" condition: changesets: includePaths: - "apps/project1/**" - step: name: trigger for project 2 script: - pipe: atlassian/trigger-pipeline:5.3.0 variables: BITBUCKET_USERNAME: $BITBUCKET_USER BITBUCKET_APP_PASSWORD: $BITBUCKET_PASSWORD REF_TYPE: 'branch' REF_NAME: $BITBUCKET_BRANCH CUSTOM_PIPELINE_NAME: "Project 2 pipeline" ACCOUNT: "myaccount" WAIT: "true" DEBUG: "false" REPOSITORY: "myrepository" condition: changesets: includePaths: - "apps/project1/**" - "apps/project2/**" you could change it in repoA to the next: step: name: trigger a pipeline script: - pipe: atlassian/trigger-pipeline:5.3.0 variables: BITBUCKET_USERNAME: $BITBUCKET_USER BITBUCKET_APP_PASSWORD: $BITBUCKET_PASSWORD REF_TYPE: 'branch' REF_NAME: $BITBUCKET_BRANCH CUSTOM_PIPELINE_NAME: "Trigger for all projects" ACCOUNT: "myaccount" WAIT: "true" DEBUG: "false" REPOSITORY: "myrepository" and in repoB you will have the next pipeline to trigger: - parallel: steps: - step: name: trigger for project 1 condition: changesets: includePaths: - "apps/project1/**" - step: name: trigger for project 2 condition: changesets: includePaths: - "apps/project1/**" - "apps/project2/**" In this scenario you will have 1 triggered pipeline, and regarding to it's status, you will know is it possible to merge or not. Regards, Igor

Mnoto Nyembe · Answer

Hello @Saxea _Flowie_

If I understand your question correctly you are referring to the build result on the PR page, the answer is no, the end result will always be 1 of 1 build passed after everything has run. The build that I run triggers 1 or more custom pipelines using the following pipe

atlassian/trigger-pipeline:5.3.0

I have

WAIT: "true"

as a parameter for the pipe, this is what the pipes documentation says WAIT is supposed to do:

Flag to wait until the triggered build finishes. Default: false. If set to true, this pipe will wait for the triggered pipeline to complete. If the triggered pipeline fails, this pipe will also fail.

atlassian/trigger-pipeline documentation

When my pipeline successfully triggers the custom pipeline it waits for waits for it to complete and if the triggered pipeline is successful it sets the build on the PR page as successful, if it fails it sets it to failed. This is expected and works perfectly when my pipeline triggers 1 custom pipeline. As soon as I trigger 2 or more custom pipelines if the first triggered pipeline passes it sets the main build on PR page as successful, (which is not what I want) and the developer is able to merge, if another triggered ends up failing in the same build it then changes the main build and then disables the Merge button. I am expecting the Merge button to be disabled until all the triggered pipelines are completed

I currently have Minimum number of successful builds for the last commit with no failed builds and no in progress builds set to 1, I tried changing it to 2 but then the merge button is always disabled even if all the triggered pipelines pass.