taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

commit 58361555d2018889723eaeb108238318f5355bd7
parent 08ea9a994ab6afc579fb1a0a7623926664672aee
Author: Devan Carpenter <devan@taler.net>
Date:   Thu, 13 Jul 2023 22:15:12 -0400

DD44: attempt to fix rst syntax

Diffstat:
Mdesign-documents/044-ci-system.rst | 19+++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/design-documents/044-ci-system.rst b/design-documents/044-ci-system.rst @@ -1,5 +1,5 @@ -CI System -######### +DD44: CI System +############### Summary ======= @@ -17,15 +17,15 @@ 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. + as possible. - Jobs should be split up further to allow for more granular control and -insight. + 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. + false-negatives all the time. Proposed Solution ================= @@ -40,7 +40,9 @@ 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 @@ -68,8 +70,9 @@ 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