Run Bitbucket Pipelines locally for testing

[TimorKalerman]

I understand that there is an official suggestion to run the same docker image on my local environment and run there all the script I am using in my bitbucket-pipelines.yml.

But I would like to actually use my bitbucket-pipelines.yml and test it "as is", before commiting it to the repo.

This is will give me the ability to tweak it as much as possible before commiting, thus saves me a lot of debuging commits.

Anyone has a way to do that?

[Erez Maadani]

Hi @TimorKalerman 

I haven't tried it but the general direction would be to set up a self-hosted runner, configure it and then trigger builds locally.

For setting up the self-host runner, have a look here: https://support.atlassian.com/bitbucket-cloud/docs/adding-a-new-runner-in-bitbucket/

Take a special look at the section #9, which talks about the pre-configured scripts which:

"automatically downloads and starts the necessary software to run build steps on your host"

That should explain how the triggering commands are getting to your runner and how they are converted into commands to run your build steps. 

The last part is to understand what is included the triggering command, so I guess you would have to do some commits to understand what info is actually sent to your runner.  

Hope that helps

[TimorKalerman]

Thank you @Erez Maadani , I will test it, but it will still require me to do commits for each fix instead of testing locally on my pc before I commit.

Anyway I guess currently there is no way for it, but hopefully Atlassian will release such tool.

I know Google Cloud Build for example has such tool for local debugging and it is very helpful.

[Theodora Boudale]

Hi Timor,

If you are referring to debugging pipelines locally as per this guide, then there is no way to use the bitbucket-pipelines.yml file "as is". In this case, you run in the container the commands that you intend to use in your bitbucket-pipelines.yml file.

You can always create a fork of the repo for testing purposes and use it with a Linux Docker runner as Erez suggested (so that you don't consume build minutes), and eventually delete the fork. Please keep in mind that if you use any user-defined variables or deployment environments in the fork's builds, you will need to create them also in the repo where you want to run the builds eventually.

Kind regards,
Theodora