Here is another post that has to do with my current company migrating CI systems, from Bitrise into Github Actions. While on Bitrise we had workflows that would trigger (fork) more workflows. This worked well for us to trigger our android, iOS and Huawei builds with a single click.
Unfortunately, after migrating to Github Actions, it’s not quite clear how to achieve the same. There are some posts on the forums that point to old answers using personal tokens. I lost some time googling around, so I thought I might save the next guy time.
In the past Github prevented triggering workflows from other workflows to prevent recursive triggers. However at some point they added another trigger, so instead of dispatching a build from a parent, you declare a dependency on the child workflow.
Here is an example of a parent workflow:
name: Fork production builds on: workflow_dispatch jobs: say_hi: runs-on: ubuntu-latest steps: - name: Hi run: echo "Hi"
You need to have jobs with a step, otherwise github complains, but this entire workflow runs in less than a second.
and on the child workflow, you just add it to the triggers
name: Android HMS Production on: # Automatic trigger when pushing tags # push: # branches: # - "!*" # tags: # - 'v*' # Manual trigger from the UI workflow_dispatch: inputs: message: description: 'Build description' # Dependency to a forking workflow workflow_run: workflows: ["Fork production builds"] type: - complete
The ‘complete’ type is just so that this workflow triggers after the previous one has been completed.
That’s it, now when you trigger the “Fork production builds” (from the github UI), the child (or children) process will run.
If you want even more details about your CI builds and workflows on github, you should check CI Demon, it’s an app that I made that puts your builds right on your mac Desktop.