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

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

Avatar

1 badge earned

Collect

Participate in fun challenges

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

Challenges
Coins

Gift kudos to your peers

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

Recognition
Ribbon

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!

Leaderboard

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
4,551,667
Community Members
 
Community Events
184
Community Groups

bitbucket-pipelines, pull-request vs merge

I am trying to use bitbucket-pipelines to test and in a separate step deploy,

When a pull-request is created I want to run unit tests. I see that I can do this with the pull-requests feature.

When the code is merged, I want to create a zip and deploy (copy) code to s3

How do I trigger a step when the code is merged?  Not when the pull-request is created.

Do I need to use tags?

1 answer

0 votes
Philip Hodder
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jun 11, 2019

Hello Joseph,

For the workflow you're mentioning, you can use branch pipelines.

For example:

pipelines:
branches:
master:
- step:
script:
- # Create zip and deploy to s3.
pull-requests:
feature-branch-*:
- step:
script:
- # Run unit tests

In this configuration, the zip creation and deployment will only happen when a new commit is introduced to the master branch. i.e. Whenever a feature branch is merged to master. 

It is possible to use tags. But that doesn't sound like it's a part of your current workflow, so it isn't necessary to introduce if you don't need them.

Does that work for you?

Thanks,

Phil

@Philip Hodder The branch pipeline on `master` isn't really a solution for us, because we can't just run the pipeline willy-nilly on any commit to `master`; we need to know something about how that commit originated. Consider:

When a PR from a `release/*` branch is merged into `master`, I would like to run an action that:

  1. Deletes the `release/release-{#}` branch (yes, I know PRs offer the option to close the source branch on merge, but I don't want to leave that up to a human to remember to check that option)
  2. Increments a repository variable representing the release number,
  3. Creates a new `release/release-{#}` branch

I can't hook this action to any commit to `master`, because a hotfix could come in that gets deployed to `master`, and I wouldn't want that change to trigger the release branch-related workflow.

Any suggestions?

Thanks 

Like # people like this

@Max DeCurtins I am looking to do a flow similar to the one described by you. Did you find any solution?

Like # people like this

@Philip Hodder, any workaround to achieve this? 

Like Michael Mersiades likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events