Amina Lawal

IP Addresses & Subnetting - Every device needs an address to communicate

Tue, 01 Apr 2025 13:00:00 GMT

What is an IP Address?

An IP address (Internet Protocol address) is a unique identifier for a device on a network. It’s like your home address but for computers.

Types of IP Addresses:

IPv4 (e.g., 192.168.1.1) – Most common, but limited.
IPv6 (e.g., 2001:0db8:85a3::8a2e:0370:7334) – Newer, more addresses available.

Public vs. Private IP:

Public IP – Unique on the internet (e.g., Google’s 8.8.8.8).
Private IP – Used within a local network (e.g., 192.168.1.1 for your router).

Hands-On Task: Find Your IP Address

Try these commands on your terminal:

Find your public IP (internet IP):

curl ifconfig.me

curl icanhazip.com

Find your private IP (local network IP):

On Linux/macOS:
```
ip a
```
On Windows (Command Prompt):
```
ip config
```

Subnetting (Breaking Down Networks)

What is Subnetting?

Subnetting is dividing a large network into smaller, more manageable networks (subnets). This helps with:

✅ Efficient IP allocation

✅ Better security

✅ Reduced network congestion

IP Address Structure (IPv4)

An IPv4 address has four numbers (octets) separated by dots, each ranging from 0 to 255. Example

Each IP address consists of two parts:

Network Portion – Identifies the network
Host Portion – Identifies a specific device

The Subnet Mask tells us how many bits belong to the network and how many belong to hosts.

Understanding Subnet Masks

A subnet mask determines which part of an IP address belongs to the network and which part is for devices.

Common subnet masks:

Subnet Mask	CIDR Notation	Usable IPs
255.0.0.0	/8	16,777,214
255.255.0.0	/16	65,534
255.255.255.0	/24	254
255.255.255.128	/25	126

Example:

IP Address: 192.168.1.10
Subnet Mask: 255.255.255.0 (/24)
- Network Portion: 192.168.1
- Host Portion: 10
- Usable IPs: 254 (from .1 to .254)

Hands-on Task: Check Your Subnet Mask

On macOS, run:

ifconfig | grep netmask

Understanding the Output

inet 127.0.0.1 netmask 0xff000000

This is the loopback address (127.0.0.1).
It’s used for internal communication within your device (your computer talking to itself).
The netmask 0xff000000 (hexadecimal) is equivalent to 255.0.0.0 or /8 in CIDR notation.

inet 172.20.10.10 netmask 0xfffffff0 broadcast 172.20.10.15

This is your actual private IP address (172.20.10.10).
It belongs to the 172.16.0.0 - 172.31.255.255 range, which is for private networks.
Netmask: 0xfffffff0 (hex) = 255.255.255.240 (CIDR: /28)
- This means your network has 16 total IPs (14 usable: .1 to .14, since .0 is the network and .15 is the broadcast).

What This Means for Your Network

You are on a private network with a small subnet (/28).
Your network can support up to 14 devices (IP range: 172.20.10.1 to 172.20.10.14).
The broadcast address (172.20.10.15) is used to send messages to all devices on this subnet.

Next Steps: Practice Subnetting

Try answering these questions:

If you had a /24 subnet mask (255.255.255.0) instead of /28, how many usable IPs would you have?
Convert 255.255.255.192 into CIDR notation and tell me how many usable IPs it provides.

TERMINOLOGY TO KNOW

What is a Loopback Address?

Loopback address = 127.0.0.1

What does it do?

It lets your computer talk to itself.

Why is that useful?

Testing if your network stack is working.
Running servers or services locally without internet.
Developers use it all the time.

Think of 127.0.0.1 like calling your own phone number—it rings, and you’re the one answering.

What is a Broadcast Address?

It’s a special IP used to send data to every device on the subnet.

Why is it needed?

Let’s say you want to alert every device connected to your network (“hey everyone, please refresh your DNS settings!”) — you send that message to the broadcast address. Everyone on the subnet hears it.

So in /28, broadcast = 172.20.10.15

Exploring Kubernetes with HKE

Fri, 03 Jan 2025 21:00:00 GMT

Managing Kubernetes clusters can be complex and time-consuming. HKE (HostSpace Kubernetes Engine) aims to simplify this process with automated cluster management, built-in monitoring, and intelligent optimization recommendations. Let’s explore how HKE streamlines the Kubernetes experience while providing robust management features.

