Updates after day 2 of 20250514

Author: nicholasdille

160_gitlab_ci/095_scheduling_internals/slides.md

@@ -8,6 +8,30 @@
 
 ## Scheduling Internals
 
-XXX create in DB and enqueue
+How GitLab manages pipelines:
 
-XXX metrics
+1. Receive a trigger event
+1. Determine which jobs to run
+1. Create pipeline, stages and jobs in database
+1. Enqueue jobs if prerequisites are met
+    - All upstream jobs are done
+    - The seletected runner is available
+1. GitLab Runner picks up the job
+1. The log is streamed to GitLab
+1. After completion, GitLab Runner sends the result back to GitLab
+
+Meanwhile the database is continuously updated with the status
+
+---
+
+## Job metrics
+
+GitLab comes with Prometheus metrics:
+
+`ci_pending_builds` - number of jobs waiting to be picked up
+
+`ci_running_builds` - number of jobs currently running
+
+`gitlab_ci_job_failure_reasons` - reasons for job failures
+
+`job_queue_duration_seconds` - histogram data for the time spent in the queue

160_gitlab_ci/097_manual_pipelines/slides.md

@@ -8,10 +8,41 @@
 
 ## Manual Pipelines
 
-XXX [](https://docs.gitlab.com/ci/pipelines/#prefill-variables-in-manual-pipelines)
+<i class="fa-duotone fa-solid fa-4x fa-light-switch-on"></i> <!-- .element: style="float: right;" -->
 
-XXX `variables:description` [](https://docs.gitlab.com/ci/yaml/#variablesdescription)
+Manual trigger from the pipeline overview in the web UI
 
-XXX `variables:value` [](https://docs.gitlab.com/ci/yaml/#variablesvalue)
+Pipeline variables can be added manually
 
-XXX `variables:options` [](https://docs.gitlab.com/ci/yaml/#variablesoptions)
+But simple forms are also possible [](https://docs.gitlab.com/ci/pipelines/#prefill-variables-in-manual-pipelines)
+
+Global variables can have...
+
+- Description in `variables:description` [](https://docs.gitlab.com/ci/yaml/#variablesdescription)
+- Default value in `variables:value` [](https://docs.gitlab.com/ci/yaml/#variablesvalue)
+- Dropdown options in `variables:options` [](https://docs.gitlab.com/ci/yaml/#variablesoptions)
+
+### See also
+
+Pipeline inputs in a later chapter [<i class="fa-solid fa-arrow-right-to-bracket"></i>](#/gitlab_ci_inputs)
+
+---
+
+## Example
+
+Use global variables for basic forms:
+
+```yaml
+variables:
+  favorite_fruit:
+    description: "My favorite fruit"
+    value: apple
+    options:
+    - apple
+    - banana
+    - strawberry
+
+job_name:
+  script: |
+    echo "My favorite fruit is $favorite_fruit"
+```

160_gitlab_ci/120_templates/slides.md

@@ -151,8 +151,6 @@ job_name:
   script: whoami
 ```
 
-But `variables` are merged!
-
 ---
 
 ## Pro tip 2: Solve multiple inheritence
@@ -175,6 +173,8 @@ job_name:
   - !reference[.template2, script]
 ```
 
+CI/CD Components are a proper solution in a later chapter [<i class="fa-solid fa-arrow-right-to-bracket"></i>](#/gitlab_components)
+
 ---
 
 ## Pro tip 3: Organizing templates in repositories
@@ -197,8 +197,6 @@ Separation of concerns
 
 Harder to find/browse, easier to version
 
-Create versions separately
-
 ---
 
 ## Pro tip 4: Public Template Library

160_gitlab_ci/130_rules/exercise.md

@@ -31,7 +31,7 @@ pages:
     - public
 ```
 
-Review the official documentation for the [`rules`](https://docs.gitlab.com/ee/ci/yaml/#rules) keyword to limit the job `pages` to run when...
+Review the official documentation for the [`rules`](https://docs.gitlab.com/ee/ci/yaml/#rules) keyword and the [predefined variables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) to limit the job `pages` to run when...
 
 - the pipeline was triggered by a push event AND
 - the change applied to the default branch

160_gitlab_ci/130_rules/slides.md

@@ -20,6 +20,8 @@ job_name:
   #...
 ```
 
+If no condition matches, the job disappears from the pipeline
+
 Formerly `only`/`except` [](https://docs.gitlab.com/ee/ci/yaml/#only--except) which are "not actively developed"
 
 Official documentation of job control [](https://docs.gitlab.com/ee/ci/jobs/job_control.html)
@@ -51,16 +53,18 @@ Disable execution for some trigger types
 ```yaml
 workflow:
   rules:
-  - if: $CI_PIPELINE_SOURCE == 'push'
-  - if: $CI_PIPELINE_SOURCE == 'web'
-  - if: $CI_PIPELINE_SOURCE == 'schedule'
-  - if: $CI_PIPELINE_SOURCE == 'pipeline'
-  - if: $CI_PIPELINE_SOURCE == 'api'
+  - if: $CI_PIPELINE_SOURCE == 'push'      # Allow triggering through git push
+  - if: $CI_PIPELINE_SOURCE == 'web'       # Allow manally triggered pipelines
+  - if: $CI_PIPELINE_SOURCE == 'schedule'  # Allow scheduled pipelines
+  - if: $CI_PIPELINE_SOURCE == 'pipeline'  # Allow multi-project pipelines
+  - if: $CI_PIPELINE_SOURCE == 'api'       # Prevent pipelines triggered through the API
     when: never
-  - if: $CI_PIPELINE_SOURCE == 'trigger'
+  - if: $CI_PIPELINE_SOURCE == 'trigger'   # Prevent pipelines triggered through trigger tokens
     when: never
 ```
 
+See the pre-defined variables [](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) for more information about the variables
+
 ---
 
 ## Mind the order
@@ -122,7 +126,7 @@ Rules not only control execution of jobs but can also configure jobs through the
 
 Rules become especially powerful when combining the fields supported by rules - including `if`
 
---
+---
 
 ## Pro tip 3: Avoid pipeline on push
 
@@ -139,6 +143,8 @@ my_job:
     when: never
 ```
 
+See the pre-defined variables [](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) for more information about the variables
+
 ---
 
 ## Pro tip 4: Use quotes to help the YAML parser
@@ -190,4 +196,4 @@ Situation:
 
 Possible root cause:
 
-- All job were filtered out due to rules
+- All jobs were filtered out due to rules

160_gitlab_ci/140_merge_requests/exercise.md

@@ -12,13 +12,15 @@ In the last chapter about `rules`, you learned how to use `$CI_PIPELINE_SOURCE`
 
 On the branch `main`, add rules to the jobs to specify when to run them:
 
-1. For the jobs `lint`, `audit`, `unit_tests`, `build` and `test`, add rules so that the jobs are executed when...
+1. Add rules the jobs `lint`, `audit`, `unit_tests`, `build` and `test` so that they are executed when...
     1. pushing to the default branch
     1. running in merge request context
 1. Run the job `trigger` only when pushing to the default branch
 1. Run the job `deploy` only when on the branches `dev` and `live`
 1. Do not modify the existing rules for the job `pages`
 
+Also add the merge request event to the workflow rules to allow the pipeline to run in merge request context.
+
 Afterwards check the pipeline in the GitLab UI. You should see a successful pipeline run.
 
 ??? info "Hint (Click if you are stuck)"
@@ -147,6 +149,7 @@ Afterwards check the pipeline in the GitLab UI. You should see a successful pipe
 Now we want to check which jobs are executed in the context of a merge request:
 
 1. Create a new branch based on `main`
+1. Push a change to the new branch, e.g. small change to the `README.md` file
 1. Create a merge request into `main`
 
 Afterwards check the pipeline in the GitLab UI. You should see a successful pipeline run.

160_gitlab_ci/160_variable_precedence/slides.md

@@ -8,7 +8,7 @@
 
 ## Variable precedence
 
-Variables con be defined on many different levels
+Variables can be defined on many different levels
 
 GitLab has documented the precedence of variables [](https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence)
 

160_gitlab_ci/170_deprecations/slides.md

@@ -8,12 +8,18 @@
 
 ## Deprecations
 
-XXX https://docs.gitlab.com/update/deprecations/
+<i class="fa-duotone fa-solid fa-4x fa-scroll-old"></i> <!-- .element: style="float: right;" -->
 
-XXX https://gitlab-com.gitlab.io/cs-tools/gitlab-cs-tools/what-is-new-since/?tab=deprecations
+GitLab documents deprecations thoroughly [](https://docs.gitlab.com/update/deprecations/)
+
+Rolled out in major version updates (release in May)
+
+Web page for more granular search [](https://gitlab-com.gitlab.io/cs-tools/gitlab-cs-tools/what-is-new-since/?tab=deprecations)
+
+Compiled from deprecation files [](https://gitlab.com/gitlab-org/gitlab/-/tree/master/data/deprecations)
 
 ### Upcoming features
 
-XXX https://about.gitlab.com/upcoming-releases/
+GitLab also documents upcoming features [](https://about.gitlab.com/upcoming-releases/)
 
-XXX https://gitlab-com.gitlab.io/cs-tools/gitlab-cs-tools/what-is-new-since/?tab=features
+Web page for more granular search [](https://gitlab-com.gitlab.io/cs-tools/gitlab-cs-tools/what-is-new-since/?tab=features)

160_gitlab_ci/220_services/slides.md

@@ -10,6 +10,8 @@
 
 Services [](https://docs.gitlab.com/ee/ci/services/index.html) run side-by-side with CI jobs
 
+Useful for integration tests, e.g. database and other backend services
+
 Services can be declared using the `services` keyword [](https://docs.gitlab.com/ee/ci/yaml/#services)
 
 - For all jobs
@@ -45,6 +47,25 @@ job_name:
   script: curl -sv http://nginx
 ```
 
+---
+
 ### Hands-On
 
 See chapter [Services](/hands-on/2025-05-14/220_services/exercise/)
+
+---
+
+## Pro tip: Service logs
+
+Not available in the job log by default
+
+Capture and display them when `CI_DEBUG_TRACE` is set to `true`:
+
+```yaml
+job_name:
+  variables:
+    CI_DEBUG_TRACE: "true"
+  services:
+  - name: nginx:stable
+  script: curl -sv http://nginx
+```

160_gitlab_ci/230_docker/exercise.md

@@ -23,7 +23,7 @@ For building a container image, you will need to...
 1. Use the image `docker:27.3.1` for the job
 1. Add a rule to limit execution to pushes to the default branch
 1. Add a service to the job using the image `docker:27.3.1-dind`
-1. Add a variable `DOCKER_CERT_DIR` to the job and set it to an empty string
+1. Add a variable `DOCKER_TLS_CERTDIR` to the job and set it to an empty string
 1. Execute the command `docker build --tag hello .`
 
 !!! tip "Heads-Up"
@@ -35,9 +35,10 @@ Afterwards check the pipeline in the GitLab UI. You should see a successful pipe
     The service should be set to:
 
     ```yaml
+    variables:
+      DOCKER_TLS_CERTDIR: ""
     services:
     - name: docker:27.3.1-dind
-      command: [ "dockerd", "--host", "tcp://0.0.0.0:2375" ]
     ```
 
 ??? example "Solution (Click if you are stuck)"