0

I have two Bamboo plans, the first one produces a shared artifact (a library) and the second one attempts to download it. The first plan puts the build number into the artifact name, the copy pattern is defined this way:

release-x64-b${bamboo.buildNumber}-runtime.zip

So I get a number of artifacts in the plan directory:

release-x64-b671-runtime.zip
....
release-x64-b678-runtime.zip

The dependent plan is instructed to simply download the artifact. I think it's using the copy pattern from the parent plan because I'm running into an issue where the dependent plan is substituting its own build number when downloading the artifact, here's a log excerpt:

Preparing to download plan result PROJECT-WVN-678 artifact: Shared artifact: [x64 Nightly Runtime], pattern: [release-x64-b207-runtime.zip]

(The dependent build number is 207 while the parent build number is 678). Is there a way for me to work around this 'feature'?

autonomy
  • 1,165
  • 1
  • 12
  • 18
  • so do you want the build number to be same or to fix the artifact with with same build number? If you want same build number then you can reset the number and always run both the plans so the number mismatch wont happen. If you want the parent build number to be used in dependent then you can use as below. – Chidambaram Jul 18 '18 at 10:51

1 Answers1

0

I hope if you have a dependent plan, then it is a subsequent stage. So, in the parent build you can save the build number in mvn_version using powershell script.

$buildnum=$env:bamboo_buildNumber

Then put the value into a text file 

echo "`nmvn_version=$buildnum" | out-file -encoding utf8 mvn_version.txt

Then add a task, inject bamboo variables, where you can set the path of file ./mvn_version.txt and namespace as inject. Choose the radio button as result, so the value will be subsequently accessible in following stages/dependent plans and release plan also.

Chidambaram
  • 434
  • 4
  • 14