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

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

When the default pipeline is triggered it only takes the last commit into consideration.

I do a modification in my local copy of the repository and commit the change to the local repository into a new branch. Then i do some more corrections and commit those changes to the same branch. Now my local branch has two commits done to two separate files in the repo. Then i push the local branch to the remote repository.

Now the default pipeline gets triggered. But i see that the default pipeline is triggered only one the last commit that was done to the branch and it does not include the first commit.

Depending on what files are changes in a commit i have  change sets in place to trigger different builds in the default pipeline. So when my branch that was pushed contain changes to two different files done in two different commits i expect that both builds would get executed because  there were two changes. But in this case only the last commit was picked and only that build will get executed.

How can I overcome this behaviour, because i need all the builds to be triggered that matches the change sets when i do a push.

Here is an extract of my pipeline:

default: #This will build and push the modified container image
- parallel:
- step: &build_ifs_secrets_handler
name: build_ifs_secrets_handler
- export COMMIT_VERSION=`echo ${BITBUCKET_BRANCH} | sed 's/\///g'`
- HOST_UID=`id -u` TRACE=true ./
- ifs/secret-handler/**
artifacts: # results of the security scan
- ifs/pipeline_scripts/*.txt
- docker
- docker
- step: &build_ifs_base_image
name: build_ifs_base_image
- HOST_UID=`id -u` TRACE=true ./
- ifs/base/**
artifacts: # results of the security scan
- ifs/pipeline_scripts/*.txt
- docker
- docker
- trivycache


So if my first commit had change done to ifs/secret-handler/** and my second commit had changes done to ifs/base/** i want both pipelines to be triggered when the branch is pushed with those two commits. 

But what happens now is only the second commit gets triggered and only the pipeline build_ifs_base_image gets executed.

1 answer

1 accepted

0 votes
Answer accepted
Theodora Boudale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Sep 26, 2022

Hi @Prabha Ranaweera,

In a pull-request pipeline, all commits are taken into account, and if you provide an includePathlist of patterns, a step will be executed when at least one commit change matches one of the conditions.

For other types of pipelines, like the default one you are using, only the last commit is considered. I'm afraid there is no way to change this at the moment.

This is mentioned in our documentation here:

We have a request in our issue tracker to change this and consider all commits of a certain push:

Please make sure to vote and comment on it to give it more weight and further express your interest.

In the meantime, one thing you could do is push commits one at a time. This should be fine for pull request merge commits in your default main branch for example, but if you push multiple commits to a branch at the same time or if you push multiple times to a given branch you might experience non-intuitive behavior when failing pipelines turn green only because the failing step is skipped on the next run.

Kind regards,

Thank you for the response. I have voted for Hopefully this will be taken up and fixed soon.



Like Theodora Boudale likes this

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events