Bitbucket cloud trigger pipe

[plussier]

Is it possible for a triggered pipeline to pass information back to the repository pipeline which triggered it?

For example, if repo my-lib triggers a rebuild of my-app, is there a way to pass information back to the pipeline in my-lib for further action other than simple success or failure?

[Mark C]

Hi @plussier

Thanks for reaching out to the community.

Perhaps you can trigger another build using using the Pipes script trigger-pipeline to pass back any information you'd like from the parent repo.

Regards,
Mark C

[plussier]

Hi, @Mark C ,

Thanks for the reply.  I thought of that, but it doesn't really make sense to do that.  Having A1->B->A2 would end up with loop.  A1 triggers B and has to wait for it to complete. B then triggers A2 and waits for it to complete... what? A different pipeline entirely which now contains the data the I'm waiting for A1 ?  Meanwhile, now A1 is waiting for A2 to complete so B can complete and return to A1?

That seems like high-risk chain of events that just won't work well.

Since we can have environment variables persist between steps in a normal pipeline, it seems that we should somehow be able to pass environment variables back when a triggered remote pipeline completes.

I'm guessing it's not currently possible, but it sure would be helpful and convenient!

--

Paul

[Mark C]

Hi Paul,

True, it may be messy to manage especially when builds becomes busy. Indeed, you can try passing through data using variables or through the use of Caches.

Alternatively, you can try to containerize the library using Bitbucket Cloud Packages and update it from your desired build step.

Regards,
Mark C

[plussier]

Hi Marc,

Passing data back from the triggered pipeline using variables is exactly what I'd like to do, that was basically my initial question. I'm just not clear on how that works. I don't see anything in docs for the trigger pipe that says there's any exit data passed back to the triggering pipeline. As far as I can tell, the trigger pipe simply makes a BB API call to run a remote pipeline, then polls for it's exit status (success or failure).

Containerizing the library isn't useful in this case.   The goal is to be able to use information passed back in subsequent steps in the triggering pipeline.  In other words:

• A triggers B
• B does whatever, and exits passing back data to A
• A then moves on, using the data passed back in follow-on steps.

Containerizing the repository from A doesn't help me as far I can tell.

--

Paul