summaryrefslogtreecommitdiff
path: root/topics
diff options
context:
space:
mode:
Diffstat (limited to 'topics')
-rw-r--r--topics/systems/ci-cd.gmi49
1 files changed, 49 insertions, 0 deletions
diff --git a/topics/systems/ci-cd.gmi b/topics/systems/ci-cd.gmi
new file mode 100644
index 0000000..e170292
--- /dev/null
+++ b/topics/systems/ci-cd.gmi
@@ -0,0 +1,49 @@
+# CI/ CD for genetwork projects
+
+We need to figure out/ discuss and document how to go about doing the
+whole automated testing and deployment, from pushing code to
+deployment to production.
+
+For a first, we need various levels of tests to be run, from unit
+tests to the more complicated ones like integration, performance,
+regression, etc tests, and of course, they cannot all be run for each
+and every commit, and will thus need to be staggered across the entire
+deployment cycle to help with quick iteration of the code.
+
+## Tags
+
+* assigned: bonfacem, fredm, efraimf, aruni
+* deployment
+
+## Tasks
+
+#### Ideas
+
+GeneNetwork is interested in doing two things on every commit (or
+periodically, say, once an hour/day):
+
+- CI: run unit tests
+- CD: rebuild and redeploy a container running GN3
+
+Arun has figured out the CI part. It runs a suitably configured
+laminar CI service in a Guix container created with `guix system
+container'. A cron job periodically triggers the laminar CI job.
+
+=> https://git.systemreboot.net/guix-forge/about/
+
+CD hasn't been figured out. Normally, Guix VMs and containers created
+by `guix system` can only access the store read-only. Since containers
+don't have write access to the store, you cannot `guix build' from
+within a container or deploy new containers from within a
+container. This is a problem for CD. How do you make Guix containers
+have write access to the store?
+
+Another alternative for CI/ CID were to have the quick running tests,
+e.g unit tests, run on each commit to branch "main". Once those are
+successful, the CI/CD system we choose should automatically pick the
+latest commit that passed the quick running tests for for further
+testing and deployment, maybe once an hour or so. Once the next
+battery of tests is passed, the CI/CD system will create a
+build/artifact to be deployed to staging and have the next battery of
+tests runs against it. If that passes, then that artifact could be
+deployed to production, and details on the commit and \ No newline at end of file