You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I see two issues with the yml file you posted:
1st. The two steps are parallel. Parallel steps can only use artifacts produced by previous steps, not by steps in the same parallel set.
If you want the second step to use an artifact generated by the first step, you will need to remove the parallel keyword.
2nd. I'm afraid that the file path in artifacts cannot render variable names. We have a bug report about this in our issue tracker:
As a workaround, you can determine as an artifact any file with .zip extension as follows:
In case you have multiple zip files in the clone directory and you want to avoid having all of them uploaded as artifacts, you can generate this specific zip in a separate folder inside the clone directory, e.g. named 'app', and then define as an artifact any zip file in that directory
Please feel free to let me know how it goes and if you need further assistance.
Thank you for the update and you are very welcome! It's good to hear that the issue was solved.
Regarding $BITBUCKET_BUILD_NUMBER not incrementing, have you perhaps defined a deployment variable, repository variable, or workspace variable with the same name? These variables will override default ones with the same name.
If you add the command ls -lah below the zip command as follows, does the number in the name of the zip not correspond to the build number?
- zip -r example-$BITBUCKET_BUILD_NUMBER.zip .
- ls -lah
In case you are generating the zip in a directory inside the clone directory, provide the directory name in the ls -lah command.