fixed first batch of tasks

chapters/implementation/dynamic-testing-framework.tex

@@ -3,7 +3,7 @@ \section{Dynamic Testing Framework}\label{sec:dynamic-testing-framework}
 The Dynamic Testing Framework (DTF) is a tool created to generate a test suite.
 Its input are test definitions and a defined similarity.
 Its output is a pipeline, that runs a subset of tests as defined by test definitions and similarities.
-As discussed in section~\ref{ch:background}, it uses a similarity based algorithm, to choose a subset of tests to run.
+As discussed in Chapter~\ref{ch:background}, it uses a similarity based algorithm, to choose a subset of tests to run.
 
 The purpose of this tool is to generate a pipeline based on a set of tests.
 Tests are defined and their similarity to each other are set.
@@ -53,8 +53,7 @@ \subsection{Test definitions}\label{subsec:test-definitions}
 \pagebreak
 
 The \textbf{name} property defines how the test definition is referenced in the similarity file and how the name in the test configuration for Concourse will look like.
-This property must be case-insensitive unique.
-I.e., the name \verb|A test| is the same as \verb|a test|.
+This property must be case-insensitive unique, i.e., the name \verb|A test| is the same as \verb|a test|.
 Therefore, there must not be two tests which, in their name, differ only in case.
 This is because the name in the Concourse configuration will be in a normalized form.
 In this form, spaces are replaced with dashes and all text will be in lowercase.
@@ -69,8 +68,7 @@ \subsection{Test definitions}\label{subsec:test-definitions}
 The scripts are executed in the same order as they are supplied.
 
 The \textbf{environment} and \textbf{resource} properties can be used to specify environment variables or Concourse resources that should be passed to the test task.
-The value will be passed to the Concourse configuration exactly as stated in the test definition.
-I.e., if \verb|((something))| is passed, \verb|((something))| will be passed to Concourse, which in turn will make a Vault lookup.
+The value will be passed to the Concourse configuration exactly as stated in the test definition, i.e., if \verb|((something))| is passed, \verb|((something))| will be passed to Concourse, which in turn will make a Vault lookup.
 With \verb|{{something}}| a parameter from a params-file can be referenced.
 Simply passing \verb|something| will pass the value \verb|something|.
 
@@ -98,7 +96,7 @@ \subsection{Test definitions}\label{subsec:test-definitions}
 \subsection{Similarities}\label{subsec:similarities}
 
 A similarity defines how similar a test is to other tests.
-This is the implementation of the concept introduced in section~\ref{sec:similarities}.
+This is the implementation of the concept introduced in Section~\ref{sec:similarities}.
 It is used to select tests for a pipeline with a greater amount of variety than pure randomness.
 First, a random test is picked and added to the list of tests.
 Then, the list of all other possible tests is sorted by descending similarity, such that the most dissimilar test is at the beginning of the list.

chapters/implementation/release-pipeline/finding-latest-release-branch.tex

@@ -30,8 +30,8 @@
     \end{tabular}
 \end{table}
 
-This python script, using the parameters shown in table~\ref{tab:py-finding-the-release-branch}, reads through the list of branches, tries to find a version for each one and then compares the versions found.
-It does so, by first removing the strings \verb| {release-prefix}-v | and \verb| {release-prefix}- | from the name.
+This python script, using the parameters shown in Table~\ref{tab:py-finding-the-release-branch}, reads through the list of branches, tries to find a version for each one and then compares the versions found.
+It does so, by first removing the strings \verb|{release-prefix}-v| and \verb|{release-prefix}-| from the name.
 The resulting name is then split by a dot, i.e., \verb|.|, because it assumes the usage of a semantic versioning scheme.
 Since the branches usually contain two version numbers, the major and minor version, the resulting array is extended with \verb|.0| until is length is two.
 These steps are necessary to obtain a normalized array for further processing.
@@ -44,12 +44,12 @@
 
 Examples:
 \begin{itemize}
