It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Pushing back to your repository


@ryanbannonour Pipeline is mainly for deploying in GCloud.

We use Scala and sbt-release, so the "release" command bumps the project version (committing + pushing changes to "version.sbt" file) and publishes artifacts if relevant.

Currently we are releasing the projects manually before code is sent to Bitbucket, so we can push the version file ourselves.

I was waiting for the feature to be able to do it inside Pipelines.

Then I use Pipelines to get the fresh version number and to create a fresh Docker image (so it uses the same versioning from the repo) and to deploy it.

NPxComplete Atlassian Team Jan 04, 2019

@Beatriz Capelli It sounds like the workflow you want is something like

Dev pushes to feature branch

Feature branch (pipelines) run tests 

Merge feature branch to master (via PR)

Master branch (pipelines) bumps version.sbt and pushes to staging branch

Staging branch runs `sbt release`

Where both staging and master are sox controlled.

Would that work for you?

@Beatriz Capelli Add "[skip ci]" into any commit message you're pushing from pipelines - that will prevent the pipeline loop.

Like Graham Gatus likes this

@Marcy NugentThat seems great! I will try that asap.

I just saw it on the example anyway ¬¬ I just tried from my head when got the news, sorry!

Linette Atlassian Team Jan 06, 2019

@ryanbannonGenerally community is a great place to see how other people are using Bitbucket. You could even start a thread asking people about them? I'm also planning on putting something in the docs to gather together examples of how people might use pipelines in different ways. I think it's much easier when you can see examples!

This article is a bit misleading. I had a repo that was actually manually setting up an HTTP origin url by getting an access token via oauth. I don't remember why we set it up that way instead of using ssh keys. Anyways, the article only calls out SSH push-back as being put on the exclusion list, when in actuality it seems to be any push-backs. Just in case anyone else was crazy enough to do it the way I did, you will still have to set the origin manually if you want to switch to this method before Feb 1.

Like ryanbannon likes this

It looks like the jgitflow-maven-plugin (originally created, but no longer maintained by an Atlassian employee, and published under the atlassian team) does not support this because the version of jgit is too old, and it doesn't support 301 Moved Permanently (bug 465167) (which apparently is required with the proxy thing).

I have updated the plugin manually to use the latest jgit version, but still doesn't work because:

`Authentication is required but no CredentialsProvider has been registered`.

Any other ideas on how to make this work?

Hopefully someone at Atlassian will pick up the maintenance on this plugin, even if just accepting pull requests and releasing new versions of that very useful and widely used plugin, especially now considering that it will no longer work on Pipelines?  I would think that at least _some_ teams at Atlassian are using this plugin, even if the original author/maintainer have moved on from it.

I'm getting these warnings after switching to http from ssh:


You are currently connecting with your team account.

This is no longer supported, so please connect using your user account.


I can't seem to find how I can change my account with this new approach. I'm using a custom docker image.


Any insight? Thanks in advance.

Like Chu Anh Đức likes this

@Han Xu this is a known issue when pushing back to a repository nested under a team account, however it won't affect pushing back. We'll post further updates when a fix has been made available, and you can follow for more information.

@Ben seems the issue is that you need to tell jgit (which is used by the jgitflow-maven-plugin) to use the Git proxy which we use to inject the OAuth credentials. You can do this by passing system properties to maven.


mvn jgitflow:release-start -Dhttp.proxyHost=localhost -Dhttp.proxyPort=29418

The git client provided in pipelines has already been configured to use the auth proxy (if you run 'git config --list' in your pipeline, or expand the 'Build Setup', you will see the proxy settings).

