Trigger Another Repository's Github Action Workflow and Wait for Result
In this lesson, I will walk you through triggering a workflow in a second Github repository. The most common use case is probably for triggering a single batch of tests while your code base is divided among multiple repositories. Another great use is triggering deployments of your API (in its own repo) before deploying your frontend (web app). This can be done fairly simply with a Github Action called Trigger Workflow and Wait.
Full transparency: I created this Github Action for Convictional and an internal use case. Its been made open-sourced to help others out. I would appreciate it if you enjoy it, please star it. Thanks!
High Level Explanation
Required arguments are (pulled off README):
The owner and repository are pretty clear. The Github token is a personal access token. A user must trigger a workflow. The workflow name is because we want to trigger a specific workflow.
The optional arguments is:
In my words:
wait_intervalis the pauses between checking the workflow status. It's measured in seconds. If you know your second workflow will take 10+ minutes to complete, there is no point in checking every second. You should just set it to check every 60 seconds.
GITHUB_REF(the hash that represents a branch or commit).
inputsis any inputs for trigger client payload.
propagate_failureallows you to toggle if you want to return errors to the original workflow that triggered.
trigger_workflowallows you to toggle if you want to trigger the second workflow. You may just want to watch for the results of it.
wait_workflowallows you to toggle if you want to wait for the output.
More Detailed Explanation
I'm going to explain how the actual code works. If this doesn't matter to you, feel free to skip.
The entrypoint is:
validate_args verifies you have the required arguments.
trigger_workflow is called. It calls the Github API using your personal access token, and event type:
The last step is
wait_for_workflow_to_finish. The code grabs the status of last workflow run. If its
pending, then it waits based on the wait interval. Otherwise, its
success. If its
failure, it exits with a
1 exit code. On success, it continues.
The code really isn't complicated. The Github Action is a nice interface. Next a demo!
I will create two repositories. The first one is the
web-app and the second repository is
web-api. I want to trigger a "deployment" on the API on each code merged into the master of "web-app".
Start with creating the API repository.
Clone the repository and open up the codebase in an editor.
In your editor, create a new file
Create another file
Push your changes to master.
If you navigate to your Actions tab, you should see the workflow run. This ran on push to master.
Now it's time to setup the second repository. This will be called
demo-web-app and it will build, trigger the API's deploy workflow, and if passes continue onto its own deployment. Start by creating a new repository.
Again, clone it to your local machine.
Open in your favourite editor. Create a
.github/workflows/deploy.yml file and put the following in it:
Before you push this code up to master, you will need to setup a personal access token on the repository's secrets. Two differences from the README that is provided (It will probably be updated soon). First, there is no version on the
uses so we add it on:
email@example.com. You can also use
master which looks like:
convictional/trigger-workflow-and-wait@master. The second, we changed secret name from
G_ACCESS_TOKEN. I received this error when trying to add the secret:
You can create a personal access token by heading over to settings.
On the left side, you should see
Personal Access Tokens and
Generate New Token.
You will need to give it a name. The token requires repo access and actions access.
You personal token is created! Take note of the new token. Do not lose it or you will have to regenerate it. Next, it is time to add secrets. Go to the repository, open settings, and open
New Secret, you can add the name and value. The name would be
G_ACCESS_TOKEN. The value is your new personal access tokens.
You are all setup! Now time to push the code to your remote repository.
Actions tab, and see your new run. It will run on push to master.
If you open your first repository Actions, you should see it get triggered by the web app.
When the API is successful, it will return to the web app.
You are all setup!
That is it! Thats the general overview of triggering one repo from another. Github Actions is a really nice way of interfacing with the API. Thanks for reading!