Help & Documentation>Tencent Container Registry>Operation Guide>DevOps>Managing Triggers

Managing Triggers

Last updated: 2024-03-25 14:33:11

On this page:

Scenario

Tencent Container Registry (TCR) allows users to configure and use the flexible trigger (Webhook) feature. By configuring a proper trigger in an instance, you can quickly integrate existing R&D processes and CI/CD platforms and realize container DevOps scenarios such as image updates automatically triggering application deployment.
The trigger feature allows users to create custom trigger rules and view triggering logs. Trigger actions support the push, pull, and deletion of container images and Helm charts. Triggering rules support flexible regular expression filtering and regular filtering based on specified namespaces in an instance and configured image repositories and tags. This allows the trigger to be triggered by only certain repositories or image tags that use special naming formats. The custom Header feature allows users to configure the Header for accessing the target URL in the Key:Value format, which is applicable to authentication and other scenarios.

Preparations

Before creating and managing a trigger in a TCR Enterprise Edition instance, complete the following tasks:
You have purchased a TCR Enterprise Edition instance. This feature is only applicable to Enterprise Edition instances.
If you are using a sub-account, you must have granted the sub-account operation permissions for the corresponding instance. For more information, see Example of Authorization Solution of TCR Enterprise.

Instructions

Creating Trigger

1. Log in to the Container Registry Service console and select Trigger from the left navigation bar. On the "Trigger" page, you can view the list of trigger rules within the current instance. If you need to switch instances, select from the "Instance Name" dropdown list at the top of the page.
2. Click New. In the "Create a trigger" window that appears, configure the rules according to the following prompts, as shown in the figure below:


Name: Instance rule name, supporting lowercase letters, digits, and three symbols (-, ., _), and must start with a letter or digit. In this example, we use webhook-demo.
Description: Rule description.
Action: Four trigger actions are supported: push images, delete images, upload Helm charts, and delete Helm charts. During the execution of the webhook, the initiated webhook request contains information about the trigger action.
Trigger rule:
Triggered instance: The instance to which the trigger belongs, which is the currently selected instance and cannot be changed.
Namespace: The namespace for which the trigger takes effect. If the list is empty, create a namespace in the instance.
Repository name: The name of the repository for which the webhook takes effect. Regular matching of image repositories and Helm charts is supported.
Tag: The tag for which the webhook takes effect. It supports regular matching. If you want the webhook to take effect for all tags, leave this parameter empty.
URL: The target URL for request initiation after the trigger fires, which is the URL that you specified for the webhook server. The trigger will send a POST request to the URL, and the request body contains the trigger action, trigger rule, and other information.
Header: The Header information in the Key:Value format to be carried in a POST request initiated by the trigger. Example: Authentication: xxxxxxx.
3. Click Confirm to create the synchronization rule.

Managing trigger rules

Upon successful creation, you can view the created trigger rules on the "Triggers" page. You can perform the following operations to manage the trigger rules, as shown in the figure below:



View Triggering Logs: Click the trigger rule name or Triggering Logs on the right side of the trigger rule name to view the trigger logs for that rule. For more information, see Viewing Trigger Logs.
Modify Rule Status:

indicates that the rule is enabled, and

indicates that the rule is disabled. By default, a synchronization rule is enabled after it is created. You can change the status as needed.
Configuration: You can re-configure all parameters of the trigger rule.
Delete: Remove the trigger rule.

Viewing trigger logs

Click the name of a specific trigger rule or click Trigger Logs on the right side of the trigger rule to view the trigger logs of the rule. The information includes:
Task ID: Unique trigger task ID within the instance.
Action: The action that initiated the trigger, such as pushing an image.
Triggered Repository: The repository resources that launched the trigger.
Status: Success status of the trigger in executing the webhook request.
Creation Time: The time when the trigger was launched, which is also the time when the webhook request was initiated.

Relevant Information

Webhook request format for reference

When users perform a relevant action on resources that meet a trigger rule, for example, pushing new images to the specified image repository, the relevant trigger is triggered and sends an HTTP POST request to the URL configured in the rule. The request body contains information such as the trigger action and repository path. The following is the resolved information of a sample request body after the trigger is triggered by image pushing. This sample is for reference in webhook server development.
      {
  "type": "pushImage",
  "occur_at": 1589106605,
  "event_data": {
    "resources": [
      {
        "digest": "sha256:89a42c3ba15f09a3fbe39856bddacdf9e94cd03df7403cad4fc105xxxx268fc9",
        "tag": "v1.10.0",
        "resource_url": "xxx-bj.tencentcloudcr.com/public/nginx:v1.10.0"
}
    ],
    "repository": {
      "date_created": 1587119137,
      "name": "nginx",
      "namespace": "public",
      "repo_full_name": "public/nginx",
      "repo_type": "public"
}
  },
  "operator": "332133xxxx"
}

Using regular expressions to create rules

Regular matching rules

The following are the matching rules supported by the regular expression when you enter “repository name” or “version tag”:
*: matches all strings of any length that do not contain the path separator (/).
**: matches all strings of any length that contain the path separator (/).
Note
** must be used as a complete relative path. If you use /path**, its effect will be equivalent to /path*, and it can only match first-level repositories with the "path" prefix. To match all repositories under "path", use /path/**; to match all repositories with the "path" prefix, use /path*/**.
?: matches any single character except ‘/’.
{alt1, alt2, …}: matches multiple regular expressions at the same time.

Typical Use Cases

Matches all repositories in the specified namespace.
** or leave it blank
Matches all first-level repositories whose names are prefixed with path in the specified namespace.
/path*
Matches all first-level repositories whose names are prefixed with path1 and path2 in the specified namespace.
/{path1, path2}*
Matches all repositories under the path1 and path2 directories in the specified namespace.
/{path1, path2}/**
Matches all repositories whose names are prefixed with path1 and path2 in the specified namespace.
/{path1, path2}*/**
Matches all 1.x version tags in the specified repositories.
1.?
Matches all version tags whose names are prefixed with env1 and env2 in the specified repository.
{env1*, env2*}

中国站 - English