Adapt episode 8 to changed GitLab UI

episodes/08-process-automation.md

@@ -24,8 +24,7 @@ we fill our research diary every day. Now it is time to make use of it.
 
 We want to share it with the world, because what we do is so important and everyone should now about it.
 So we want to create a website based on the diary and update it whenever our Markdown files change.
-
-Just as much based in reality as the rest of this lesson’s story, we know how to do that, but we do not want to do it by hand.
+But we do not want to do that by hand.
 Instead, we are going to let GitLab automatically turn our Markdown files into HTML, whenever our repository changes.
 To achieve it, we will use two GitLab features: CI/CD-Pipelines and Pages.
 
@@ -35,18 +34,18 @@ To achieve it, we will use two GitLab features: CI/CD-Pipelines and Pages.
 
 The terms continuous integration (CI) and continuous deployment (CD) come from the fields of software engineering and software operation.
 
-A software project uses CI, if it has setup a process that automatically runs some (or all) tests for a software project, whenever changes are committed or even just proposed (for example through a merge request) to the main branch of a repository.
-In particular, when tests run already for proposed changes this can help prevent bugs to reach the code base, while freeing the developer of remembering to run all the tests, before creating a merge request.
+A software project uses CI, if it has setup a process that automatically runs some (or all) tests for a software project, whenever changes are committed to the main branch of a repository or even just proposed (for example through a merge request).
+In particular, when tests are already run for proposed changes this can help prevent bugs to reach the code base, while freeing the developer from remembering to run all the tests, before creating a merge request.
 
 CD is a process that updates the software on the production machines (deploys) as soon as a new change reaches the code base, generally after having passed the CI process.
 
-Both processes can be implemented by running scripts, called jobs on GitLab, triggered either by changes to the code base or by the successful completion of other jobs, which lead to the CI/CD feature of GitLab.
+Both processes can be implemented by running scripts, called jobs on GitLab, triggered either by changes to the code base, the creating of merge request, or by the successful completion of other jobs, which lead to the CI/CD feature of GitLab.
 
 :::
 
 ## Example Configuration
 
-To configure our automatic process, we navigate to our project page and click the menu item labeled  “CI/CD” in the main menu on the left.
+To configure our automatic process, we navigate to our project page and click the menu item labeled  “Pipelines” in the submenu “Build” of the main menu on the left.
 
 The page that this leads to invites us to “use a sample `.gitlab-ci.yml` template file to explore how CI/CD works.”
 The GitLab CI is configured by providing a file called `.gitlab-ci.yml` in the root directory of a project’s repository.
@@ -84,8 +83,8 @@ The remaining four blocks, `build1:`, `test1:`, `test2:`, and `deploy1:`, each d
 A job represents one non-divisible unit of a CI/CD process.
 Together the jobs defined in a project’s `.gitlab-ci.yml` file form a so called **pipeline**.
 
-By default a pipeline has three **stages**, called `build`, `test`, and `deploy`, and their order is important.
-The terminology comes from software development again.
+By default a pipeline in GitLab has three **stages**, called `build`, `test`, and `deploy`, and their order is important.
+The terminology comes again from software development.
 A pipeline is executed by running all jobs of the first stage and, if they succeed, to then continue with jobs of the next stage, repeating this until a job fails or all stages complete.
 
 The four jobs in the example are named similar to the stages they are assigned to.
@@ -145,7 +144,7 @@ publish-on-web:
 After giving the name of the job, we again provide an Docker image in which the job should run.
 We use pandoc to convert our Markdown files into an HTML file, so we use the official pandoc Docker image.
 The next line, with the keyword `entrypoint` is necessary, because the pandoc Docker image is configured to directly run pandoc, when started in a container (pandoc is configured as its entrypoint).
-However, GitLab CI expects to run scripts in the Docker container in a shell.
+However, GitLab CI expects to runs the provided scripts in a shell in the specified Docker images.
 
 ::: callout
 
