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
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.
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
@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
@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)
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.
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.
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.
@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
@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 Thanks for the details!
