This repository contains several reusable workflows designed to streamline the CI/CD process. The workflows aim to automate tasks such as testing, deployment, pull request management, and code quality checks.

• Purpose: Manages the deployment of technical documentation using Backstage TechDocs.

• Purpose: Runs integration tests for ensuring code stability.

• Purpose: Automates actions based on pull request events such as title validation, code coverage reports, and testing.

• Purpose: Integrates with SonarCloud for analyzing code quality and vulnerabilities.

• Purpose: Manages deployments to various environments based on the branch being deployed.

• Purpose: Manages the execution of Kover, a Kotlin coverage engine, for code coverage on pull requests.

• Purpose: Automates the process of merging pull requests and triggering subsequent deployment steps for staging and production.

• Purpose: Automatically tags releases with a timestamped version.

• Purpose: Automatically creates a pull request to promote changes from develop to staging.

• Purpose: Automatically creates a pull request for promoting changes to the production branch.

This repository provides two deployment patterns to support different Helm chart management strategies:

Helm charts and deployment configurations are managed in the kube-manifests repository.

Workflows:

• deploy-generic.yml - Generic deployment workflow for any service
• deploy-python.yml - Python-specific deployment with testing
• deploy-kotlin.yml - Kotlin-specific deployment with Gradle testing

Use when: Your service's Helm charts live in the kube-manifests repository under apps/{service-identifier}/{stage}/app/.

Helm charts are managed within each service's repository, enabling better service ownership.

Workflows:

• deploy-generic-v2.yml - Generic deployment workflow for service-repo pattern
• component-deploy-v2.yml - Low-level component that updates service repo charts

Use when: Your service manages its own Helm charts in helm/{service-identifier}/{stage}/app/ within the service repository.

Key differences:

• Charts live in service repository instead of kube-manifests
• Deployment workflow updates service repo's values.yaml with image tags
• ArgoCD config in kube-manifests points to service repo for chart source
• ArgoCD tracks deployments directly from service repo commits (no cluster config updates needed)
• Better service ownership and versioning of deployment configurations

This workflow is triggered by pushes to the develop branch. It automatically creates a pull request to promote changes to the staging branch using the staging-pr.yml workflow.

Example:

name: Auto-create PR to promote develop to staging

on:
  push:
    branches:
      - develop

jobs:
  staging_pr:
    name: Pull request (Staging)
    uses: monta-app/github-workflows/.github/workflows/staging-pr.yml@v2

This workflow listens for comments on pull requests and responds to specific commands. It handles automatic PR merging, staging deployment, production pull request creation, tagging, and deployment based on the command /monta-merge.

Example:

name: Release Workflow Automation
on:
  issue_comment:
    types:
      - created

jobs:
  monta-merge:
    name: auto-merge release pull request
    if: ${{ github.event.issue.pull_request && startsWith(github.event.comment.body, '/monta-merge') }}
    uses: monta-app/github-workflows/.github/workflows/monta-merge-command.yml@v2
    secrets: inherit

  trigger-staging-deploy:
    needs: monta-merge
    if: ${{ needs.monta-merge.outputs.base_branch == 'staging' }}
    # Update this to your deployment workflow, and ensure it runs on workflow_call
    uses: ./.github/workflows/deploy_staging.yml 
    secrets: inherit

  trigger-production-pr-creation:
    needs: monta-merge
    if: ${{ needs.monta-merge.outputs.base_branch == 'staging' }}
    uses: monta-app/github-workflows/.github/workflows/production-pr.yml@v2
    secrets: inherit

  trigger-production-tag-release:
    needs: monta-merge
    if: ${{ needs.monta-merge.outputs.base_branch == 'main' }}
    uses: monta-app/github-workflows/.github/workflows/release-tag.yml@v2
    secrets: inherit

  trigger-production-deploy:
    needs: trigger-production-tag-release
    # Update this to your deployment workflow, and ensure it runs on workflow_call
    uses: ./.github/workflows/deploy_production.yml
    if: ${{ needs.trigger-production-tag-release.outputs.tag_exists == 'false' }}
    secrets: inherit

Use this for services with Helm charts in the kube-manifests repository.

Example:

name: Deploy Staging

on:
  push:
    tags:
      - '*'
  workflow_dispatch:

jobs:
  deploy:
    name: Deploy
    uses: monta-app/github-workflows/.github/workflows/deploy-generic.yml@main
    with:
      stage: "staging"
      service-name: "My Service"
      service-emoji: "🚀"
      service-identifier: my-service
      ecr-repository-name: my-service-staging
    secrets:
      AWS_ACCOUNT_ID: ${{ secrets.INTERNAL_AWS_ACCOUNT_ID }}
      MANIFEST_REPO_PAT: ${{ secrets.PAT }}
      SLACK_APP_TOKEN: ${{ secrets.SLACK_APP_TOKEN }}

Use this for services that manage their own Helm charts in the service repository.

Prerequisites:

• Helm charts exist in your service repo (default location: helm/{service-identifier}/{stage}/app/)
• ArgoCD config in kube-manifests points to your service repo
• values.yaml includes revision and build fields under the image section

Example:

name: Deploy Staging

on:
  push:
    tags:
      - '*'
  workflow_dispatch:

jobs:
  deploy:
    name: Deploy
    uses: monta-app/github-workflows/.github/workflows/deploy-generic-v2.yml@main
    with:
      stage: "staging"
      service-name: "My Service"
      service-emoji: "🚀"
      service-identifier: my-service
      ecr-repository-name: monta/my-service
      # helm-values-path: "helm/staging/app"  # Optional: override default (helm/{service-identifier}/{stage}/app)
    secrets:
      AWS_ACCOUNT_ID: ${{ secrets.INTERNAL_AWS_ACCOUNT_ID }}
      MANIFEST_REPO_PAT: ${{ secrets.PAT }}
      SLACK_APP_TOKEN: ${{ secrets.SLACK_APP_TOKEN }}

values.yaml structure:

kotlin:  # or your chart type
  image:
    repository: 123456789.dkr.ecr.eu-west-1.amazonaws.com/monta/my-service
    tag: latest
    revision: "initial"  # Updated by workflow
    build: 0             # Updated by workflow
    pullPolicy: IfNotPresent

If you are adding new workflows or updating existing ones, please ensure to update this README with descriptions and usage examples for easy integration by other teams. Make sure your workflows follow best practices for GitHub Actions to ensure reliability and maintainability.