Description of the feature request
Trigger Bitrise workflows based on trigger maps through commands in pull request comments.
Use case / for what or how I would use it
There are cases where it’s beneficial to be able to trigger a workflow without matching on a pull request’s branch name.
- One user might add a pull request without the correct naming scheme and instead of going about recreating the branch and polluting pull request history with multiple incorrect requests, its better to simply trigger the workflow manually.
- A pull request might match on a trigger to run tests on an application but not a trigger that would ship a new beta release for testing. Keeping the discussions in the comments and triggering a build related to the discussion can help keep the discussion on track
- A feature or bug fix could rely on an external feature that would cause a PR check to fail - say downloading a parsing data in a test. In this case you’d need to push a new commit to trigger a build when it’s only the external resource that has changed.
Discussion
Much like other bots and actions it would be nice to be able to manually trigger re-checks or other checks. One way I see this work is to either have a trigger map much like the existing ones but map commands to a workflow instead. However the simplest solution would be to map directly to the PR trigger workflows.
A command could look something like this:
@github-checks feature
@github-checks bugfix
One more advanced way could be supplying environment values just like through the Build Configuration on Bitrise itself. That could be something like this where coverage maps to $COVERAGE or similar:
@github-checks pr-tests coverage:full
@github-checks pr-tests coverage:smoke