Prerequisites

Before creating your first cluster, ensure you have:

A server/instance ready for use
SSH key for secure access
Instance username
Basic understanding of Kubernetes concepts

Pro tip: Start by visiting the HKE Settings page to add your instances and SSH keys. This is particularly useful if you manage multiple infrastructure components.

Creating Your First Cluster

HKE’s approach to cluster creation is refreshingly straightforward. Unlike traditional Kubernetes setups that often require extensive configuration, HKE streamlines the process to a few essential steps:

Choose your Kubernetes version
Select or add your instance IP
Provide SSH credentials
Name your cluster
Select your Kubernetes version (1.31 in my case)

Cluster Home Page

Creating a Cluster using Saved Credentials (Instance IP & SSH Keys)

Cluster Creation Completed

What stands out is the minimal input required — HKE handles the complex underlying configuration automatically.

Connecting to Your Cluster

Once your cluster is up, HKE provides straightforward connection instructions:

Download the kubeconfig file
Configure kubectl using the provided commands
Verify connection with kubectl get nodes

A useful tip: Make sure to use the complete context name when switching contexts, as it includes a unique identifier.

Connection instructions from HKE UI

Cluster Creation Completed

Deploying Applications from the Marketplace

HKE comes with a built-in marketplace offering various applications. For this demonstration.

Before deploying ArgoCD, we first needed to set up the Nginx Ingress Controller from HKE’s Marketplace. This is a crucial component because:

It acts as the traffic manager for your cluster
Enables domain-based routing using .nip.io
Allows external access to applications running in the cluster

Navigate to the Marketplace tab
Locate Nginx Ingress Controller & ArgoCD in the available applications
Click Install — HKE handles all the underlying complexity

HKE Marketplace

Quick Verification with Port Forwarding

Before setting up external access, it’s good practice to verify your deployment using port forwarding:

kubectl port-forward svc/argocd-server -n argocd 8080:443

This allows you to quickly access the UI at https://localhost:8080

Generating password for ArgoCD & Port Forwarding

Local Host ArgoCD UI accessed with Port-forwarding

Setting Up External Access

In our case:

HKE Marketplace automatically deployed the Nginx Ingress Controller
Created ingress rules for ArgoCD
Configured domain access using .nip.io for convenient URL access

Since we’re running in an environment without a LoadBalancer and we didn’t set up MetalLb, we needed to switch to NodePort:

kubectl patch svc nginx-ingress-ingress-nginx-controller -n default -p '{"spec": {"type": "NodePort"}}'

This change allows external traffic to reach our ingress controller through a specific port on the node.

After configuring NodePort, access ArgoCD through.

http://argocd.YOUR-NODE-IP.nip.io:NODEPORT

Where NODEPORT is the port assigned by Kubernetes (in our case, 31043)

Successfully deployed ArgoCD interface

Security Considerations

For production environments, consider these additional security enhancements:

Enable SSL redirect
Configure backend protocol as HTTPS
Implement proper certificate management

What Makes HKE Stand Out

Simplified Management: The one-click deployment of complex applications like ArgoCD shows how HKE abstracts away Kubernetes complexity
Intelligent Monitoring: Built-in resource tracking, security monitoring, and advisory systems provide comprehensive cluster insights

Security Events

HKE Advisory

Automated Best Practices: From ingress configuration to resource optimization recommendations, HKE guides you toward Kubernetes best practices
Clear Visibility: The dashboard provides immediate insights into cluster health, resource usage, and potential optimizations

General Cluster Dashboard

HKE simplifies Kubernetes deployment and management while maintaining flexibility for customization. The marketplace feature particularly stands out, making application deployment a streamlined process.

Key takeaways:

Easy cluster creation and management
Rich marketplace of applications
Automated ingress configuration
Flexibility to adapt to different infrastructure requirements

The platform’s ability to automatically handle complex tasks while providing comprehensive monitoring and optimization recommendations makes it a compelling choice for teams looking to streamline their Kubernetes operations.

Get started here today!

Advanced Secrets Management for CI/CD Pipelines with Doppler and GitHub Actions

Tue, 16 Apr 2024 21:00:00 GMT

