nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Bamboo child plans: how do I get information about the parent plan?

Paul Smith

In Bamboo you can create a child plan that will be automatically invoked when a given plan completes successfully. I want to kick off a performance test plan after a good build of our nightly plan (but I don't want the availability or success/failure of the nightly plan to depend on the performance test plan, so I don't want to add it as a task to the nightly plan).

I see in Bamboo that I can add the performance test plan as a child of the nightly plan, which is great.

But I need the artifacts from the nightly plan when I run the performance test plan, and I can't see in the documentation any way to know what the plan name and build number of the parent plan was once I've started the child plan.

How can I get this information? Thanks!

Accepted answers

All comments

PiotrA

Hello Paul,

I think that what you are trying to achieve is not implemented yet in Bamboo - please check this issue out: https://jira.atlassian.com/browse/BAM-10573 - if I understand you correctly this is the functionality you're after. If so - can you vote on that issue?

I think the current workaround is to 'wget' the artifact from the different plan by hitting a relevant URL + basic authentication. If you wish I can find you more informations about that technique (although not today) - just chime in.

regards,

Paul Smith

Thanks Piotr. I did vote on that issue. For now I'm happy to do a wget, that's no problem. In fact I already do that in other situations and it's very easy. But in order to do the wget, I need to know the plan ID and build # of the parent plan. Is there a way to get that information? Without it I don't see how I can use wget for this.

Cheers!

PiotrA

Ah, I see - so you don't want to have a 'hardcoded' solution where you store the parent plan key in the script that calls wget? Instead you want to have some kind of a shared script that could be re-used in each of your 'child' plans in Bamboo? Am I understanding correctly?

Paul Smith

(Why do I not get email about answers even though I'm subscribed?? Grr.)

Ideally I would be able to have multiple parent plans run the same child, yes, because the child is a suite of performance validation tests and we have various different build plans we'd like to test.

But, even if we did hardcode the plan ID I still need to get the build number before I can retrieve the artifact, so I still need some information about the parent when the child is running... yes?

Thiago Marano

Hi Piotr,

That doesn't guarantee that I'm getting the same same parent build number as the one which triggered the child build

PiotrA

Hello Thiago,

Why do you need to guarantee you're getting the same build number?

Thiago Marano

Thanks for the quick reply. I have pipeline which consists of two plans. One for many kinds of testing, and another one creating a package, image, and deploying to different environments. I want to attach the build number, to the application version, when I create the package. But I want it to be the build number of my first plan, not the second.

PiotrA

Quick question - which Bamboo version are you using? 5.0++ ? I'm wondering if you could use 'Deployments' feature (introduced in Bamboo 5.0) and get rid of your second plan. Can you tell me if you considered using Deployments instead of the second, "releasing" plan?

Thiago Marano

I am out now, so I will reply to you tomorrow about the bamboo version. About using the deployment feature I have some concerns. I don't know how the feature actually works so I might be wrong. - I want my deployment repo to trigger only the deployment build when it changes. Not the tests. - I want to have a green plan once the tests passes, not to wait for the long time deployment takes. - I don't want my test plan red if deployment fails.

Thiago Marano

And I forgot this: I want to have concurrent test builds, not concurrent deployments.