Philip Hodder Atlassian Team

No worries! The solution is almost always trivial once you know what it is. Finding it is the hard part. :)

Thanks for the information rhitik.bhatt@rivetlabs.io. Can I get you to open a support case here: https://support.atlassian.com/contact I suspect there was an error uploading your logs, rather than downloading them. And we'd like to investigate what the root cause of this is, so it doesn't happen to you (or other users)…

Hi Rhitik, Was there a traceId or requestId in the response payload that you can share? Is this happening for just a single step, or several? Thanks, Phil

Hi Fabian, Can you provide an example of your bitbucket-pipelines.yml? Are you running all your Cloud Foundry commands in the same step? Pipelines does not persist state across steps. So you'll need to log in again if you run commands across several steps. You can also try to run your commands in a similar environment as…

Hi Mathieu, Can you please provide an example of a script that isn't replacing the variable correctly? Variable substitution in the script is not performed by the YAML parser. The script section simply defines Bash commands. So variable substitution will happen at runtime. You need to make sure that the AWS command is…

This feature is currently not supported in Pipelines. There's an open feature request for adding support for environment variables in Docker image names that you can follow if you're interested. Using Docker Compose is the way to go here! It's an intentional use-case we had for providing Docker in Docker. The associated…

As Lavakumar said, a 4x size is currently not supported in Pipelines. We have an open feature request for this here that you should watch: https://bitbucket.org/site/master/issues/17260/ability-to-increase-pipelines-memory Are you currently at the 10 step limit? Or can you increase the number of steps to split your…

Hi Roman, Looks like this is a whitespace formatting issue. You need to change the step indentation to this: pipelines: branches: master: - step: *Test-step - step: <<: *Deploy-step name: Deploy to Test deployment: test - step: <<: *Deploy-step name: Deploy to Staging trigger: manual deployment: staging release/*: - step:…

Hi Vetri, We have a guide on how to push back new commits to your Bitbucket repository here: https://community.atlassian.com/t5/Bitbucket-Pipelines-articles/Pushing-back-to-your-repository/ba-p/958407 Thanks, Phil

Hi William, Pipelines currently does not support repository transfers. So you'll need to copy over the necessary data manually between repositories. I couldn't find an open feature request to support this. So, if you'd like, you can open one here: https://bitbucket.org/site/master/issues/new Thanks, Phil

Hi Ken, Bitbucket Pipelines has its own YAML configuration. It looks like you're trying to reuse the one defined on the Dockerhub readme? You cannot combine the stack.yml format with the bitbucket-pipelines.yml format. The 'restart' and 'ports' properties shouldn't be necessary for you here. See how you go without them.…

Hi Jiri, I've seen a few other users use Git-FTP to solve this problem. I'm not too familiar with it myself, but it could be another tool you could look into. If you use Git and you need to upload your files to an FTP server, Git-ftp can save you some time and bandwidth by uploading only those files that changed since the…

@alexwonguhuru, if you only need the variable variation for you deployments, you should be able to use Deployment Variables to do that. They'll let you define different values for the same key on different deployment steps. We have documentation about it…

Before running the pipe, try checking the files that exist in your build environment. ls -R $BITBUCKET_CLONE_DIR | xargs realpath ls -R $BITBUCKET_CLONE_DIR | xargs realpath | grep hosticawebapp You may also need to install realpath with apt-get, if realpath cannot be found.

Hi @Elias Serneels, I had a chat with a few team members: * We have the reference (tag or branches) limitations documented here in the 'Push Limits' section. It's not too clear (or Google-able) though, so we'll get that updated later. * I chat with one of the PMs and they had seen a similar use case! The other user was…

Thanks for letting me know. I checked and I couldn't find any documentation either. We implemented the limit a few years ago, so it's possible it got lost in a rewrite of a page. I'll chase up getting it re-added to the docs. Interesting use case. I haven't encounter anyone else with a similar one, but I'll pass this onto…

We've started looking into adding support for flexible environment configuration (add, rename, delete). You can follow the progress of this feature here: https://bitbucket.org/site/master/issues/15362/enhance-deployments-to-support-flexible

@Liri Sokol, we've started work on adding support for flexible environment configurations (i.e. more than 3 environments, named whatever you want). You can follow its progress here: https://bitbucket.org/site/master/issues/15362/enhance-deployments-to-support-flexible

Environment Variables are not carried across steps. They are always copied from those set in the Pipelines UI. If you'd like to update them you can use the Bitbucket Pipelines REST API to do so. Alternatively you can combine the two steps so that the new credentials are available in the push step. 

Apt-get is not installed by default on the Docker image you are using (samueldebruyn/debian-git). Depending on the base image of your image, you may have other tools available. You can try use the 'apt' command (although it may also not be present) to perform operations, use an image that contains apt-get, or install…

Bitbucket Pipelines now has support for Deployment Variables. These are variables that are only defined for a single environment. So for example, you can have a variable mapping like: Staging environment: DEPLOYMENT_ENVIRONMENT = staging RESOURCE_FILE = stg.yml Production: DEPLOYMENT_ENVIRONMENT = production RESOURCE_FILE…

The state of one step is not carried to the next. So you'll need to combine step 3 and step 4 together in order to tag and push the built image. In any subsequent steps, you can then pull the image and operate on it (perhaps to retag the image for a deployment step).

Pipelines has support for manually trigger steps. For example, you can configure the following pipelines: default: - step: name: Automatic step script: - # Commands - step: name: Manually triggered step trigger: manual script: - # Commands More details can be found…

Restricting Pipeline execution is currently not supported. However we are currently working on Deployment restrictions. This will allow for configuring users who can perform a deployment step, as well as which branch the deployment can be deployed from. More details on this feature request:…

Bitbucket Pipelines parses xUnit / JUnit test formatted test results. First check that your tests are outputting the results in this format. Unfortunately, the format is not very strict. So we have to modifying our parser for specific build tools. If this issue is still occurring, can you open a feature request with an…

You can set this up by using scheduled pipelines. First, create a pipeline definition such as this: pipelines: custom: my-scheduled-pipeline: - step: name: Run Tests script: - ./run-tests Pipelines defined in the 'custom' section will not be triggered by any automated actions. They can only be triggered manually or via a…

A repository admin is a user that either created the repository, or has been granted admin access by an existing administrator. A user with write access to a repository does not necessarily have admin access to a repository. More details can be found…

Hi Ankur, Currently the only deployment tags allowed are "test", "staging" and "production". We are currently working on adding support for more environments, as well as naming them as you'd like. You can follow its progress here: https://bitbucket.org/site/master/issues/15362/enhance-deployments-to-support-flexible…

Hi Carlos, You can enable Pipelines on the 'Pipelines' tab on the sidebar. That configuration should be fine. If you'd like to use Deployments, you will need to add the "deployment" keyword to your step. For example: pipelines: default: - step: deployment: production script: - ./deploy-to-production From what I can see,…

Hi Annelise, Pipelines copies the entire contents of your repository for each build. So you should be able to use the BITBUCKET_CLONE_DIR variable in order to indicate the files to update. image: python:3.5.1 pipelines: branches: master: - step: script: - pipe: atlassian/aws-s3-deploy:0.2.1 variables: AWS_ACCESS_KEY_ID:…