Pushing back to your repository

56 comments

Beatriz Capelli January 4, 2019

@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
Atlassian Team members are employees working across the company in a wide variety of roles.
January 4, 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?

Marcy Nugent January 4, 2019

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

Like # people like this
Beatriz Capelli January 4, 2019

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

Beatriz Capelli January 4, 2019

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

Linette
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
January 6, 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!

snyman January 7, 2019

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
Ben
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 9, 2019

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.

Like Chandler Zhang likes this
Han Xu January 9, 2019

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
Graham Gatus
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
January 13, 2019

@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 https://bitbucket.org/site/master/issues/17955/user-who-push-back-to-repositories-receive for more information.

Graham Gatus
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
January 16, 2019

@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.

e.g:

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).

Abhishek Nandi January 17, 2019

Hi,

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?

Samantha Adrichem January 18, 2019

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?

Enrique Wood January 18, 2019

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

Graham Gatus
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
January 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 - https://bitbucket.org/site/master/issues/17799/allow-pushing-to-other-repositories-under.

You can configure any of the available authentication methods if you wish to commit to another repository, which are detailed at https://confluence.atlassian.com/bitbucket/push-back-to-your-repository-962352710.html. 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
Atlassian Team members are employees working across the company in a wide variety of roles.
January 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
Atlassian Team members are employees working across the company in a wide variety of roles.
February 3, 2019

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

ryanbannon February 19, 2019

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
Atlassian Team members are employees working across the company in a wide variety of roles.
February 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.

ryanbannon February 19, 2019

@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?

ryanbannon February 19, 2019

@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.

ryanbannon February 21, 2019

@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
Atlassian Team members are employees working across the company in a wide variety of roles.
February 25, 2019

@ryanbannon I've raised a site master ticket to discuss this further - https://bitbucket.org/site/master/issues/18229/provide-opt-out-option-for-the-git-auth . Feel free to move discussion there.

Like ryanbannon likes this
ryanbannon February 25, 2019

@Graham Gatus great! Thanks so much!

Rob T March 4, 2019

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 'https://bitbucket.org': 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. http://bitbucket.org/**/*.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. 

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events