In the dynamic field of software development, integrating effective tools is crucial for maintaining a secure and efficient workflow. Doppler is a secrets management platform that helps teams securely store and manage their environment variables and other sensitive data. GitHub Actions is a CI/CD solution that automates workflows to run tasks, such as testing and deploying code, directly from GitHub. Together, they provide a robust solution for automating deployments and managing secrets securely across multiple repositories. This integration not only simplifies the management of secrets but also enhances the security and consistency of your deployment processes.

Why Use Doppler with GitHub Actions?

Doppler provides a seamless way to integrate secrets management into CI/CD processes, significantly enhancing the security and efficiency of these pipelines. By centralizing secret storage and tightly controlling their distribution, Doppler prevents the accidental exposure of sensitive data across development stages, from testing to production. This integration ensures that sensitive data, such as API keys and credentials, are managed securely and are only accessible to authorized systems and personnel.

Getting Started with Doppler and GitHub Actions

Prerequisites

Before you begin integrating Doppler with GitHub Actions, ensure you have the following:

A GitHub Account: You should have owner access to one or more repositories. Create a GitHub account if you don’t have one.
A Doppler Account: Necessary for managing and syncing secrets across your projects. Sign up for Doppler.
Familiarity with GitHub Actions: Basic understanding of how to configure and manage workflows. For a quick overview, refer to the GitHub Actions documentation.

1. Integrating Your Repositories with Doppler

Step 1: Doppler Setup

For each repository you wish to integrate, follow these steps:

Log into your Doppler dashboard.
Create a Project: This will be your central space for managing secrets. Set up a new project for each application or service you deploy using GitHub Actions. Organize your secrets within this project by environment (development, staging, production) to streamline access and enhance security.
Select “Integrations” and choose GitHub as your integration service.
Follow the prompts to authorize Doppler to access your GitHub repositories.
Choose a repository to integrate and configure the secrets you want to sync.

2. Configuring GitHub Actions Workflows

For each repository, create or ensure a .github/workflows directory exists at the root with a YAML file defining your CI/CD workflow. This file should specify the actions to be taken (e.g., build, test, deploy) and configure triggers for repository_dispatch or workflow_dispatch events, depending on your operational needs.

Repository Dispatch: Triggers workflows on custom repository events.

File: repository_dispatch.yaml

name: Dispatch Event for Doppler
on:
  repository_dispatch:
    types: [deploy_event]
jobs:
  process_dispatch:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Run Custom Script
        run: |
          echo "I worked!"

Workflow Dispatch: Allows you to run workflows manually or via API calls.

File: workflow_dispatch.yaml

name: Handle Dispatch Event for Doppler
on:
  workflow_dispatch:
jobs:
  process_dispatch:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Run Custom Script
        run: |
          echo "I worked!"

repository_dispatch is ideal for automated scenarios where external events (like a tool or service hook) trigger the workflow.
workflow_dispatch provides flexibility to trigger workflows manually or programmatically, offering control when deployments are more sensitive or require timing.

3. Setting Up Webhooks in Doppler

Doppler webhooks will trigger your GitHub Actions workflows upon changes to your secrets.

Creating a Webhook for Each Repository

In Doppler, navigate to the “Webhooks” section within your project’s settings.

Configuration Steps:

URL: Set this to the GitHub Actions trigger endpoint.
- For repository_dispatch, use:
```
https://api.github.com/repos/OWNER/REPO_NAME/dispatches
```
- For workflow_dispatch, adjust the URL to target the specific workflow within the repository. Please note that the WORKFLOW_ID is the name of the workflow; e.g. main.yaml
```
https://api.github.com/repos/OWNER/REPO/actions/workflows/WORKFLOW_ID/dispatches
```
Authentication: Ensure each webhook is authenticated with a GitHub Personal Access Token (PAT) that has repo workflow permissions.
- Choose “Bearer Token” for authentication.
- Input the PAT you generated.
JSON Payload:
- The payload varies based on the event type (repository_dispatch or workflow_dispatch) and the data your workflow expects.
- For repository_dispatch:
```
{
  "event_type": "deploy_event",
  "client_payload": {
    "unit": false,
    "integration": true
  }
}
```
- For workflow_dispatch:
```
{
  "ref": "develop"
}
```
- Adjust the “ref”, and “event_type” as needed for your specific workflows. The “ref” is to reference the branch name the workflow is on

