Document a workaround to run another workflow (#67)

See #65

README.md

@@ -34,3 +34,17 @@ jobs:
 ## Restricting who can call the action
 
 It's possible to use `author_association` field of a comment to restrict who can call the action and skip the rebase for others. Simply add the following expression to the `if` statement in your workflow file: `github.event.comment.author_association == 'MEMBER'`. See [documentation](https://developer.github.com/v4/enum/commentauthorassociation/) for a list of all available values of `author_association`.
+
+# Running multiple GitHub Actions workflows
+
+If you have another workflow setup that for example executes unit tests, and that workflow is a required status check that needs to pass before merging, you may find the check in "waiting" status after `/rebase`. Unfortunately, that's a current Actions limitation, see [this community post](https://github.saobby.my.eu.orgmunity/t/triggering-a-new-workflow-from-another-workflow/16250/33) and/or [#65](https://github.com/cirrus-actions/rebase/issues/65) for more details.
+
+However, one possible workaround is to setup your test workflow to run also on [pull request review events](https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#pull_request_review) like:
+```
+on: [push, pull_request_review]
+```
+Then for example approving a code review will start, run and finish the test workflow and you'll be able to merge the pull request (if the check passes).
+
+GitHub can also optionally dismiss an existing review automatically after rebase, so you'll need to re-approve again which will trigger the test workflow.
+Set it up in your repository *Settings* > *Branches* > *Branch protection rules* > *Require pull request reviews before merging* > *Dismiss stale pull request approvals when new commits are pushed*.
+