The GitLab Container Registry is the built-in registry for storing Docker images and OCI artifacts alongside the source code. It is not an external service like Docker Hub; it is a component of the GitLab instance, accessible at registry.gitlab.com on GitLab.com or at a configured hostname on self-managed instances. The exam tests the CI/CD integration:…
A function is a named block of commands that can be called multiple times within a script. It is the mechanism for eliminating repetition and for encapsulating logic that would otherwise be duplicated. The LFCS exam tests the syntax of the function definition, the scope of variables within a function, the mechanism for returning values,…
The previous chapter covered conditionals: the if statement, the test command, and the case statement. This chapter covers loops: for, while, and until. These are the constructs that repeat a block of commands. The LFCS exam tests the syntax of the for loop over a list and over a range, the while loop with a…
The previous chapter covered special parameters: positional arguments and exit codes. This chapter focuses on conditionals: if, elif, else, case, and the test operators that determine which branch runs. The LFCS exam tests the syntax of the if statement, the difference between [ and [[, and the distinction between numeric comparison and string comparison. The…
The previous chapter covered ordinary variables: assignment, expansion, and quoting. This chapter covers the special parameters that the shell sets automatically: the positional parameters ($1, $2, …), the argument collection ($@ and $*), the argument count ($#), the script name ($0), the exit status ($?), the process ID ($$), and the background job ID ($!)….
The previous chapter introduced the first script: the shebang, the executable permission, and the exit codes. This chapter focuses on the most error-prone part of shell scripting: variables and quoting. A variable holds a string, but the shell treats unquoted strings as a set of words to be split and expanded. A quoted string is…
A GitLab Runner is the agent that executes the jobs defined in the .gitlab-ci.yml file. Without a runner, a pipeline stays in the pending state indefinitely. The runner is a separate process from the GitLab server. It can run on the same machine as the server, on a dedicated build machine, or on a fleet…
A pipeline without variables is a pipeline that hardcodes its configuration. The repository URL, the container registry, the deployment token, the database password—each of these changes between environments, and none of them should be committed to the .gitlab-ci.yml file. GitLab provides predefined variables that describe the pipeline context, and project/group variables that store configuration and…
A pipeline that runs the same jobs on every branch, every commit, and every tag is a pipeline that wastes resources and delays feedback. The rules, only, and except keywords control which jobs run and when. The LFCS exam does not test GitLab, but the GitLab Certified Associate exam does. The critical distinction is that…
The previous chapters established the stage-bound pipeline and the basic needs syntax. This chapter focuses on the DAG model as a whole: how GitLab builds the execution graph, how needs interacts with parallel:matrix, how the pipeline visualization reflects the actual dependencies, and how to debug a pipeline that fails to start because of a cycle…