We released a new version (1.1.0) of GitHub Status step.
Changes:
-
New input:
status_identifierallows to differentiate this status from the status of other systems.
1 Like
Would it be possible to add some documentation on how to use the github status step? I’m new to bitrise and am looking forward to improving the status on github to include some of the subtasks in my PR workflow. For example, if my PR workflow builds my app, runs all the tests, and deploys the apks, I want 3 steps in github that say that, with all of the right status values, but I don’t know how to do that.
@coltonidle that’s a bit out of scope for the step I think. I mean you can add as many as you want, but the purpose of the status report is to report the status of the build, not the status of individual steps.
I guess you use the status report on PRs to decide whether the PR can be merged or not. If the build is successful it can be merged, if it fails it can not. In this use case that would be the advantage of per-step status report? I mean if any of those steps fail you will check the build and the PR can’t be merged, right? So it doesn’t really matter whether there’s a per-step status report or a single report of the build’s final status, as far as I can see.
But I might be wrong of course, would love to hear the use case for per-step status reports! Sounds interesting 
A few examples for Android projects:
- Static code analyisis like detekt, it is still in release candidate, so may report false positives. One may want to merge a PR even there are some false issues reported.
- UI tests - if e.g. one of tests fails on one of the devices one may decide to fix it later.
In such cases it is convenient to have overall build status separated from some per-step statuses.
Thanks @koral!
Definitely see your point but:
Mark the step as skippable if you don’t really care about whether it failed or not.
You should still check which test failed and decide based on it. I wouldn’t recommend you to not to check the UI tests just because “those are usually failing / flaky”. You should either fix that or mark the step as Skippable if you don’t care.
Maybe it’s just me but I think the status should indicate whether the PR can be merged or not, and even enforce it (e.g. by using GitHub protected branches so that it can’t be merged). I mean a failing test which no one check / is ignored every time is just noise, for which “Skippable” is a better solution IMO
Docs for Skippable / is_skippable: http://devcenter.bitrise.io/tips-and-tricks/dont-mark-build-failed-if-step-fails/
But again it might be just me, that I miss something
In any case, feel free to create a #feature-request for this, as this is just a step update’s changelog entry, not the ideal place for a thread which should be kept for longer discussion - yeah it was my mistake asking this here, I know 
And of course thanks for the feedback, both @koral & @coltonidle! A friendly debate is always welcome
Maybe you could split this thread?
Right, but it is only part of a solution. Build does not fail but you don’t have easily available info what has failed.
Here is what I talked about:
In this case codecov and sonarqube check results are generated outside bitrise but you can have analogous ones produced by some steps.
Maybe “Status” is not a good word for something like that. It is rather “check”.
Got it. If you have some time feel free to create a #feature-request
Not sure if I could just split this thread, as the comments seem to require the context…
Yeah. To me, it’s just more that I don’t want to go to bitrise to figure out what went wrong. It’s hard to figure out what went wrong there for someone that’s not familiar with ci. It’s much easier to show that “Hey building failed” or “unit tests failed”. The dev can go on their local machine and try it. That’s just my two cents instead of the ci being a binary thing even though there are like 5 steps in my ci.