Introduction

In a mono repository containing multiple applications, each app typically has its own set of GitHub Actions workflows. However, when you push changes to the branch, all the workflows defined in the repository will run from scratch by default, irrespective of which specific application the changes were made to.

This article presents an approach to enhance workflow separation in a mono repository, allowing each push to trigger only the workflows related to the specific app with changes, while leaving unaffected workflows untouched. By achieving this decoupling, each app's development becomes independent of the other apps, streamlining the CI/CD process and promoting efficient code management in the mono repository setting.

Mono-Repo Structure

For instance, consider a mono repository housing five distinct apps (ums, ims, nms, oms and pim), each with its unique set of files and dependencies. Additionally, all the separate workflows reside within the same .github folder. The following represents the structure of the mono repository:

mono-repo/
├── .github/
│   └── workflows/
│       ├── ums-ci-cd.yaml
│       ├── ims-ci-cd.yaml
│       ├── nms-ci-cd.yaml
│       ├── oms-ci-cd.yaml
│       └── pim-ci-cd.yaml
├── ums/
│   # ums app files and directories
├── ims/
│   # ims app files and directories
├── nms/
│   # nms app files and directories
├── oms/
│   # oms app files and directories
└── pim/
    # pim app files and directories

Workflow Trigger Configuration

So if you want to ensure that specific workflows only run for specific applications or directories when changes are pushed, you can define conditions within the workflow files to determine when the workflow should be executed. For example, you can use the 'on' and 'paths' options in your workflow YAML to specify which events and paths should trigger the workflow.

Below are examples of the workflows for each of the five different appsmentioned above (ums, ims, nms, oms, and pim):

ums-ci-cd.yaml:

name: ums-ci-cd

on:
  push:
    branches:
      - main
    paths:
      - 'ums/**' # This will trigger the workflow only for changes in the 'ums' app directory

jobs:
  build-and-deploy:
    # ... (add your build and deployment steps here)

ims-ci-cd.yaml:

name: ims-ci-cd

on:
  push:
    branches:
      - main
    paths:
      - 'ims/**' # This will trigger the workflow only for changes in the 'ims' app directory

jobs:
  build-and-deploy:
    # ... (add your build and deployment steps here)

nms-ci-cd.yaml:

name: nms-ci-cd

on:
  push:
    branches:
      - main
    paths:
      - 'nms/**' # This will trigger the workflow only for changes in the 'nms' app directory

jobs:
  build-and-deploy:
    # ... (add your build and deployment steps here)

oms-ci-cd.yaml:

name: oms-ci-cd

on:
  push:
    branches:
      - main
    paths:
      - 'oms/**' # This will trigger the workflow only for changes in the 'oms' app directory

jobs:
  build-and-deploy:
    # ... (add your build and deployment steps here)

pim-ci-cd.yaml:

name: pim-ci-cd

on:
  push:
    branches:
      - main
    paths:
      - 'pim/**' # This will trigger the workflow only for changes in the 'pim' app directory

jobs:
  build-and-deploy:
    # ... (add your build and deployment steps here)

Explanation:

• Each workflow file is named appropriately for the respective app it belongs to (e.g., ums-ci-cd.yaml, ims-ci-cd.yaml, etc.).

• The 'on' section specifies that the workflow should be triggered on any 'push' event to the main branch.

• The paths field within the on section is the key to triggering the workflow only for changes in the specified app's directory. We use a glob pattern to specify the path to the app's directory, followed by /** to include all files and directories within that app's folder.

• For example, in ums-ci-cd.yaml, the paths field is set to 'ums/**'. This means that any changes made within the ums app's directory will trigger the ums-ci-cd.yaml workflow. Similarly, for other apps, their respective workflows will be triggered when changes occur within their corresponding directories.