Say you are maintaining a set of Atlassian Enterprise plugins in separate repositories on Bitbucket Cloud.
Say they share the same build commands in their `bitbucket-pipeline.yml` definition , for instance they all need to be able to release either a milestone or a final version
- parallel:
- step:
name: Release Milestone
trigger: manual
caches:
- maven
script:
- git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN}
- ./build/mvn-release.sh milestone
- step:
name: Release
trigger: manual
caches:
- maven
script:
- git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN}
- ./build/mvn-release.sh final
In order to allow the maven release to go through and push git tags back to the repo, we will first need to generate an SSH Key from the repo and apply it on our account settings as per the documentation available here ... (this little detail is important to the next section)
Now the fun part is to figure out how to distribute those "build scripts" across multiple repositories
The first idea that comes to mind would be to store those scripts into a separate repository and consume it as a git submodule
cd my-plugin
git submodule add git@bitbucket.org:<workspace>/build-scripts.git
I can then update my pipeline definition as follow to first resolve the submodule
script:
- git submodule update --init --recursive
- git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN}
- ./build-scripts/mvn-release.sh milestone
notice that `git submodule update --init --recursive`
which is there to make sure build scripts are checked out, because they are not there by default on a simple clone
and when I want to update my repo to use a newer version of build-scripts
I can use either of the following commands, and commit the changes back to my repo
git submodule update --recursive --remote
git pull --recurse-submodules
curve ball
pipelines won't be able to resolve the submodule because it doesn't have access
one way to mitigate this problem is by generating an SSH Key from our repo, and apply it as access key to our new `build-scripts` repo
however that will not work ... because remember, we have already assigned the key to our account so the maven release can go through succesfully
Morale , maybe don't use git submodules when dealing with build configurations
yes, this, do this !
It is a much better option documented here which basically allows you to pipe a Docker image into your pipeline and "execute" it prior to running the rest of your build steps.
So essentially you can write a pipe that copies over to your build context all the scripts you need.
Here is a summary of that documentation in images (the steps I followed)
- parallel:
- step:
name: Release Milestone
trigger: manual
caches:
- maven
script:
- pipe: <worskpace>/build-scripts:<git-tag>
- git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN}
- ./atlas/mvn-release.sh milestone
- step:
name: Release
trigger: manual
caches:
- maven
script:
- pipe: <worskpace>/build-scripts:<git-tag>
- git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN}
- ./atlas/mvn-release.sh final
Hmm, yea
Hasnae
Senior Developer
Atlassian
Sydney
6 accepted answers
0 comments