Auto Trigger Pipelines¶

You can configure triggers for your pipelines to automatically trigger them periodically. Click Edit Configuration when editing a pipeline to set up a build trigger.

Currently, the following types of triggers are supported:

• Code source trigger
• Webhook trigger
• Regular repository scan
• Scheduled trigger

Trigger Types¶

Code Source Trigger¶

Choose the code repository integrated with your toolchain (currently only integrated code repositories are supported), and configure corresponding trigger events. The pipeline will be triggered based on these events. Once configured, Workbench will automatically configure the Webhook address into the integrated code repository.

Prerequisites¶

• Integrate GitLab code repository into the current workspace

Trigger events¶

Branch Change

The pipeline is automatically triggered when the branch in the code repository matches the set branch and there are code changes in the current branch. Regular expressions are supported.

PR/MR

When enabled, the pipeline is automatically triggered when a new PR/MR is created, updated, or merged in the code repository.

Tag

When a Tag is created in the code repository, the pipeline is automatically triggered if it matches the set Tag rules. Regular expressions are supported.

Webhook Trigger¶

When the Webhook trigger is enabled, you will receive a Webhook address that you can use to trigger the pipeline through other systems.

For example, below are the steps to trigger a pipeline using a Gitlab repository's Webhook.

1. Go to Gitlab, select and enter a repository detail.

2. Click Settings -> Webhooks .

3. In the URL area, enter the address generated by enabling the Webhook. In the Trigger area, select the trigger events based on actual conditions.

   

4. Click Add webhook. A record will be generated in the Project Hooks area.

   

5. Click Test to check if the trigger is successful.

Regular Repository Scan¶

The system checks the code repository for changes at a specified time. For example, entering H/15 * * * * means that the system will automatically check the code repository every 15 minutes for new changes. If there are new changes, the pipeline will be executed.

Refer to the Trigger Rules Syntax section for a guide on trigger syntax.

Scheduled Trigger¶

Triggers the pipeline at a specified time. After enabling the scheduled trigger, you can directly select preset rules or choose to customize CRON expressions and enter custom trigger rules.

Refer to the trigger rules section for a guide on trigger syntax.

Trigger rules¶

Trigger rule syntax follows that of CRON (with a slight difference). Specifically, each line consists of 5 tab- or space-separated fields: MINUTE HOUR DOM MONTH DOW

To specify multiple values for a field, you can use the following operators in order of priority:

In order for regularly scheduled tasks to create an even load on the system, the symbol H (for "hash") should be used whenever possible. For example, using 0 0 * * * for a dozen daily jobs will result in a large spike at midnight, possibly straining resources. In contrast, using H H * * * will still run each job once a day, but not all at once, which makes better use of limited resources.

H can be used with ranges. For example, H H(0-7) * * * means some time between 00:00 and 7:59.

Due to the different number of days in different months, when a short period such as /3 or H/3 appears in DOM , it will not be triggered at the end of most months. For example, */3 will trigger the task on the 1^st, 4^th, ..., 31^st of each month. If there are 30 days in the next month, the last time the task is triggered is the 28^th day.

Also, @yearly, @annually, @monthly, @weekly, @daily, @midnight, and @hourly are convenient aliases. These use hashes for automatic matching. For example, @hourly is the same as H * * * * and can represent any time within an hour. @midnight represents a period of time between 0:00 and 2:59 every day.

Examples

Comments