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.
Prerequisites
Before creating and managing a trigger in a TCR Enterprise Edition instance, complete the following tasks:
1. Log in to the TCR console and click Trigger in the left sidebar.
On the Trigger page, you can view the list of trigger rules for the current instance. To change the instance, select the desired instance name from the Instance Name drop-down list at the top of the page.
2. Click Create. In the Create Trigger pop-up window, specify the parameters and the trigger rule. You can use the following figure for reference:
Name: Instance name. The name can contain lowercase letters, digits, hyphens (-), periods (.), and underscores (_), and must start with a letter or digit. In this document, webhook-demo is used as an example.
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.
Triggering Rule:
Triggered Instance: The instance to which the webhook belongs, which is the currently selected instance and cannot be changed.
Namespace: The namespace for which the webhook 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 OK.
Managing trigger rules
After a trigger rule is created, you can view the trigger rule on the Trigger page and perform the following operations to manage the trigger rule:
View Trigger Logs: You can click the name of the trigger rule or click Trigger Logs on the right side of the trigger rule to view the trigger logs of the 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: You can delete the trigger rule.
Viewing trigger logs
You can click the name of a trigger rule or click Trigger Logs on the right side of the trigger rule to view the trigger logs of the rule. See the figure below:
A log contains the following information:
Task ID: Trigger task ID, which is unique in the instance.
Action: The action that launched the trigger, such as image push.
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.
More 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.
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**, it will be the same as /path* and will only match the first-level repositories whose names are prefixed with path. To match all repositories under path, you should use /path/**. To match all repositories whose names are prefixed with path, you should use /path*/**.
?: matches any single character except ‘/’.
{alt1, alt2, …}: matches multiple regular expressions at the same time.
Use cases
Matches all repositories in the specified namespace
** or leave it empty
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
Yes
No
Was this page helpful?