The 301 you were seeing was caused by an unauthenticated git+http request being sent to Bitbucket (as the request out from jgit wasn't going via the auth proxy and having the auth credentials injected into the request).


In pipeline I commit changes to both the current project and also commit changes to another project. So I will need to configure remote origin ssh for both the projects ? How do I do that?

We're also receiving the message for this, though I don't completely understand as to why.

All we do is what is above.. bitbucket itself decided it's ssh. adding the " - git remote set-url origin ${BITBUCKET_GIT_HTTP_ORIGIN}" command also works and causes no issues.

My tought is that it is because we're pulling other repositories with for example composer how is this affected?

What if I need to push back to another repository in my account? how would it be?

Graham Gatus Atlassian Team Jan 20, 2019

@Abhishek Nandi / @Enrique Wood pushing back to another repository using this method is not yet supported. There is a feature request to have this implemented; feel free to vote for it -

You can configure any of the available authentication methods if you wish to commit to another repository, which are detailed at You will need to generate either an OAuth token, App Secret or SSH private key to be able to push back to another repo, and provide these to pipelines.

Graham Gatus Atlassian Team Jan 20, 2019

@Samantha Adrichem, prior to feature launch, we automatically added all accounts with repositories that were pushing commits from pipelines (within a 6 week period leading up to the feature launch) to an exclusion list. These accounts won't have the http origin enabled by default until 1st February, and receive the notification, giving time to configure ssh to be the default, or switch to http.

If you want a list of what accounts are pushing back over ssh, please contact support and we can provide you further details.

Graham Gatus Atlassian Team Feb 03, 2019

We've now switched all accounts to have the HTTP origin enabled by default.

Forgive me if this has already been discussed, but are there any security concerns with the new feature? Suppose I have a pipeline that uses SSH. Couldn't a script easily change the origin back to HTTP, then start doing pushes?

Graham Gatus Atlassian Team Feb 19, 2019

@ryanbannon in such a scenario where you may be executing potentially untrusted or non peer reviewed code/scripts and want to avoid either unwanted pushes by other developers, or even malicious pushes due to a bad 3rd party script, I would suggest restricting access using branch permissions, and configuring a minimum number of approvers on pull requests before a merge can happen.

@Graham Gatus even with branch permissions, it still seems like a security flaw. Unless I'm mistaken, before the switch to HTTP origin by default, credentials were a must because SSH was used. Inconvenient, yes, but secure. Now with HTTP, a security flaw exists that can only be remedied by branch permissions? What if I have hundreds of repositories?

@Graham Gatus what is really upsetting to me is that there seemed to be a good solution with just using SSH and having to provide a private key that's obfuscated, but with the new feature a security flaw has been implemented in favor of convenience. On top of that, I'm being told that the solution is to have a better review process and use more branch permissions. Even if I did that, the old SSH solution would have taken care of this.

Forgive me if I seem combative; I'm not trying to be. I'm just struggling to understand. Is there something I'm missing, because this seems like a step backwards.

@Linette @Graham Gatus I would very much like to discuss this. Perhaps the community forum is not the best place. I really want to understand what I'm potentially missing, because I love using BP. But from my understanding, this feature creates a security flaw that will force me to reconsider my use of BP altogether.

What would be the best place to further this discussion?

Graham Gatus Atlassian Team Feb 25, 2019

@ryanbannon I've raised a site master ticket to discuss this further - . Feel free to move discussion there.

Like ryanbannon likes this

@Graham Gatus great! Thanks so much!

I struggled mightily with this new http proxy using Maven's release plugin and scm. Kept getting this output from the scm plugin:

could not read Username for '': No such device or address  

Misleading, but makes sense in retrospect.

The url defined in my Maven pom.xml for the repository included the .git extension, i.e.**/*.git

The pipeline value of BITBUCKET_GIT_HTTP_ORIGIN does not include the .git extension in the url. So Maven was not hitting the proxy as it's request to the remote was a slightly different url, and Bitbucket host was asking for a Username. 


Log in or Sign up to comment
Community showcase
Published in Bitbucket Pipelines

What We Learned When We Researched Open Source Vulnerabilities in 7 Popular Coding Languages

...hey are a part of us, shaping how we interact with the world around us. The same holds true for programming languages when we think about how different kinds of vulnerabilities raise their heads in t...

405 views 0 1
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you