It’d be great to have status badges per workflow to separate status for distinct targets (acceptance tests & unit tests, for example).
Just wanted to mention that per-branch badges are available, but of course per-workflow ones might also be useful.
Thanks for the #feature-request!
I think this is very useful.
I have a workflow that is triggered by a github pull request.
In this case, if all test pass, the build it will pass.
I would use this to create a table of:
| Build | iPhone 8 | iPhone X | iPad Air | iPad Pro |
alpha | pass badge | fail badge | pass | fail |
beta | …
prod | …
I.e. each badge would be based on a specific workflow (in this case, a scheduled nightly build)
Just want to amplify this. Since we have a “test” and a “deploy” workflow, and the “deploy” workflow triggers on tags, the status badge shows the status of the last “deploy”, not the latest build in the master branch. The status badge is essentially useless for us.
It’s likely that tags should not be included in the status of a branch for the status badge. But the ability to specify a workflow name would do the job well enough.
For users with a monorepo configuration, containing multiple apps, the status badge without the ability to pass a specific workflow id unfortunately doesn’t provide much value
Thank you for reaching out to Bitrise Support.
Can I have the use case for this feature so that I can get that to the Product Team?
Hi @chaitanya.tanna, thanks for your reply.
In our monorepo, we build each one of the 2 apps using 2 different workflows. We have
Pro-OnCommit, which are triggered per push in the
develop branch, besides the release branches which run 2 other workflows. I wanted to have in our repository the badges for each one of the workflows. Currently, the badge for
develop returns the state of the last build, but this doesn’t say much. Passing a Workflow ID (by itself or together with a branch name) is essential for achieving this.
Also, if the status.json API would be able to receive a workflow (with or without a branch name), creating dashboards would be much easier to do than building the same with the current build APIs.
Hope that’s clear