Argo Workflow and Events CI/CD

CICD Argo workflows

In this tutorial, you will learn about how to use Argo Events and Argo Workflows to achieve event driven workflow execution.

Components Explained

Event Source

It specifies how to consume events from external sources such as GitHub, Slack, AWS SNS and Webhooks etc.

Event Bus

An Event Bus acts as a transport layer for events to go from an Event Source to a Sensor.


It listens to events on Event Bus and triggers when a matching event is observed.

There are multiple trigger types such as AWS Lambda, HTTP requests, Any Kubernetes Objects and Slack.


Using argo workflows we can define workflows where each step in the workflow is a container.

Workflow Deployment

Click here to download the project manifest files

Create registry configurations,

Provide your username and password



Create registry config as a secret by replacing the placeholder <YOUR-REGISTRY-URL> with your registry url.

kubectl create secret generic -n argo-workflows docker-config --from-literal=".dockerconfigjson={\"auths\": {\”https://<YOUR-REGISTRY-URL>\”: {\"auth\": \"$(echo -n $DOCKER_USERNAME:$DOCKER_TOKEN|base64)\"}}}"

Create a secret for your GitHub token.

kubectl create secret generic github-test \ --namespace=argo-workflows \ —from-literal=username=<YOUR-USERNAME> \ —from-literal=personal_access_token=<YOUR-GITHUB-TOKEN>

Eventsource manifest

Our workflow needs to be able to receive HTTP Requests from the external system and to deploy the workload

The manifest file which you downloaded previously tells the event source controller that the event-source pod is listening for HTTP requests on port 12000 and endpoint /example

EventBus is namespaced, an EventBus object is required in a namespace to make EventSource and Sensor work.

Sensor Manifest file

It contains the sensor configs and the workflow to execute in a CI/CD fashion

The workflow templates in the sensor.yaml consists of tasks such as,

  1. Checkout code from Github repository

  2. Build and push the container images using buildkitd

  3. Promote and modify the release tag as seen in the image below

  4. Create a pull request

once deployed, you can test the webhook using curl with sample payload.