Distribute build scripts across your project in Bitbucket Pipelines

[#1]

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 

maybe I can just consume it as a git submodule ?

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

maybe use Bitbucket pipes ?

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)

• define `pipe.yml`

• setup a `Dockerfile` to contain your entry point to be executed by Bitbucket Pipelines, plus the set of scripts you intend to distribute

• provide an entry point `activate.sh` that copies the scripts folder and makes it available to the build pipeline

• now you can `docker build` and `docker push` your image, and update your readme, and also you must commit your changes with a git tag on them and push everything back to your new `build-scripts` repository.
• and finally consume it as a pipe across all your repositories.

- 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

 does it work ?

Hmm, yea