Common Issues:

Webhook Failures: Ensure the PAT has appropriate permissions.
Workflow Errors: Verify YAML syntax and ensure all required secrets are correctly referenced in Doppler.

4. Testing Your Integration

After configuring webhooks in Doppler, test the integration by updating a secret in Doppler and verifying that it triggers the appropriate workflow in GitHub Actions. Check the “Actions” tab in your GitHub repository for execution details.

Actions triggered with both workflow & repository triggers.

Conclusion

Integrating Doppler with GitHub Actions across multiple repositories enhances your CI/CD pipelines by automating deployments and securing secrets. By following the steps outlined above, you can ensure consistent, secure, and efficient workflows across all your development projects.

Remember to maintain security best practices by managing access permissions carefully and regularly reviewing your integration setup for any potential improvements.

Resources

Deploying Actions Runner Controller for Cost-Efficient GitHub Actions

Sun, 21 Jan 2024 16:00:00 GMT

GitHub Actions is a powerful tool for automating workflows within your software development lifecycle. While GitHub offers hosted runners to execute these workflows, they can incur significant costs, especially for frequent or resource-intensive jobs. Actions Runner Controller (ARC) emerges as a solution to manage self-hosted runners on your Kubernetes cluster, offering cost savings, autoscaling capabilities, and seamless integration with GitOps practices.

Why Use ARC?

Cost-Effectiveness: Self-hosted runners often cost less than hosted runners, especially for long-running or high-resource jobs. ARC allows you to leverage your existing infrastructure, potentially saving you money.
Autoscaling: ARC automatically scales runners up and down based on demand, ensuring efficient resource utilization and avoiding unnecessary costs.
Increased Security: GitHub self-hosted runners can be configured to run on your servers, which provides an extra layer of security compared to using shared runners. This helps to protect sensitive information and data in your workflows.
Greater Control: Self-hosted runners give you complete control over the resources and environment used for your workflows, which can help you optimize performance and ensure that your builds and deployments run smoothly.

In this tutorial, we will show you how to set up GitHub’s ARC on Kubernetes using Helm, then create and run a workflow that uses runner scale sets. For more information about runner scale sets, see “Deploying runner scale sets with Actions Runner Controller.”

If you are looking to secure your Actions Runner Controller (ARC) environment, get in touch with Hostspace.

Step-by-Step Guide

Prerequisites

Basic understanding of Kubernetes, Git, and GitHub Actions
A Kubernetes cluster with ArgoCD installed
Helm installed on your local machine

1. Prepare the ARC Charts Repository:

Create a New Repository

You need to create a dedicated repository to store the Helm charts for this specific deployment. You can create this repository on GitHub within your organization or on any other Git hosting platform you prefer.
For clarity, let’s assume you call this new repository gh-arc-scale-set-charts.

Clone the Base Repository

Next, clone the actions/actions-runner-controller repository to your local machine. This repository contains the base files needed for deploying ARC. We only need the below folders.

#Link to the gha-runner-scale-set-controller folder
https://github.com/actions/actions-runner-controller/tree/master/charts/gha-runner-scale-set-controller

#Link to gha-runner-scale-set-controller folder
https://github.com/actions/actions-runner-controller/tree/master/charts/gha-runner-scale-set

Now, you need to copy the contents of the cloned actions-runner-controller directory into the local directory of your newly created gh-arc-scale-set-charts repository.
Finally, push the local gh-arc-scale-set-charts repository.

2. Create ArgoCD Applications:

Once you’ve prepared your custom gh-arc-scale-set-charts repository, it’s time to tell ArgoCD how to deploy and manage your ARC components. This involves creating two ArgoCD applications, one for the gha-runner-scale-set-controller and one for the gha-runner-scale-set.

Recommended Approach: Using a Connected Git Repository

Use the provided manifest files (gha-runner-scale-set-controller.yaml and gha-runner-scale-set.yaml), adjusting values as needed.

Create the gha-runner-scale-set-controller Application

name: This defines the name of your ArgoCD application, in this case, gha-runner-scale-set-controller.

