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.
Before creating and managing a trigger in an TCR Enterprise Edition instance, complete the following tasks:
-
, .
, and _
). It must start with a letter or number. In this document, webhook-demo
is used as an example.Authentication: xxxxxxx
.After a trigger rule is created, you can view the trigger rule on the "Trigger" page. Then, you can perform the following operations to manage trigger rules. See the figure below:
You can click the name of a specific trigger rule or click Triggering Logs to the right of the trigger rule name to view the triggering log of the rule. See the figure below:
The log contains the following information:
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"
}
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 (/
).**
: match 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.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*} |
Was this page helpful?