Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Ignore bitbucketpipelines.yml during branch merge

jawad_abbasi August 5, 2019

I have two branches which have two separate bit bucket pipelines

  1. master

  2. develop 

when we try to merge the updated develop branch to the master, the pipeline in develop branch also merges with master and i don't want this happen because both pipelines are different from one another.

Thanks in advance if someone tell me how to get rid out of this ?

2 answers

1 vote
Daniel Santos
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 7, 2019

Hi @jawad_abbasi,

As you already know you can have multiple different bitbucket-pipelines.yml files in your repository, one for each branch, but that will bring you the inconvenient situation you are facing now.

The easier/recommended approach would be considering all of them the same file, but eventually with different versions. It means that the bitbucket-pipelines.yml file would have the pipeline's configuration for every branch that needs dedicated steps to run.

 

Let's say the first configuration we have for pipelines is this on master:

pipelines:
default:
    - step:
        script:
          - echo "this will run for EVERY OTHER repository branch"

Later we create develop branch and inherit it. We notice that we need a special pipeline for it. We then add and extra section to the bitbucket-pipelines which becomes this:

pipelines:
default:
    - step:
        script:
          - echo "this will run for EVERY OTHER repository branch"
 
branches:
    develop:
      - step:
          script:
            - echo "this step will only run in DEVELOP branch"

Merging the file back to master will still run only the first step (configured for default).

Please notice that what is in default will run for every branch other than develop.


At some point, you realize that you don't want new branches to run pipelines. In this case, you would change the default part to trigger only the master branch. The file would become like this:

pipelines:
  branches:
master
    - step:
        script:
          - echo "this step will only run in MASTER branch"

    develop:
      - step:
          script:
            - echo "this step will only run in DEVELOP branch"

 

Following the same idea, you can keep updating the bitbucket-pipelines.yml file and merging it without causing undesired builds.

Please let me know if it makes sense to you now.

jawad_abbasi August 8, 2019

Hi @Daniel Santos , i solved my problem with exactly the same solution, a little bit late reply but really a good answer, thanks bro....! 👍

Like Daniel Santos likes this
Daniel Santos
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 8, 2019

You are welcome!
At least it may save the time of other users reaching this thread.
Have a good one!

Like jawad_abbasi likes this
0 votes
Carlos Augusto October 7, 2021

Hi @Daniel Santos and @jawad_abbasi 

Sorry for the late message, but I have a need to run just one step as self-hosted for arm architecture build.

The other steps would normally run in bitbucket using your structure.

However, when I put in "definitions" the image docker:dind in the docker service it gives an error when compiling the other steps, as this option only works in self-hosted.

I even tried to create a "docker-custom" and include the image only in it, but I gave a memory error when running, not getting the definition of 3072.

I can't isolate this setting only for the "master" branch, as the homologation machine I have is ARM64 (which is not supported by Bitbucket for compilation), but the development machine is a normal AMD64.

The only way I thought was to have two bitbucket-pipelines.yml for each branch, however when merging it overwrites the content even though I include it in .gitignore and setting the merge method in .gitaatributes. Everything is ignored.

How to solve this problem?

I'm doing automated deploy with Rancher and Continuous Delivery (Fleet integrated), which reads a specific branch that I change at the end of the build in the pipeline.

 

Below my bitbucket-pipelines.yml

options:

  docker: true
 

