service/ci.md

@@ -109,7 +109,7 @@ the cleanup jobs by hand, in order:
 
     docker system prun --filter until=72h
 
-The timeframe can be lowered for a more aggressive cleanup.
+The time frame can be lowered for a more aggressive cleanup.
 
 Alternatively, this will also clean old containers:
 
@@ -126,7 +126,7 @@ to clone the repository at the start of the job, for example:
 A workaround is to reboot the runner's virtual machine. It might be
 that we need to do some more configuration of Docker, see [upstream
 issue 6644](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6644), although it's unclear why this problem is happening
-right now. Still to be more fully, see [tpo/tpa/gitlab#93](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/93).
+right now. Still to be more fully investigated, see [tpo/tpa/gitlab#93](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/93).
 
 ## Disaster recovery
 
@@ -145,7 +145,7 @@ GitLab.
 
 ### Docker on Debian
 
-A first runner (`ci-runner-01`) was setup by Puppet in the gnt-chi
+A first runner (`ci-runner-01`) was setup by Puppet in the `gnt-chi`
 cluster, using this command:
 
     gnt-instance add \
@@ -174,10 +174,10 @@ performed:
     NOTE: this was probably already done. If you need a more specific
     runner (say group- or project-specific), a new Role
     (e.g. `roles::gitlab::runner::docker::tpa` could be created and
-    pass a different token (set in trocla like the above).
+    pass a different token (set in Trocla like the above).
     
     TODO: this is one case where the Trocla Hiera support (which we do
-    not currently use), could come in handy. See our [Puppet trocla
+    not currently use), could come in handy. See our [Puppet Trocla
     docs](howto/puppet#trocla) for more details.
 
  2. setup the large partition in `/srv`, and bind-mount it to cover
@@ -312,12 +312,12 @@ We currently use the following tags:
    example, run Docker-inside-Docker (DinD)
  * **memory** size: `64GB`, `32GB`, `4GB`, etc.
  * `privileged`: those containers have actual root access and should
-   explicitely be able to run `DinD`
+   explicitly be able to run `DinD`
  * `interactive web terminal`: supports [interactively debugging
    jobs](https://docs.gitlab.com/ee/ci/interactive_web_terminal/)
  * `fdroid`: provided as a courtesy by the [F-Droid project](https://f-droid.org/)
 
-Use tags in your configuration only if your job can be fullfilled by
+Use tags in your configuration only if your job can be fulfilled by
 only some of those runners. For example, only specify a memory tag if
 your job requires a lot of memory.
 
@@ -435,7 +435,7 @@ see the [log and metrics](#log-and-metrics) section below.
 
 ## Logs and metrics
 
-GitLab runners send logs to syslog and systemd. They contain minimal
+GitLab runners send logs to `syslog` and `systemd`. They contain minimal
 private information: the most I could find were Git repository and
 Docker image URLs, which do contain usernames. Those end up in
 `/var/log/daemon.log`, which gets rotated daily, with a one-week