-    \item The branch \verb| release-v0.2 | is considered lower than \verb| release-v0.3 |
-    \item The branch \verb| release-0.2 |  is considered lower than \verb| release-v0.2.1 |
-    \item The branch \verb| release-1.3 | is considered later than \verb| release-0.5 |
-    \item The branch \verb| release-2.0.0 | is considered invalid since is has too many version numbers. \\ Therefore any other branch ``wins'' the comparison.
-    \item The branch \verb| release-vA.B | is considered invalid since \verb| A | cannot be parsed as an integer. \\ Therefore any other branch ``wins'' the comparison.
-    \item The branch \verb| release-1 | is considered later than \verb| release-0.9 |. \\ The former version is appended with zeros. \\ The actual comparison would be \verb| 1.0 | against \verb| 0.9 |.
+    \item The branch \verb|release-v0.2| is considered lower than \verb|release-v0.3|
+    \item The branch \verb|release-0.2|  is considered lower than \verb|release-v0.2.1|
+    \item The branch \verb|release-1.3| is considered later than \verb|release-0.5|
+    \item The branch \verb|release-2.0.0| is considered invalid since is has too many version numbers. \\ Therefore any other branch ``wins'' the comparison.
+    \item The branch \verb|release-vA.B| is considered invalid since \verb|A| cannot be parsed as an integer. \\ Therefore any other branch ``wins'' the comparison.
+    \item The branch \verb|release-1| is considered later than \verb|release-0.9|. \\ The former version is appended with zeros. \\ The actual comparison would be \verb|1.0| against \verb|0.9|.
 \end{itemize}
 
 After the latest release branch is found, the version derived from it is also used to generate the CSV and Helm chart branches.

chapters/implementation/release-pipeline/get-next-version.tex

@@ -63,10 +63,9 @@
 All found releases are then filtered.
 Releases are discarded if:
 \begin{itemize}
-    \item They are a draft
-    \item They do not contain the release branch version
-    \item They are a sub-release of some kind.
-        I.e., if they do not contain the character ``-''
+    \item they are a draft,
+    \item they do not contain the release branch version and
+    \item they are a sub-release of some kind, i.e., if they do not contain the character ``-''
 \end{itemize}
 
 Every release that was not discarded is then compared against the other, not discarded, releases.

chapters/implementation/release-pipeline/image-preflight.tex

@@ -9,7 +9,7 @@
 Finally, it parses the digests of the images and adds them to the release information.
 
 First \verb|jq| is installed to read the release data, because \verb|jq| is not installed by default on the Docker in Docker image.
-Then, the Docker config provided is written to \verb|~/.docker/config.json| to make it available to Docker.
+Then, the Docker config provided is written to \verb|~/.docker/config| \verb|.json| to make it available to Docker.
 The command \verb|source /docker-lib.sh| imports all functions made available by the Docker in Docker image.
 One of the functions is \verb|start_docker|, which is then called to start the Docker daemon.
 
@@ -20,8 +20,7 @@
     \item \verb|docker.io/dynatrace/dynatrace-operator:v${version}|
 \end{itemize}
 
-Where \verb|version| is read from the release data using jq.
-\verb|${GCE_MARKETPLACE}| is defined by the \verb|gcp_marketplace| parameter.
+The value for \verb|version| is read from the release data using jq while \verb|${GCE_MARKETPLACE}| is defined by the \verb|gcp_marketplace| parameter.
 If any of those image cannot be pulled, the task fails.
 
 The digest is then parsed for each image.

chapters/implementation/release-pipeline/main-tasks.tex

@@ -3,12 +3,12 @@ \subsection{Main release tasks}\label{subsec:main-release-tasks}
 \begin{figure}[H]
     \centering
     \includegraphics[width=\textwidth]{img/implementation/release-pipeline.drawio}
-    \caption{Implemented release pipeline}
+    \caption{Implemented release pipeline.}
     \label{fig:implemented-release-pipeline}
 \end{figure}
 
 This section discusses the tasks implemented as part of the main release pipeline.
-In figure~\ref{fig:implemented-release-pipeline} the final implementation of this pipeline part is depicted.
+In Figure~\ref{fig:implemented-release-pipeline} the final implementation of this pipeline part is depicted.
 The boxes contain the names of the tasks, while the freestanding text depicts the resources they either consume or produce.
 Most of them consume the DTO's repository and the release-data generated by the previous task.
 They then generate a new version of the release-data, amended with the data generated by the tasks.