CI Job Processing

Monteur key feature is its CI Job approach to achieve reproducible build from sourcing supply chain to customers shipment. This page details its technical specifications.

The Problems

Dated to year 2020, there is a realization within ZORALab team that their projects and products had overly relying on 3rd-party vendor locked-in continuous integration services like GitLab CI, Circle CI, and Travis CI. The team also technically reviewed Jenkins CI but found that it was gigantic and quite heavy as an independent platform service.

Among the key vulnerabilities discovered were:

1. The project becomes very vulnerable to these locked-in vendors. Should any of these vendors perform business-wide direction changes (GitLab CI Case Exhibits I, GitLab CI Case Exhibits II, GitLab CI Case Exhibits III, Travis CI Case Exhibits I, Travis CI Case Exhibits II, and Travis CI Case Exhibits III), to change such a critical CI service tool while still continuously developing the project can be very cumbersome and can take months to change.

2. Inflexible, vendor-specific, and custom-brewed instructions scripts. The critical CI can ONLY and ONLINE ONLY be running on these third-party platforms of your choice. There is NO WAY to run CI locally in an offline, decentralized, and independent manner.

3. Global geo-political instability that can instantly kill one or more project entirely anytime. Should the geo-political implication is unfavorable to the project (GitHub Exihibit I, GitHub Exihibit II, GitHub Exihibit III, GitLab Exihibit I, GitLab Exihibit II, and GitLab Exihibit III), there is little efforts these service providers can do but to comply with their country of origin's export restrictions.

4. Project-specific, non-reusable CI investment across different projects. This means it is very hard to roll out updates for the CI script across multiple projects there are using the same CI job.

The Solution

The ZORALab team immediately put this Monteur project at work. Monteur CI Jobs specifically facilitates anyone or everyone a consistent implementations of CI at decentralized, offline-capable, down to work laptop level. This should solve the geo-politics instability vulnerability.

To make sure Monteur's customers do not suffer the never ending SHELL+BATCH scripting choice, Monteur itself is works as an intepreter executing its CI commands based on a standardized TOML data format. This should solve the portability matter related to the CI script.

The CI Job TOML data file is continuously designed and tested across time to formulate a generic job for interacting various 3rd-party software in the project and existing 3rd-party CI services. Due to the generic nature of the CI Job, the distribution and update rolling to any of the existing CI Job script can be easily rolled out across various project, thus solving the non-reusable investment vulnerability.

To keep communications simple, Monteur keeps the CI stages based on brewing a cup of artistic coffee. That way, it's easier to communicate between technical folks and non-technical folks.

Available CI Jobs

To date, Monteur had developed the following CI Jobs for specific needs. Please remember that each CI Jobs has its own currently maintained job recipes for known platforms and interacting 3rd-party software. Here are the available CI Jobs: