Add triggers based on Github PR labels

#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:

1 Like
#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.

3 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
#16

Is there any update on this?

0 Likes
#17

Sorry - no ETA at this time.

0 Likes
#18

Any ETA for this feature? I think its been 2 years.

0 Likes
#19

Hi guys, do we have any update on this? It would definitely improve our workflow :slight_smile:

2 Likes
#20

Any update? I would love to use this feature.

0 Likes
#21

@cathy.harmon @ahvth-bitrise

is there any update on this feature? we’d love to trigger builds via adding a label to a specific PR, rather than every single pull request

0 Likes
#22

I’d love this feature if available, jakarta barat
best regards

0 Likes
#23

for the time being, I’ve created a GH Action to implement this feature. hopefully this helps anyone looking for this feature for now.

name: Check for Bitrise Label

on:
  pull_request:
    types: [labeled, synchronize]

jobs:
  deploy:
    name: Trigger Build with Label
    runs-on: ubuntu-16.04

    steps:
      - name: Get the pull request number
        id: pr_number
        run: |
          echo ::set-output name=number::$(echo "$GITHUB_REF" | awk -F / '{print $3}')
      - name: Send mobile build on bitrise
        if: contains(github.event.pull_request.labels.*.name, 'Build Bitrise')
        run: |
          curl https://app.bitrise.io/app/YOUR_APP_ID/build/start.json --data '{
            "hook_info":{
              "type":"bitrise",
              "build_trigger_token":"YOUR_BUILD_TOKEN"
            },
            "build_params":{
              "branch":"${{ github.head_ref }}",
              "workflow_id":"deploy-internal",
              "commit_hash":"${{ github.event.pull_request.head.sha }}",
              "pull_request_id": ${{ steps.pr_number.outputs.number }}
            },
            "triggered_by":"curl"
          }'
0 Likes