Feature/ADRs

README.md

@@ -1,6 +1,6 @@
 # execDAT
 
-execDAT - remote code execution for research
+execDAT - remote code execution for research 
 
 ## Getting Started
 

docs/adrs/2023-03-16-public-vs-private-data.md

@@ -3,7 +3,7 @@
 Date: 2023-03-16
 
 ## Status
-__PROPOSED__
+__ACCEPTED__
 
 ## Context
 

docs/adrs/2023-03-23-branch-naming.md

@@ -0,0 +1,25 @@
+# Branch Naming
+
+Date: 2023-03-23
+
+## Status
+__PROPOSED__
+
+## Context
+We want a unified naming scheme for the naming of branches. Currently, no concrete scheme was decided on and we had a discussion between `feature/`, `features/` and `issue/` prefixes for branches beside `dev` or `main`.
+
+## Decision
+We decided on the following namings:
+* `main` for the main branch
+* `dev` for the development branch
+* `feature/` for all branches that implement a new functionality or feature
+* `issue/` for all branches that are concerned with a bug-fixe or issue
+* `testing/` for all branches that fit neither `feature/` or `issue/`
+
+We researched Pre-Commit-Hooks to enforce this, however a local installation of the CLI tool would be required and we do not want the added tool requirements and complexity.
+
+Instead we will use the __branch protection rules__ to pattern match all other names and lock the corresponding branches. This should correspond some type of enforcing.
+
+## Consequences
+* developers need to adhere to the naming scheme for branches
+* tighter control over the branch protection rules because we only have a small set of legal names

docs/adrs/2023-03-23-cicd-solution.md

@@ -0,0 +1,19 @@
+# Title
+
+Date: 2023-03-23
+
+## Status
+
+__PROPOSED__
+
+## Context
+
+We need to dicide on a CI/CD solution for our project, so we can automate certain tasks, e.g., building, testing, releasing, etc..
+
+## Decision
+
+Some choices for our CICD platform would be GitHub Actions, Tekton, Jenkins or Argo CD. Solutions like Tekton or Argo CD are build up upon Kubernetes, are cloud-native and platform agnostic. GitHub Actions workflows are much simpler, have predefined workflow steps and only require a yaml file for configuration. We decided to use GitHub Actions workflows because we already use GitHub for other related tasks, such as branch naming and protection rules, and therfore we have all of our configuration in one place. Additionally, GitHub Actions are much easier to setup and there are many already existing yaml configurations we can build up upon.
+
+## Consequences
+
+By choosing GitHub Action workflows, compared to running custom workflows in a Kubernetes environment with other solutions, we have a much simpler setup. But we are also more limited in our possibilities, as you have more options in a custom Kubernetes cluster.