Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,361,597
Community Members
 
Community Events
168
Community Groups

Using trigger-pipeline to trigger the 'default' pipeline of another repo

Edited

Hi,

 

I'm trying to use trigger-pipeline (5.0.1) to trigger other pipelines in other repos. 

For branches like 'master', 'release/*', and 'develop', I want to trigger the corresponding branch in the downstream repo.  But for the 'default' pipeline in "repoA", which gets run on things like 'feature/*' branches, I want to trigger the 'default' pipeline in downstream "repoB".

Generally, this works fine when $BRANCH is one of (master, release/*, develop). But I can't figure out how to trigger the "default" pipeline.

 

I *could* create a 'custom' pipeline called 'default', and set the value of 'CUSTOM_PIPELINE_NAME' to 'default', but that seems rather redundant. Why have two pipelines called 'default', both of which do exactly the same things, but which get called by different means.

It seems what I'm missing is, how do I trigger the "default" pipeline directly? Does anyone have any idea how to do this?

Thanks.

--

Paul

1 answer

1 vote
Mark C Atlassian Team Aug 25, 2022

Hi @plussier,

Thank you for reaching out to the community.

In your repoA YAML file (bitbucket-pipelines.yml), would you be able to confirm if you're using triggers both "default:" and "branches:"?
If yes, do you have the "feature/" branch added in the "branches:" trigger?
If yes again, Pipelines will run the step from the trigger "branches:" instead of the default one.

The default pipeline runs on every push to the repository unless a branch-specific pipeline is defined.

Reference: Configure bitbucket-pipelines.yml - default

For that, you can edit your bitbucket-pipelines.yml (in repoA) and remove the configuration "feature/" from the "branches:" trigger.
Then in your repoB, you can use the Pipes script below which should trigger the default step in repoA for "feature/" branch:

            - pipe: atlassian/trigger-pipeline:5.0.1
              variables:
                BITBUCKET_USERNAME: $SOME_USERNAME
                BITBUCKET_APP_PASSWORD: $SOME_APP_PASS
                REPOSITORY: 'repoA'
                REF_TYPE: 'branch'
                REF_NAME: 'feature/1.0'

Hope it helps and let me know how it goes.

Regards,
Mark C

Hi Mark,

Thanks for the reply. I think I may not have been very clear in what my problem is. I'll try do explain this better.

repoA is a dependency of repoB. Changes in repoA should trigger a build on repoB (using the same branch as the changes occured on in repoA IF AND ONLY IF the changes on repoA are one of (develop, release/*, or master). If repoA is using a feature branch, then it should trigger a rebuild of repoB on the develop branch.

repoB's pipeline looks like this
pipelines:

pipelines:
default:
- step: *build
- step: *testA
- step: *testB
- step: *testC

pull-requests:
'**':
- step: *build
- step: *testA
- step: *testB
- step: *testC

branches:
develop:
- step: *build
- step: *testA
- step: *testB
- step: *testC
- step: *uploadBuildArtifacts

master:
- step: *build
- step: *testA
- step: *testB
- step: *testC

release/*:
- step: *build
- step: *testA
- step: *testB
- step: *testC
- step: *uploadBuildArtifacts

In repoA I have this:

  - REFNAME=${BITBUCKET_BRANCH}
- REFTYPE='branch';
- if [[ ! ${BRANCH} =~ (^develop*|^release*|^master*) ]];then echo "caught one of [develop,release,master]"; REFNAME='default'; fi;
- if [[ ${BITBUCKET_TAG} =~ ^20[0-9][0-9]\.[0-9]\.[0-9] ]];then REFTYPE='tag';REFNAME=${BITBUCKET_TAG}; fi;
- export REFTYPE REFNAME;
- pipe: atlassian/trigger-pipeline:5.0.1
variables:
BITBUCKET_USERNAME: ${USER}
BITBUCKET_APP_PASSWORD: ${PASSWD}
REPOSITORY: 'repoB'
REF_TYPE: ${REFTYPE}
REF_NAME: ${REFNAME}

So, what I want to have happen is, the trigger-pipeline pipe should trigger the DEFAULT pipeline based on setting REFNAME accordingly. Unfortunately, REFNAME is git reference, not a pipeline target. So I need some way of specifying a pipeline target instead. And so far, the best I can come up with is this:

  - REFNAME=${BITBUCKET_BRANCH}
- REFTYPE='branch';
- if [[ ! ${BRANCH} =~ (^develop*|^release*|^master*) ]];then echo "caught one of [develop,release,master]"; export CUSTOM_PIPELINE='default'; REFNAME='develop'; fi;
- if [[ ${BITBUCKET_TAG} =~ ^20[0-9][0-9]\.[0-9]\.[0-9] ]];then REFTYPE='tag';REFNAME=${BITBUCKET_TAG}; fi;
- export REFTYPE REFNAME;
- pipe: atlassian/trigger-pipeline:5.0.1
variables:
BITBUCKET_USERNAME: ${USER}
BITBUCKET_APP_PASSWORD: ${PASSWD}
REPOSITORY: 'repoB'
REF_TYPE: ${REFTYPE}
REF_NAME: ${REFNAME}
CUSTOM_PIPELINE_NAME: ${CUSTOM_PIPELINE}

Which requires a custom pipeline target in repoB like this:

custom:
default:
- step: *build
- step: *testA
- step: *testB
- step: *testC

As you can see, this is somewhat redundant. I have 2 pipeline targets which are identical, one named "default" and a custom one also named "default". So what I really need is a way to specify both the pipeline target AND the branch that target should run on. This appears to possible in the Bitbucket UI when manually running pipelines, so I'm guessing there must be a way to do it automatically with trigger-pipeline.

Thanks!
--
Paul

 

P.S. Also, if there's a way to have multiple steps with yaml anchors be referenced by yet-another yaml anchor, that would be cool too. So rather than having several pipelines which refer to "build", "testA"... etc. I could just say "&standard_build_test" and have that refer to those steps it would really cut down on duplication of code :)

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
TAGS
Community showcase
Published in Bitbucket

Git push size limits are coming to Bitbucket Cloud starting April 4th, 2022

Beginning on April 4th, we will be implementing push limits. This means that your push cannot be completed if it is over 3.5 GB. If you do attempt to complete a push that is over 3.5 GB, it will fail...

3,498 views 3 10
Read article

Atlassian Community Events