Event-driven CI pipeline with EventBridge - Container Service for Kubernetes

Prerequisites

You have activated EventBridge and granted permissions.
You have created an Argo workflow cluster.
You have created a file system.
You have created an Enterprise Edition instance.
You have granted the AliyunAdcpFullAccess permission to a RAM user. For more information, see Grant permissions to a RAM user.

How it works

An event-driven, automated CI Pipeline consists of two parts:

Committing code to a Git repository triggers a Git event.
The CI system runs pre-build tests, builds a Docker image, and pushes the image to an image repository.

After the image is successfully built, you can use a continuous deployment (CD) system, such as ACK One GitOps, to synchronize the new image tag with your Kubernetes cluster.

This tutorial uses EventBridge for the event-driven solution because of its advantages in availability, ease of use, security, and scalability. The CI component uses Argo Workflows, a graduated project of the Cloud Native Computing Foundation (CNCF). The workflow cluster fully manages Argo Workflows to improve stability and observability. It also provides operations and maintenance (O&M) capabilities to help you build larger, faster, and more cost-effective CI Pipelines.

A user commits code to a Git repository.
Based on a configured event rule, EventBridge captures the Git event and forwards it to the ACK One workflow cluster. This triggers the CI workflow.
A CI workflow on an ACK One workflow cluster builds a Docker image and pushes it to an image repository. You can then use GitOps to automatically synchronize the image changes with an ACK cluster.

Step 1: Prepare the CI environment

Create an ACR EE access credential and mount an NAS volume. For more information, see Step 1 and Step 2 in Build a CI Pipeline for a Golang project by using a workflow cluster.

Note
Ensure the namespace is the same as that of the Workflow resource.
This tutorial uses the echo-server project as the sample application code. Fork the project to your GitHub account, and then modify the WorkflowTemplate by following the instructions in Clone a private Git repository in a CI Pipeline.

Step 2: Trigger the CI pipeline with EventBridge

Create a custom event bus.
Integrate EventBridge with GitHub. For more information, see GitHub integration.

Optionally, configure an event rule. The following code provides a sample configuration. For more information about how to configure event rules, see Manage event rules.

Event pattern: The following setting triggers changes only from the release-v1 branch.

{
    "source": [
        "github.event"
    ],
    "data": {
        "body": {
            "ref": [
                "refs/heads/release-v1"
            ]
        }
    }
}

Configure the event target.

Service Type: Select Container Service for Kubernetes.
Cluster KubeConfig: Enter the KubeConfig to access the workflow cluster over the VPC.
YAML Configuration: Select Template.
Parameters: Add workflowName to configure the event ID.
```
{
  "workflowName": "$.id"
}
```

Template: Enter the Workflow CI custom resource (CR). The following example is for reference only; create the CR based on your actual information.

Important

Resource configurations require that you explicitly set the name and namespace. You cannot use generateName. If a resource belongs to the default namespace default, you must also declare it.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: ci-go-v1-eb-${workflowName}
  namespace: default
  labels:
    workflows.argoproj.io/workflow-template: ackone-ci
spec:
  arguments:
    parameters:
    - name: repo_url
      value: https://github.com/ivan-cai/echo-server.git
    - name: repo_name
      value: echo-server
    - name: target_branch
      value: release-v1
    - name: container_image
      value: "YOUR-IMAGE-REGISTRY-ADDRESS"     # Replace this with the address of your container image repository.
    - name: container_tag
      value: "v1.0.0"
    - name: dockerfile
      value: ./Dockerfile
    - name: enable_suffix_commitid
      value: "true"
    - name: enable_test
      value: "true"
  workflowTemplateRef:
    name: ci-go-v1
    clusterScope: true

Network Access: We recommend using a VPC. Select the VPC, vSwitch, and security group that correspond to the workflow cluster.

Based on the preceding configuration, when you modify and commit code to the release-v1 branch of your GitHub repository, this action triggers an automated process. You can verify this in the following ways.
1. View the event trace.
  1. Log on to the EventBridge console. In the left-side navigation pane, click Event Buses.
  2. Click the name of your event bus. In the left-side navigation pane, click Event trace.
  3. On the Event trace page, you can view the event trace.
    
    In the event trace details, the event ID is b91299ae-355d-4f66-ac53-8d84e5d84b97, the event type is eventbridge:Events:HTTPEvent, the event bus name is ci-test, and the event source is github.event. In the Event Delivery section, the rule ttt delivered the event to the target https://8.217.97.153:6443. The delivery status is Succeeded, the delivery latency is 59 ms, and the delivery response is [200]NoMessage.
2. View the execution topology of the newly created Workflow.
  
  You can find this topology in the workflow cluster. For more information, see Enable Argo Server to access the workflow cluster.
  
  The Workflow is named ci-go-v1-eb-3999580c-1ee4-4e10-a75b-af6e8eddccde. Its directed acyclic graph (DAG) execution topology shows the following steps: git-checkout-pr (Succeeded), run-test (Succeeded), and build-push-image (Running).