Graham Gatus Atlassian Team

@Matt Goodson were you able to resolve this issue? The scenario you've describe seems perfectly valid - if this isn't working please raise a support ticket so we can do a more thorough investigation.

@Harsha Vardhan are you able to provide some further details regarding your bitbucket-pipeline.yml file, as well as the source, and the output from maven ( if you can reproduce the problem, perhaps create a new public repository and post a link here demonstrating the problem). A few things you can try to narrow down the…

@kumarpr , are you able to provide your bitbucket-pipelines.yml file? Based on the error, it sounds like you may need to install chromium browser first. You can test this by running `which chromium-browser` in your pipeline, which should give the location of chromium. If chromium is not present, for an Ubuntu based build…

Hi @[deleted] , please ensure you allow incoming port 22 connections from the range of IP addresses used by both Pipelines services and Pipelines build environments - https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html. I would…

If you inspect the ~/.ssh/config directory in your pipeline, it contains an entry for IdentityFile, which points to the location of the private key which was generated via the UI. This location resolves to '/opt/atlassian/pipelines/agent/ssh/id_rsa'. Using tools such as git or ssh, they would check ~/.ssh/config to find…

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

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

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

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

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

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

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

@Marcy Nugent SSH will continue to work, however the SSH origin will no longer be the default we set after 1st February. To continue using SSH after this date, you can manually set the origin to the SSH origin in your bitbucket-pipeline.yml file by executing: git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN} Please…

@Andrew Stec the warning message is shown for all accounts where a pipeline executed that committed back to a repository over SSH, during a 6 week period leading up to the feature being enabled.

@NPxComplete, pushing back to other repositories under your account is not supported by this feature. You would need to manually configure one of the alternate authentication methods to allowing pushing to another repository. Discussing with the team, this may be something we could consider when we allow first class…

@Jono / @[deleted] / @ryanbannon: Branch permissions can be applied and will work if the repository owner has permissions to write to the branch being pushed to, however this doesn’t work if the repository is created under a Team account. The complication here is that pipelines executes using the account UUID of the…

@Peter Morlion / @[deleted], please contact support and we can provide information about the repositories you own that were pushing via SSH leading up to the 9th December.

@Malte Hübner the feature is still in the process of being rolled out, and we expect all accounts (except those currently pushing with SSH, which will be notified with an in app notification once rollout has complete) to have it within the next 24 - 48 hours. If you wish to checkout another branch and commit back, the…

If you did want to use the bitbucket build number, you could do something like: script: - export VERSION=1.0.${BITBUCKET_BUILD_NUMBER} # later, use ${VERSION} in scripts to update your pages - update-html-page-version.sh ${VERSION}

Hi @Marc Pipelines itself won't manage versioning (there is a $BITBUCKET_BUILD_NUMBER environment variable, but this probably wont fit into your versioning scheme) - you will need to use some tool to read the current version number from a file or external service, increment it by one, then write it back. Im not familiar…

@Vimal krishnamoorthy if you don't mind me asking, what method did you use to migrate over from github? I'm curious to find out how this could have caused issues in this case?

@Jeremy Stafford I've played around with setting up an extremely basic pipeline with dotnet , nuget and a basic installation of google cloud tools. I built a simple C# app based on https://docs.microsoft.com/en-us/nuget/quickstart/install-and-use-a-package-using-the-dotnet-cli, which pulled down a json related dependency…

@Vimal krishnamoorthy do you mind sharing a snippet from you bitbucket-pipelines.yml file? I haven't used CodeCommit before, however something to consider is that in pipelines, we perform a shallow clone of your repository (to a depth of 50, see the log output from Build Setup). Its possible that you are now trying to push…

@Anthony David thanks, I'll take a look!

@Aswin Satish One solution is to use 2 appspec files, one per branch: appspec-master.yml: version: 0.0 os: linux files: - source: ./ destination: /opt/master-path appspec-develop.yml: version: 0.0 os: linux files: - source: ./ destination: /opt/develop-path In your pipelines config, depending on the branch, you could…

If you tag each release, you can also use 'git describe' to check if there exists a tag pointing to the commit thats at the head of the newly created release branch. If a tag exists, skip running tests and deployments (since its most likely a new release branch thats been pushed). If no tag exists, then you have new…

@ajit54, for a "standard" maven project, you should be able to find your .war file under the "target" directory. Generally it should be target/<artifact>-<version>.war. You should be able to verify this by running your build commands locally. If you want to avoid writing additional scripts to build the .zip required by AWS…

Hi @[deleted] What specific service in Azure are you trying to deploy your application to? We have a guide for deploying to Azure App Service at https://confluence.atlassian.com/bitbucket/deploy-to-microsoft-azure-900820699.html I've noticed that Azure offer a static site hosting…

Hi @SamSpreadborough ARM based builds are not currently supported, and isn't a feature on our immediate roadmap. For a deeper discussion, please take a look at https://bitbucket.org/site/master/issues/15317/allow-building-multi-architecture-docker Feel feel to watch that issue for further updates. Thanks Graham

Hi @Anthony Schmieder You can use a non blocking source of randomness by using /dev/urandom instead of /dev/random. Assuming you are on Java, you should be able to pass a sys prop use the alternative source: -Djava.security.egd=file:/dev/urandom Alternatively, in your pipeline you can remove /dev/random and symlink…