namespace: This specifies the namespace where the application resources will be deployed. In this example, it’s argocd.
destination: This defines the Kubernetes cluster and namespace where the resources will be deployed. Here, it points to the arc-systems namespace in the default Kubernetes cluster.
project: This defines the ArgoCD project the application belongs to. Usually, you’ll use the default project.
source: This section specifies the location of the manifest files.
repoURL: Replace this with the URL of your gh-arc-scale-set-charts repository.
targetRevision: This specifies the Git revision to use. Typically, you’ll use main.
path: This points to the specific directory within the repository containing the manifest files. In this case, it’s ./gha-runner-scale-set-controller.
syncPolicy: This defines how ArgoCD will manage the application’s state.
automated: Enables automatic syncing with the Git repository.
prune: Removes resources that are no longer present in the repository.
selfHeal: Attempts to fix any discrepancies between the desired and actual state.
syncOptions: Additional options for syncing. In this case, CreateNamespace=true ensures the arc-systems namespace is created if it doesn’t exist.
githubConfigUrl: Specifies the URL of your GitHub repository, organization, or enterprise where the runners will operate. Example: https://github.com/your-organization
githubConfigSecret: References a Kubernetes secret containing credentials for authenticating with GitHub.
To enable ARC to authenticate to GitHub, generate a personal access token (classic) or GitHub App. For more information, see Authenticating to the GitHub API.
maxRunners: Sets the maximum number of runners that can be scaled up in the cluster. Example: 5
minRunners: Specifies the minimum number of runners that should always be available. Example: 1
controllerServiceAccount: Configures the service account used by the ARC controller to manage runners.
namespace: Identifies the namespace where the service account resides (usually arc-systems).
name: Specifies the name of the service account (usually actions-runner-controller-gha-rs-controller).

Key Point:

Carefully adjust these values to match your specific environment and requirements.
Ensure the githubConfigSecret exists in your Kubernetes cluster with the appropriate credentials.

3. Authentication Configuration:

In the gha-runner-scale-set Helm values file, choose your authentication method:

PAT: Use a personal access token (PAT) with appropriate permissions.
GitHubConfigSecret: Create a Kubernetes secret containing GitHub app credentials

To enable ARC to authenticate to GitHub, generate a personal access token (classic) or GitHub App. For more information, see Authenticating to the GitHub API.

Reference the secret in the githubConfigSecret field of the Helm values.

5. Deploy the Applications:

If you’ve wisely connected your gh-arc-scale-set-charts & your manifests repository to ArgoCD, the deployment process is remarkably streamlined! ArgoCD will automatically detect changes in your repository and initiate syncs without requiring manual commands.

Here’s a brief overview for those who haven’t connected their repository yet:

Manual Sync (If Not Using GitOps):

Use the following commands to manually trigger the initial sync:

argocd app sync gha-runner-scale-set-controller
argocd app sync gha-runner-scale-set

6. Verify Deployment:

Check if the ARC controller and runner pods are running in your cluster.

7. Actions Workflows to Test Custom Runners:

Once you’ve successfully deployed your Actions Runner Controller (ARC) with custom runners using ArgoCD, it’s essential to verify that everything works as expected. This section guides you through creating a sample workflow to test your setup.

Before that, let’s Check the status of our deployed self-hosted runner.

A self-hosted runner can be located in either your repository, organization, or enterprise account settings on GitHub. To manage a self-hosted runner, you must have the following permissions, depending on where the self-hosted runner was added:

User repository: You must be the repository owner.
Organization: You must be an organization owner.
Organization repository: You must be an organization owner, or have admin access to the repository.

In your organization or repository, navigate to the main page and click Settings.
In the left sidebar, click Actions, then click Runners.
Under “Runners”, you can view a list of registered runners, including the runner’s name, labels, and status.

The status can be one of the following:

Idle: The runner is connected to GitHub and is ready to execute jobs.
Active: The runner is currently executing a job.
Offline: The runner is not connected to GitHub. This could be because the machine is offline, the self-hosted runner application is not running on the machine, or the self-hosted runner application cannot communicate with GitHub.

Since our runner is online, let’s test it by creating a workflow to test our setup.

Here’s the process:

Access Your Workflow File:

Navigate to the GitHub repository where you want to create the test workflow.
Create a new file named .github/workflows/test-custom-runners.yml (or any preferred name).

