How to change the check name of the bitrise ci on Github

Question & Answer
1

How do I change the check name in Github?

During my test from my first app that was setup it says ci/bitrise/fsa98f7s7sbans/pr — In progress - myAndroidApp

Can I change this to say something custom instead of an ugly name?

2

Not possible to change in the default / built in status reported. The app’s slug is included in the check name because you can register the same repo multiple times on bitrise.io

You can use the GitHub Status step if you want to specify another name, but as that’s a step which runs during the build it can’t report events which happen before or after the build (e.g. “on-hold” or “aborted”).

3

Interesting. I find it weird that I can’t change the step name. I understand the reasoning, but would definitely like to have a non ugly name.

Maybe you can help. My goal is to have these on github

Step 1: build - success/fail
Step 2: test - success/fail
Step 3: deploy apks success/fail

Are you saying it’s possible to change my primary workflow to add those steps?

4

I think the confusion comes from that you think it reports step statuses @coltonidle

The status report is for the whole build, not for individual steps. It reports when the build starts, and then reports the build’s result (success/failed/aborted).

5

What would I do if I wanted the github UI actually show those steps though?

I think it’s a reasonable ask to have github show the following:

Build apk pass/fail
Run tests pass/fail
Deploy apks pass/fail

Are you saying that that’s not really what I should be doing? I was mostly copying something you would see here: https://github.com/tensorflow/tensorflow/pull/17414

6

If you’re referring to:

26

I believe these are separate builds, similar if you’d build the same repo with multiple Xcode versions or something like that.

That said, feel free to create a #feature-request ! :slight_smile:

7

Interesting. I’d be fine setting setting things up as separate builds also, but I’m really after the clarity and human readable names of these steps. That’s why I’ve been using the Github Status Step to emulate this sort of behavior.

1 Like
8

Sure, using that step is also fine :slight_smile:

9

It seems that the same effect can be achieved using existing bitrise features even in single build, but in very indirect way.

Firstly you need to mark a step (source of the status check) as skippable (in bitrise.yml since graphical workflow editor does not support it yet). Then add a script step which exports environment variable (using envman) with one of the values accepted by GitHub status step (success or failure) depending on aforementioned step result and finally pass that variable as set_specific_status input value (not possible in workflow editor but can be done in bitrise.yml) of GitHub status step.

10

That’s a neat idea @koral! I think it can be even simpler: you don’t have to mark the step with skippable, just add a GitHub Status step after every step you want to report and change the status_identifier input to e.g. the Step’s name/id.

Something like:

steps:
- step1: {}
- github-status:
    inputs:
    - status_identifier: Step1
- step2: {}
- github-status:
    inputs:
    - status_identifier: Step2
11

But if step is not skippable and it fails it will cause whole build failure. It maybe not wanted in all the cases.

12

I think that’s independent from the status reporting, both should work for different purposes. Depends on whether you want the build to be marked as failed (e.g. in the build list page) at the end of the build.

13

I’ve created my first 3 steps to be github status steps and they report pending. Then after each of my steps that I care about, I create another github step with the same name as one of the first three that I define and submit the current status there. Seems to work well.

1 Like