WIP: Resolve "Run CI/CD pipelines on a schedule"
This MR is only for planning milestones for Idea 1 in #2989 (closed) and clarifying the specification. Each step should be separated MR.
Step 1: Remove legacy codes
-
Check whether legacy codes are still lurking (e.g. whenever
gem) -
Remove legacy codes. Test to make sure the change doesn't break current architectures and dependencies.
Step 2: Backend
Step 2.1: Database
-
or new table
-
Plan to expand schema -
Add columns and migration
table | column | type | data |
---|---|---|---|
(TBD) | trigger_type | string |
external (api) or scheduled (cron) |
(TBD) | cron | string | e.g. 30 18 * * *
|
(TBD) | cron_time_zone | string | e.g. Europe/Istanbul
|
(TBD) | target_ref | string | e.g. complie-linux-dist-*
|
(TBD) | condition_type | string |
always or if_changed
|
(TBD) | active | boolean | literaly pasue/unpause |
Step 2.2: Controller
-
Create a new trigger with cronjob (#new, #create, with sidekiq-cron) (TODO: Elaborate this process) -
Edit a trigger (#edit, #update) -
Remove a trigger (#destroy) -
Invoke a trigger with cronjob immediately (#test_cronjob) -
Support Pass job variables
(TODO: make sure this needs to be classified)
Step 3: Frontend
Step 3.1: Registration of a new Trigger ("Settings" -> "CI/CD Pipelines" -> "Triggers")
-
Click Add trigger
button -> Show a new trigger registration form -
"Trigger description" (Already existed) -
"Trigger type" (Radiobutton: External Trigger(API) or Scheduled Trigger(Cron)) -
if "Scheduled Trigger" chosen, expand those items -
"Schedules" (TextFiled: e.g. 30 18 * * *
. Syntax check.) . Plus there are three buttons: "Nightly builds", "Sunday night", "Last day of a month". If one of them clicked, automatically this filed fulfilled. -
"Time zone" (Combobox: For gitlab.com users. Choose a country. e.g. Europe/Istanbul
) -
"Target ref" (TextFiled: wildcard(*) support. e.g. complie-linux-dist-*
. If there are no matches, show an error msg.) -
"Conditions"(Combobox: "always" or "if there was a new change on the branch". Default: "always") -
"variables"(TextFiled: e.g. "variables[RUN_NIGHTLY_BUILD]=true") -
Active/Deactive a trigger (only #edit
)
Example Reference: Buddy
Step 3.2: List triggers
In a row, there are
-
Status -
Active/Deactive -
Cron format -
Last used (Already existed) -
Link to the last invoked pipeline -
Button -
Delete a trigger (Already existed.) -
Edit a trigger (Already existed. Edit parameters except "Trigger type")
Example
Reference: TravisCI
Note / Concerns
- Limitation for gitlab.com. e.g. One project has only one Scheduled Trigger. User can not set less than one day interval. Target ref should be matched less than 5 targets.
- Performance. Processes of schedulers and builds will incredibly increase.
- No real-time status update like Buddy for a first iteration.
- Maybe this layout should be refurbished by UI/UX dev.