Define the Workflow:

Monitor the Workflow:

The workflow will automatically execute on the specified runner. You can track its progress and output in the “Actions” tab of your repository.

Tips and Troubleshooting for Deploying Actions Runner Controller with ArgoCD

Tips:

Use Secrets for Credentials: Store GitHub access tokens or App credentials in Kubernetes Secrets for enhanced security and easier management.
Test and Validate your Manifests: Ensure your manifests are correct before syncing them to your cluster. Consider using tools like Helm lint or Kustomize for validation.
Monitor ArgoCD and Kubernetes Logs: Keep an eye on ArgoCD UI and Kubernetes logs for deployment progress and potential issues.
Start Small and Scale Gradually: Begin with a minimal runner scale set and gradually increase based on your workload demands.
Utilize GitOps Best Practices: Leverage the power of Git for version control, collaboration, and automated deployments.

Troubleshooting:

Connection Errors:
- Verify that ArgoCD can access your Kubernetes API server.
- Double-check the URL and namespace settings in your manifests.
Resource Creation Failures:
- Ensure the required Kubernetes resources (namespaces, service accounts, etc.) exist.
- Check for permission errors related to the service account used by the controller.
ArgoCD Sync Failures:
- Review the ArgoCD UI for detailed error messages.
- Consult the ArgoCD documentation for specific troubleshooting steps.

Conclusion:

ARC empowers you to take control of GitHub Actions runner costs and management while benefiting from autoscaling, declarative configuration, and GitOps integration. By following these steps and understanding the key concepts, you can successfully deploy ARC in your Kubernetes environment and optimize your GitHub Actions workflows.

This doesn’t end here, there will be next steps after the successful deployment

Creating custom images for actions-runner-controller: Now that we have actions-runner-controller up and running, we need to think through the runner image some. You would want to install dependencies on the image eg Docker, Yarn, etc. — Article coming soon

Resources:

Triggering Workflows in Another Repository with GitHub Actions

Tue, 03 Oct 2023 12:00:00 GMT

GitHub Actions provides a powerful automation framework that allows you to orchestrate and automate various tasks within your repositories. One of its features is the ability to trigger workflows in one repository from another repository. This can be useful for managing cross-repository actions, such as updating dependencies or deploying services.

In this guide, we will walk you through the steps to create a workflow in a source repository that triggers a workflow in a target repository.

Prerequisites

Before you begin, ensure you have the following:

Access to the source repository (the repository where you want to trigger the workflow).
Access to the target repository (the repository where the triggered workflow will run).
Basic knowledge of GitHub Actions.

Step 1: Configure the Source Repository

1.1. Set Up the Trigger Workflow

In the source repository (the repository that will trigger the workflow in the target repository), create a new GitHub Actions workflow file or use an existing one. This file should define the workflow responsible for triggering the target workflow.

Example workflow file (target_workflow.yml):

name: Trigger Target Workflow

on:
  workflow_dispatch:
    inputs:
      target_service:
        description: 'Input a service name (e.g., demo-app)'
        required: true
      target_version:
        description: 'Input a version (e.g., v1.0.0)'
        required: true

jobs:
  trigger:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Workflow in Another Repository
        run: |
          # Set the required variables
          repo_owner="REPOSITORY OWNER"
          repo_name="REPOSITORY NAME"
          event_type="trigger-workflow"
          service="${{ github.event.inputs.target_service }}"
          version="${{ github.event.inputs.target_version }}"
          
          curl -L \
            -X POST \
            -H "Accept: application/vnd.github+json" \
            -H "Authorization: Bearer ${{ secrets.PAT }}" \
            -H "X-GitHub-Api-Version: 2022-11-28" \
            https://api.github.com/repos/$repo_owner/$repo_name/dispatches \
            -d "{\"event_type\": \"$event_type\", \"client_payload\": {\"service\": \"$service\", \"version\": \"$version\"}}"

In this example, we’ve defined a workflow named “Trigger Target Workflow” that allows you to manually trigger the target workflow in another repository. This workflow is responsible for triggering another workflow in a different repository (target repository) based on user input. It allows you to specify a service name and a version (e.g., demo-app and v1.0.0) and then triggers the target workflow in the specified repository.

1.2. Configure the Trigger Logic