@@ -164,7 +163,7 @@ Next, we specify the stage, followed by the script.
 It runs pandoc on all files ending in `.md` in the current directory and instructs it to output a file `diary.html`.
 Pandoc deduces from the file extension that it should be in HTML format.
 
-The final three lines, starting with the keyword `artifacts`, specify that GitLab CI should save the file `diary.HTML` from the Docker container the job runs in and provide it for download on its web interface.
+The final three lines, starting with the keyword `artifacts`, specify that GitLab CI should save the file `diary.html` from the Docker container the job runs in and provide it for download on its web interface.
 
 This completes our GitLab CI configuration.
 There are a lot more configuration options, for example to have a process run only for commits to certain branches, that are documented in [GitLab’s Handbook](https://docs.gitlab.com/ee/ci/yaml/gitlab_ci_yaml.html)
@@ -190,7 +189,7 @@ On other instances the situation can be different.
 
 Clicking the button does not cause a change in page. Instead, we are informed at the top of the page about the status of the pipeline run that was initiated by committing the `.gitlab-ci.yml` to the repository.
 
-To get a better overview, we select “CI/CD” from the main menu on the right side.
+To get a better overview, we click the menu item labeled  “Pipelines” in the submenu “Build” of the main menu on the left.
 This brings us to the list of pipeline runs. We should see exactly one entry in the list, as we have just configured the CI.
 
 A blue, red, or green box in the “Status” column informs on the left informs us about the state of the pipeline.
@@ -200,11 +199,11 @@ Below the status box we have the runtime of the pipeline and below that informat
 In the ”Pipeline” column, we see the first line of the commit that triggered the pipeline run, the number of the pipeline run, for example `#11071`, the branch the commit is part of as well as the short identifier of the commit.
 Most of these serve as links to pages for their respective entities.
 
-The ”Triggerer” column tells us who caused the pipeline run.
+The ”Created By” column tells us who caused the pipeline run.
 In our case that’s the author of the commit.
 
 The ”Stages” column visualizes the stages and their state.
-In addition to the colors discussed above, there are stages colored in gray.
+In addition to the colors discussed above, there can be stages colored in gray.
 They are waiting for their predecessor stages (or need to be manually triggered, if configured that way).
 
 We wait until our pipeline ran through.
@@ -236,7 +235,7 @@ But we wanted to publish it on the web.
 To achieve this goal, we can use a feature of GitLab called Pages.
 It allows us to publish the results of a specific job of a CI pipeline to the web under the `gitlab.io` domain.
 
-TODO: DESCRIBE HOW TO GET THERE
+We navigate to the editor of the CI-configuration, by clicking on “Pipeline editor” under “Build” in the menu on the right.
 
 We change the configuration of our second job to look as follows:
 
@@ -259,12 +258,12 @@ This name is a convention to tell GitLab, that we want this job to create the co
 Then we create the HTML file in a directory called `public` and change the path that defines the job artifacts to `public` as well.
 The directory `public` is, again by convention, the place from which GitLab will take the contents to be published.
 
-TODO: DESCRIBE HOW TO SAVE
+We enter the commit message “Setup GitLab-Page publication” and click on “Commit changes”.
+Afterwards change, the pipeline will automatically run.
 
-After committing our change, the pipeline will automatically run.
-When it has successfully completed, we select Pages under the Settings heading of the menu on the left.
-In the section called “Access pages”, we find a link to our web page.
+When it has successfully completed, we select “Pages” under the “Deploy” submenu of the menu on the left.
+In the section called “Access pages”, we find a link to the base path of our web page.
 This will lead to a page informing us that the requested resource was not found.
 The reason is, that we do not provide a file called `index.html`.
-Instead, we need to append `diary.html` at the end of the URL shown in the settings page.
+Instead, we need to append `/diary.html` at the end of the URL shown in the settings page.
 Now we see the rendered version of that diary, published in the web.