commit 6862fff97ed28d09a9719363af48503811e6a9c9 parent 2dee57931d27858aa5f2ab0a0fd88ed6481a2272 Author: Devan Carpenter <devan@taler.net> Date: Thu, 13 Jul 2023 14:02:07 -0400 DD44: CI system design doc add first draft of CI system design doc Diffstat:
| A | design-documents/044-ci-system.rst | | | 84 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
1 file changed, 84 insertions(+), 0 deletions(-)
diff --git a/design-documents/044-ci-system.rst b/design-documents/044-ci-system.rst @@ -0,0 +1,84 @@ +CI System +######### + +Summary +======= + +This documents describes Taler's CI system based on Buildbot. + +This document uses `RFC 2119 <https://tools.ietf.org/html/rfc2119>`_ +keywords throughout. + + +Motivation +========== + +With the current CI system there are an array of issues: + +- Central place for all the jobs. +- The central config is poorly organized. +- We should prefer to keep as much CI logic in respective project source repos +as possible. +- Jobs should be split up further to allow for more granular control and +insight. +- Job triggers are unclear. +- The build environments are mutable. +- Non-trivial and error-prone to keep track of environment state. +- Hard to get an overview of what repo is causing a failure, at a quick glance. +- Bad for development workflow on a single project when you are getting +false-negatives all the time. + +Proposed Solution +================= + +Jobs shall be executed inside of containers. + +One build pipeline (aka. "builder") per repo. + +Build steps are generated from directory structure within a given repo. + +Example directory structure: +.. code:: none + ci + ├── ci.sh + ├── Containerfile + └── jobs + ├── 0-codespell + │ ├── config.ini + │ ├── dictionary.txt + │ └── job.sh + ├── 1-build + │ ├── build.sh + │ └── job.sh + └── 2-docs + ├── docs.sh + └── job.sh + +Job directories **MUST** follow this pattern: +``<repo_root>/ci/jobs/<n-job_name>/`` + +``n`` is an integer used for ordering the build steps. + +Job directories **MUST** contain a script named ``job.sh`` which **MAY** +execute other scripts. + +Config files may optionally be created, and MUST be named ``config.ini`` and +placed in the job directory. + +Available config options: +[ +.. code:: none + [build] + HALT_ON_FAILURE = True|False + WARN_ON_FAILURE = True|False + CONTAINER_BUILD = True|False + CONTAINER_NAME = <string> + + +Unless *all* jobs specify a "CONTAINER_NAME" in their custom config a +container file **MUST** be present at ``<repo_root>/ci/Containerfile``. +The container file will be built and used to run all of a repo's jobs +by default. + +All projects SHOULD have a ``build`` step and a ``test`` step, at a minimum. +