@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.
Atlassian Team members are employees working across the company in a wide variety of roles.
January 6, 2019 edited
@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.
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.
It looks like thejgitflow-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 itdoesn'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 someoneatAtlassianwill pick up themaintenance 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 onPipelines? 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.
Atlassian Team members are employees working across the company in a wide variety of roles.
January 16, 2019 edited
@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.
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?
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.
Atlassian Team members are employees working across the company in a wide variety of roles.
January 20, 2019 edited
@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.
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?
Atlassian Team members are employees working across the company in a wide variety of roles.
February 19, 2019 edited
@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?
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.
56 comments