Inside your source workflow, define the logic and inputs required to trigger the target workflow. The key part is setting the target_repository input to specify the target repository where the workflow should be triggered.

Trigger Logic and Inputs:

on: This workflow is triggered manually using the workflow_dispatch event, which allows users to specify inputs.
Inputs: Users are prompted to provide two inputs:
- target_service: The service name (e.g., demo-app) that identifies the target repository where the workflow should be triggered.
- target_version: The version (e.g., v1.0.0) that will be passed to the target workflow.
Job: trigger
- runs-on: The job runs on an Ubuntu-based runner.
- Steps:
  1. Trigger Workflow in Another Repository: This step performs the actual triggering of the target workflow in the specified repository.
  - It sets the required variables:
    - repo_owner: The owner or organization name of the target repository.
    - repo_name: The name of the target repository.
    - event_type: The event type that the target workflow listens for (e.g., trigger-workflow).
    - service: The service name provided as an input.
    - version: The version provided as an input.
  - It uses the curl command to send a POST request to the GitHub API to trigger the workflow.
  - The request includes necessary headers such as authorization, content type, and API version.
  - It passes the event type and a client payload with the service name, version, and other optional flags.

Note: You should generate your own Personal Access Token (PAT) with the required permissions to enable you to trigger workflows in other repositories. You can refer to this guide for instructions on how to create a PAT.

1.3. Commit and Push

Commit the changes to your source repository and push them to the main branch. This ensures that the source workflow is set up and ready to trigger the target workflow.

Step 2: Configure the Target Repository

2.1. Set Up the Target Workflow

In the target repository (the one where you want to run the triggered workflow), create a new GitHub Actions workflow file or use an existing one. This file should define the workflow you want to run when triggered.

Example workflow file (target_workflow.yml):

name: My Target Workflow

on:
  repository_dispatch:
    types: [trigger-workflow]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.client_payload.sha }}
      
      # Add your workflow steps here

In this example, the “My Target Workflow” workflow is designed to respond to a repository_dispatch event with the trigger-workflow type. When this event occurs, it initiates the workflow.

2.2. Configure the Workflow Logic

Inside your target workflow, define the logic and actions you want to perform when the workflow is triggered. This could include tasks like updating dependencies, deploying applications, or running tests.

Checkout code:
- This step uses the actions/checkout@v4 action to check out the source code of the repository.
- Important customization is applied here by specifying the ref parameter with the value ${{ github.event.client_payload.sha }}. This means that the workflow will check out the specific commit or branch referenced in the sha field of the client_payload object of the triggering event. This allows the workflow to operate on the exact code state associated with the triggering event.
Extract Service Name & Version:
- This step is responsible for extracting and displaying the service name and version values from the client_payload object of the triggering event. These values were passed when the workflow was manually triggered and are stored in the payload for use in downstream steps.
- The extraction process involves the following actions:
  - Parsing the service field from the client_payload object and assigning it to the service_name variable.
  - Displaying the extracted service name using echo.
  - Parsing the version field from the client_payload object and assigning it to the version variable.
  - Displaying the extracted version using echo.

2.3. Commit and Push

Commit the changes to your target repository and push them to the main branch. This ensures that the target workflow is set up and ready to be triggered.

Step 3: Trigger the Workflow

Now that both the source and target workflows are set up, you can trigger the target workflow in the target repository from the source repository.

3.1. Manual Trigger

In the source repository, go to the “Actions” tab.
Find and select the “Trigger Target Workflow” workflow.
Click the “Run workflow” button.
Provide the target_repository input with the name of the target repository (e.g., owner/repo).
Click the “Run workflow” button to trigger the target workflow in the specified repository.

Once this has successfully completed, it then triggers the other workflow and passes the inputs from the previous workflow to the current one.

3.2. Automated Trigger (Optional)

You can also automate the trigger process by scheduling the source workflow or integrating it with other events such as code pushes or pull requests. This allows you to set up automatic workflows that trigger the target workflow based on specific conditions or schedules.

Conclusion

You’ve successfully configured a GitHub Actions workflow in one repository to trigger another workflow in a different repository. This powerful feature allows you to streamline automation and collaboration across multiple repositories, making it easier to manage complex workflows and tasks.

With this knowledge, you can automate various processes and actions, improving your development and deployment workflows.