Add triggers based on Github PR labels

#1

Description of the feature request

I would like to be able to trigger a specific workflow based on the label/labels of a PR.

Use case / for what or how I would use it

When using a mono repo for several projects, we specify with labels which project a PR concerns. I would then use the trigger feature on Bitrise to launch the right workflow based on the label.

For a repo with a single project I could also use labels to specify on which environment the PR should be tested or which target of my project it concerns. The trigger feature would allow me to launch the right workflow based on the label.

Thanks for hearing me out, I hope this feature request will interest other users :slight_smile:

0 Likes

#2

Hey!

I’m facing now exactly the same need. It seems this could be done using Github trigger but it’s not so easy as it could be with Bitrise support.

Did you find any workaround in a meanwhile waiting for a feature request?

0 Likes

#3

We would find this EXTREMELY VALUABLE! Currently we are planning on digesting the Github hooks for these in Azure Funcitons and then calling out to the Bitrise API.

The other event we would LOVE is PullRequestReviewEvent. Being able to trigger a workflow on the back of a reviewer’s approval would be magical.

2 Likes

#4

Just a question: what would happen if you don’t add a label to the PR? Or if you change the label on the PR?

In general we favour features which don’t require manual steps like adding the right labels to a PR. I definitely see your point and why this feature would be great, just wondering if we already have a solution for the problem, just not this solution :wink:

@abu_tapptic & @p.val : I believe your use case is that you have a Mono Repo setup. Is that right? Because if it is, then we just released a related feature, for mono repo setups, to make it simple to filter based on paths: https://blog.bitrise.io/build-parts-of-your-mono-repo-separately
Using this you’d register your separate apps/projects as separate apps on bitrise.io but you can specify filters based on paths.

@petergoldsmithasoste definitely sounds interesting, but could you please share a bit more detail / a use case for what you’d like to use this feature? There might be a feature which already exists and can help to achieve what you want to do :wink:

0 Likes

#5

@viktorbenei I saw the mono repo feature but I have a bit different use case. I want to trigger the workflow (that runs the set of code checks and tests) once the PR “ready to be checked”.

Two ways I see now are:

  • a trigger for review status (run on “Approve review” action)
  • the trigger for the label (run on label “Ready to be merged” was set)

Do you see any simple way to achieve this goal?

2 Likes

#6

Is there a reason why you can’t run the CI before you’d add the label?

The reason why we try to automate these on code push is that ideally once you get to do a review, the CI build should already report the status, so that if the PR is accepted it can be merged immediately instead of then waiting for the CI build’s status.

0 Likes

#7

I’m using pricing plan with 1 parallel execution. Sometimes I have more then 1 PR opened and different developers working on them in parallel. Every time they push minor change the build starts and push Slack message at the end.

We use labels in order to highlight that PR is ready for review, so only after the label was set the code checks start to make sense. Everything gunned before is kind of idle use both for us and for Bitrise. Moreover, it spams Slack channel a bit more then I would like.

The perfect case for us could be to run the workflow on PR’s approval or label change. Of course, I’m opened to other solutions.

1 Like

#8

We would like a similar workflow. One particular set of steps for all pushes (unit tests) pre reviewer’s approval. Once the reviewer approves the PR, a second set of steps (our longer running ui test suite) should run, and merge automatically (using Danger for that).

Currently because there is no trigger for us to react to Label addition / comment made / reviewer approval, the final reviewer of a PR needs to logon to Bitrise and trigger the workflow manually, but this has a pitfall of not being a ‘PR’ based trigger, so PR based ENV vars are not available, and it also doesn’t attempt to do the merge into the target branch.

1 Like

#9

@p.val makes sense. Worth to note that there is an existing solution to NOT to start a build, the [skip ci] flag. In case of PRs you can add this to the title of the PR and while it’s in the PR’s title no builds will be started. Related docs: https://devcenter.bitrise.io/tips-and-tricks/skip-a-build/#pull-requests

Once it’s ready for a PR build you can simply just remove the [skip ci] text from the PR title and that will start a build. Not as elegant as a label, but it definitely works and available today :slight_smile:

0 Likes

#10

@asos-petergoldsmith so you actually want to run builds just different builds based on the label. That’s indeed not possible right now.

A workaround for now might be to do a full git flow process, where a PR is merged into an integration branch (usually develop) which can have a more thorough test suite, and then if that passes it can be merged into the release branch (usually master).

Definitely not as elegant as the labels, on the other hand it’s harder to forget about running those additional test suites (should be impossible if the PR target is configured properly) vs forgetting to add the proper label.

Having both options would be even better of course :wink: Thanks for the details!

0 Likes

#11

Trigger by github comment would be amazing.

2 Likes

#12

what’s the status of this feature req?

0 Likes

#13

On our roadmap but no ETA yet @Macarse

0 Likes

#14

Hi , Any updates about this feature ?

0 Likes

#15

Hi @moataznabil! Still don’t have an ETA, but it continues to be on our roadmap. Thanks for your inquiry.

0 Likes