How to trigger a workflow from another workflow using GitHub Action

GitHub Actions has revolutionized the way developers and testers automate their workflows. With Actions, developers can easily define and customize their CI/CD processes, enhancing productivity and code quality. One of the powerful features of GitHub Actions is the ability to trigger workflows from another workflow GitHub Actions. In this article, we will delve into the intricacies of mastering GitHub Actions and explore how to trigger workflows from other workflows.

Understanding GitActions and their Benefits:

GitHub Actions is a powerful automation framework integrated into GitHub. It allows developers and testers to define custom workflows composed of one or more jobs, each consisting of various steps. These workflows can be triggered based on events such as push and pull requests, commits, or scheduled actions. The benefits of using GitHub Actions include faster development cycles, improved collaboration, and streamlined release processes.

Defining workflow in GitHub Actions:

Before we delve into triggering workflows, let’s define what a workflow is in GitHub Actions. A workflow is a configurable automated process that runs on GitHub repositories. It consists of one or more jobs, each defining a set of steps. These steps can perform tasks such as building, testing, and deploying code. 

Overview of triggering workflows from another workflow using GitHub Action:

It is important to understand workflow dependencies to trigger a workflow from another workflow. Workflow dependencies refer to the relationships between different workflows, where one workflow triggers the execution of another workflow. By leveraging workflow dependencies, developers and testers can create a seamless and interconnected automation pipeline. 

In complex development scenarios, there is often a need to trigger workflows based on the completion of other workflows. This can be particularly useful when different parts of the development process depend on each other and when different teams collaborate on a project. By triggering workflows from related workflows, developers and testers can automate the execution of dependent tasks, ensuring a smoother development workflow. 

The advantages of workflow interdependency are numerous. Firstly, it allows for a modular and reusable approach to workflow automation. Instead of duplicating steps across different workflows, developers, and testers can encapsulate common operations in one workflow and trigger it from others. This promotes code reusability, reduces maintenance efforts, and enhances overall development efficiency. Moreover, workflow interdependency enables better collaboration between teams working on different aspects of a project, ensuring a seamless integration between their workflows. 

GitHub Action Prerequisites:

• A GitHub repository having a workflow defined in it (repository_01)
• Another GitHub repository (repository_02) has a workflow defined in it that triggers after repository_01 workflow completion.
• GitHub personal access token 

As we have all the required stuff for our goal then let’s get it done. First will understand about GitHub personal access token.

GitHub Personal Access Token (PAT):

Personal access tokens are an alternative to using passwords to authenticate GitHub when using the GitHub API or the command line. Personal access tokens are intended to access GitHub resources on your behalf.

To learn more about GitHub personal access tokens visit the official website of GitHub https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

How to Generate PAT?

1: First, Access your GitHub account by logging in.

2: Navigate to your profile, click on “Settings,” and proceed to “Developers.”

3: Click on Personal Access Token and then Select Token Classic.

4: Navigate to and choose “Generate new token,” then select Generate new token Classic.

5: Here, we Include a note for your Access Token (PAT) – it’s optional. Choose the expiration date for your PAT. Select the scope and at last click on generate token. Copy the token and paste it on a notepad. 

(Remember the selected scope will decide the permissions and authorization to access another repository and workflow)

So now we need to add the generated PAT to our repository_01 as a secret to do this follow the below steps.

• To navigate to your repository, you can click on the settings.

• Then go to secrets and variables then select the Action button.

Select the repository secret, add PAT_TOKEN in the name, and paste the copied personal access token in the value. Click on Add Secret.

Workflow Creation (repository_01):

To create a workflow head over to the action tab and click on new workflow. Then select Set up workflow yourself. Now customize your workflow and add the below step to trigger the (repository_02) workflow.

name: Workflow01
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 600

    steps:
       - name: Checkout to repository
      - uses: actions/checkout@v3

      # Your existing workflow steps
      #  At the end of your all steps add the below step
          
  trigger-workflow02:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Workflow02
        uses: peter-evans/repository-dispatch@v2
        with:
          token: ${{ secrets.PAT_TOKEN }}
          repository: username/repository_02 name
          event-type: trigger-workflow02

Let’s understand the trigger-workflow02 stage. Following is the secret we have added is used here to provide the permissions and the authorization to understand and trigger the workflow_02 of repository_02 also replace the username with your GitHub username and repository_02 name with your other repository name. 

Workflow Creation (repository_02):

As our first workflow is ready now let’s create our second workflow for repository_02. Follow the same steps described in the above step for the creation of a workflow. 

name: Workflow02
on:
  repository_dispatch:
    types:
      - trigger-workflow02
jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
   # your existing steps of workflow

Now let’s understand what to consider here, first the triggering event is set as repository_dispatch means when the other repository is completed this workflow will get triggered and now to specify which repository we arousing types as trigger-workflow02 which is defined as a stage in the workflow01. 

We are done this is how we can trigger the workflow02 of repository_02 when the execution of workflow01 of repository_01 is completed and the status is passed. Below are the output screenshots give it a check.

For Organization Account:

Till this point whatever we have seen it’s for our personal GitHub account and if we want to implement this concept for the organization’s GitHub account then we need to introduce a small change in the workflow01 of the repository_01.

name: Workflow01
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 600

    steps:
       - name: Checkout to repository
      - uses: actions/checkout@v3

      # Your existing workflow steps
      #  At the end of your all steps add the below step
          
  trigger-workflow02:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Workflow02
        uses: peter-evans/repository-dispatch@v2
        with:
          token: ${{ secrets.PAT_TOKEN }}
          repository: organization/repository_02 name
          event-type: trigger-workflow02

Let’s understand the trigger-workflow02 stage. The secret we have added is used here to provide the permissions and authorization to trigger the workflow_02 of repository_02 also replace the organization with your organization’s GitHub name and repository_02 name with your other repository name. 

Conclusion:

In this blog, we have explored the powerful feature of trigger workflow from another workflow using GitHub Actions. By understanding workflow dependencies, leveraging workflow events and triggers, implementing remote triggers, and building scalable workflow chains, developers can enhance their CI/CD processes and workflow automation. To summarize, triggering workflows from another workflow allows for increased reusability, collaboration, and customization of automation processes. By embracing these features, developers can optimize their development workflows and empower their teams to achieve greater productivity and efficiency.

Read More Blogs here.

2