describe CI/CD

see D2.6

architecture-docs/architecture.md

@@ -130,7 +130,9 @@ The used legend is as follows:
 
 For further info on components see the [glossary](#glossary).
 
-![](https://git.fediversity.eu/Fediversity/meta/raw/branch/main/architecture-docs/interactions-migration.svg)
+<!-- ![](./interactions-migration.svg) -->
+![](./interactions-migration.png)
+
 ### Configuration data flow
 
 This data flow diagram refines how a deployment is obtained from an operator's application configuration and a hosting provider's runtime setup.
@@ -141,7 +143,8 @@ For its runtime setup, a hosting provider has to supply a **resource mapping** t
 
 Applications and runtime environments thus interface through **resources**, the properties of which are curated by Fediversity maintainers.
 
-![](https://git.fediversity.eu/Fediversity/meta/raw/branch/main/architecture-docs/interactions-fediversity.svg)
+<!-- ![](./interactions-fediversity.svg) -->
+![](./interactions-fediversity.png)
 
 
 ### Service portability
@@ -159,10 +162,15 @@ The process of migrating one's applications to a different host encompasses:
 Whereas the bulk of our configuration logic is covered in the configuration schema, [implemented here](https://git.fediversity.eu/Fediversity/Fediversity/src/branch/main/deployment/data-model.nix) and [tested here](https://git.fediversity.eu/Fediversity/Fediversity/src/branch/main/deployment/data-model-test.nix), our reference front-end applications will store data.
 The data model design for the configuration front-end needed support the desired functionality is as follows, using the crow's foot notation to denote cardinality:
 
-<img src="https://git.fediversity.eu/Fediversity/meta/raw/branch/main/architecture-docs/panel-data-model.svg" alt="" style="max-width:600px;"/>
+<img src="./panel-data-model.svg" alt="" style="max-width:600px;"/>
 
 ### Host architecture
 
 Whereas the core abstraction in Fediversity is a NixOS configuration module, a more full-fledged example architecture of the web host use-case we aim to support as part of our exploitation would be as follows, where virtual machines in question run Fediversity to offer our selected applications:
 
 ![](https://git.fediversity.eu/Fediversity/meta/raw/branch/main/architecture-docs/host-architecture.png)
+
+### CI / CD
+
+In our simplest set-up, continuous integration and continuous deployment pipelines are handled using Forgejo's [built-in runner](https://code.forgejo.org/forgejo/runner), with relevant secrets handled using [Forgejo secrets](https://forgejo.org/docs/latest/developer/secrets/). Jobs we handle using CI include linting, formatting, testing, and a periodic life-cycle management job to keep our dependencies up-to-date.
+In a future iteration, we may make use of [Gerrit](https://gerrit.googlesource.com/) to better manage our review process for incoming merge requests.

default.nix

@@ -0,0 +1,14 @@
+{
+  pkgs ? import <nixpkgs> { },
+}:
+{
+  shell = pkgs.mkShellNoCC {
+    packages = with pkgs; [
+      pandoc
+      texliveMedium
+      librsvg
+      mermaid-cli
+      plantuml
+    ];
+  };
+}

shell.nix

@@ -0,0 +1 @@
+(import ./. { }).shell