[taler-docs] branch master updated: DD44: CI system design doc

[gnunet]

This is an automated email from the git hooks/post-receive script.

devan-carpenter pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 6862fff9 DD44: CI system design doc
6862fff9 is described below

commit 6862fff97ed28d09a9719363af48503811e6a9c9
Author: Devan Carpenter <devan@taler.net>
AuthorDate: Thu Jul 13 14:02:07 2023 -0400

    DD44: CI system design doc
    
    add first draft of CI system design doc
---
 design-documents/044-ci-system.rst | 84 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 84 insertions(+)

diff --git a/design-documents/044-ci-system.rst 
b/design-documents/044-ci-system.rst
new file mode 100644
index 00000000..656f14a5
--- /dev/null
+++ 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.
+

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.