pipelines:

  branches:

    develop:

      - step:

          name: Build

          image:

            name: golang:stretch

            username: $DOCKER_HUB_USERNAME

            password: $DOCKER_HUB_PASSWORD

            email: $DOCKER_HUB_EMAIL

          services:

            - docker

          condition:

            changesets:

              includePaths:

              - "app/**"

          script:

          - export APP_NAME=`echo ${BITBUCKET_REPO_SLUG} | sed 's/_/-/ig'`

          - echo $APP_NAME

          - export DEPLOY_BRANCH="deploy-dev"

          - export DEPLOY_TYPE="DEV"

          - export DEPLOY_VERSION="$BITBUCKET_BUILD_NUMBER"

          - export DEPLOY_TAG="$DEPLOY_TYPE-$DEPLOY_VERSION"

          - export IMAGE_NAME=$DOCKER_HUB_USERNAME/$APP_NAME:$DEPLOY_TAG

          - echo "Deploying to environment"

          - cd app/

          - ls -l

          - docker login --username $DOCKER_HUB_USERNAME --password $DOCKER_HUB_PASSWORD

          - docker build -t $IMAGE_NAME .

          - docker push $IMAGE_NAME

          - git config --global user.email email@dominio

          - git config --global user.name "Desenvolvimento"

          - echo ''$BITBUCKET_GIT_SSH_ORIGIN''

          - git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN}

          - cd /opt/atlassian/pipelines/agent/build

          - git clone --branch="$DEPLOY_BRANCH" --depth 5 ${BITBUCKET_GIT_SSH_ORIGIN} /$DEPLOY_BRANCH

          - cd /$DEPLOY_BRANCH

          - sed -i 's/image:\ dockerhubuser.*$/image:\ dockerhubuser\/'$APP_NAME':'$DEPLOY_TAG'/' $APP_NAME-deployment.yaml

          - git add --all

          - git commit -m 'Deploy '$APP_NAME' '$DEPLOY_TAG''

          - git push --set-upstream origin $DEPLOY_BRANCH

    master:

      - step:

          name: Build

          image:

            name: guglio/dind-buildx:latest

            username: $DOCKER_HUB_USERNAME

            password: $DOCKER_HUB_PASSWORD

            email: $DOCKER_HUB_EMAIL

          runs-on: self.hosted

          services:

            - docker

          condition:

            changesets:

              includePaths:

              - "app/**"

          script:

          - export APP_NAME=`echo ${BITBUCKET_REPO_SLUG} | sed 's/_/-/ig'`

          - echo $APP_NAME

          - export DEPLOY_BRANCH="deploy-dev"

          - export DEPLOY_TYPE="DEV"

          - export DEPLOY_VERSION="$BITBUCKET_BUILD_NUMBER"

          - export DEPLOY_TAG="$DEPLOY_TYPE-$DEPLOY_VERSION"

          - export IMAGE_NAME=$DOCKER_HUB_USERNAME/$APP_NAME:$DEPLOY_TAG

          - echo "Deploying to environment"

          - cd app/

          - ls -l

          - docker login --username $DOCKER_HUB_USERNAME --password $DOCKER_HUB_PASSWORD

          - docker run --rm --privileged multiarch/qemu-user-static --reset -p yes; docker buildx create --use --name $APP_NAME

          - docker buildx build -t "$IMAGE_NAME" --platform linux/amd64,linux/arm64 --push .

          - docker buildx imagetools inspect "$IMAGE_NAME"

          - git config --global user.email email@dominio

          - git config --global user.name "Desenvolvimento"


          - echo ''$BITBUCKET_GIT_SSH_ORIGIN''

          - git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN}

          - cd /opt/atlassian/pipelines/agent/build

          - git clone --branch="$DEPLOY_BRANCH" --depth 5 ${BITBUCKET_GIT_SSH_ORIGIN} /$DEPLOY_BRANCH

          - cd /$DEPLOY_BRANCH

          - sed -i 's/image:\ dockerhubuser.*$/image:\ dockerhubuser\/'$APP_NAME':'$DEPLOY_TAG'/' $APP_NAME-deployment.yaml

          - git add --all

          - git commit -m 'Deploy '$APP_NAME' '$DEPLOY_TAG''

          - git push --set-upstream origin $DEPLOY_BRANCH

definitions:

  services:

    docker:

      image: docker:dind

      memory: 3072

 

I appreciate any help.

Best regards,

Carlos

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events