### Install Dependencies and Setup Composer

Source: https://docs.gitlab.com/ci/examples/deployment/composer-npm-deploy

Install necessary packages like zip/unzip and set up Composer for PHP dependency management.

```yaml
before_script:
  - apt-get update
  - apt-get install zip unzip
  - php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
  - php composer-setup.php
  - php -r "unlink('composer-setup.php');"
```

--------------------------------

### GitLab CI Configuration with `needs` Keyword

Source: https://docs.gitlab.com/ci/pipelines/pipeline_architectures

This example demonstrates how to configure jobs with the `needs` keyword to create dependencies. Jobs can start as soon as their specified dependencies are met, improving pipeline efficiency.

```yaml
stages:
  - build
  - test
  - deploy

default:
  image: alpine

build_a:
  stage: build
  script:
    - echo "This job builds something quickly."

build_b:
  stage: build
  script:
    - echo "This job builds something else slowly."

test_a:
  stage: test
  needs: [build_a]
  script:
    - echo "This test job will start as soon as build_a finishes."
    - echo "It will not wait for build_b, or other jobs in the same stage, to finish."

test_b:
  stage: test
  needs: [build_b]
  script:
    - echo "This test job will start as soon as build_b finishes."
    - echo "It will not wait for other jobs in the build stage to finish."

deploy_a:
  stage: deploy
  needs: [test_a]
  script:
    - echo "Since build_a and test_a run quickly, this deploy job can run much earlier."
    - echo "It does not need to wait for build_b or test_b."
  environment: production

deploy_b:
  stage: deploy
  needs: [test_b]
  script:
    - echo "Since build_b and test_b run slowly, this deploy job will run much later."
  environment: production
```

--------------------------------

### Example of `needs` for Out-of-Order Job Execution

Source: https://docs.gitlab.com/ci/yaml

This example demonstrates how to use the `needs` keyword to define job dependencies and allow for parallel execution. Jobs with `needs: []` start immediately, while others wait for specified dependencies to complete.

```yaml
linux:build:
  stage: build
  script: echo "Building linux..."

mac:build:
  stage: build
  script: echo "Building mac..."

lint:
  stage: test
  needs: []
  script: echo "Linting..."

linux:rspec:
  stage: test
  needs: ["linux:build"]
  script: echo "Running rspec on linux..."

mac:rspec:
  stage: test
  needs: ["mac:build"]
  script: echo "Running rspec on mac..."

production:
  stage: deploy
  script: echo "Running production..."
  environment: production
```

--------------------------------

### Application MySQL Configuration Example

Source: https://docs.gitlab.com/ci/services/mysql

Example configuration parameters for an application connecting to the newly created MySQL database.

```text
Host: localhost
User: runner
Password: $password
Database: <your_mysql_database>
```

--------------------------------

### Complete .gitlab-ci.yml for Docker Testing

Source: https://docs.gitlab.com/ci/examples/php

A complete example of a `.gitlab-ci.yml` file for testing PHP projects using the Docker executor, including image selection and dependency installation.

```yaml
default:
  # Select image from https://hub.docker.com/_/php
  image: php:5.6
  before_script:
    # Install dependencies
    - bash ci/docker_install.sh > /dev/null

test:app:
  script:
    - phpunit --configuration phpunit_myapp.xml
```

--------------------------------

### Install PostgreSQL Server

Source: https://docs.gitlab.com/ci/services/postgres

Installs PostgreSQL server and client packages. Ensure you have the necessary permissions.

```shell
sudo apt-get install -y postgresql postgresql-client libpq-dev
```

--------------------------------

### Install PHP and Node.js Dependencies and Run Deploy Script

Source: https://docs.gitlab.com/ci/examples/deployment/composer-npm-deploy

Install PHP dependencies with Composer, Node.js packages with npm, and execute the npm deploy script.

```yaml
before_script:
  # ...
  - php composer.phar install
  - npm install
  - npm run deploy
```

--------------------------------

### GitLab CI/CD Variables Example

Source: https://docs.gitlab.com/ci/migration/teamcity

An example `.gitlab-ci.yml` file demonstrating the use of global and job-specific variables.

```yaml
default:
  image: alpine:latest

stages:
  - greet

variables:
  NAME: "Fern"

english:
  stage: greet
  variables:
    GREETING: "Hello"
  script:
    - echo "$GREETING $NAME"

spanish:
  stage: greet
  variables:
    GREETING: "Hola"
  script:
    - echo "$GREETING $NAME"
```

--------------------------------

### Install MySQL Server

Source: https://docs.gitlab.com/ci/services/mysql

Installs the MySQL server, client, and development libraries on Debian-based systems.

```shell
sudo apt-get install -y mysql-server mysql-client libmysqlclient-dev
```

--------------------------------

### Example .gitlab-ci.yml for Windows Hosted Runners

Source: https://docs.gitlab.com/ci/runners/hosted_runners/windows

This example `.gitlab-ci.yml` file demonstrates how to configure jobs to run on hosted Windows runners. It includes a base job definition for Windows and extends it for build and test stages.

```yaml
.windows_job:
  tags:
    - saas-windows-medium-amd64
  before_script:
    - Set-Variable -Name "time" -Value (date -Format "%H:%m")
    - echo ${time}
    - echo "started by ${GITLAB_USER_NAME} / @${GITLAB_USER_LOGIN}"

build:
  extends:
    - .windows_job
  stage: build
  script:
    - echo "running scripts in the build job"

test:
  extends:
    - .windows_job
  stage: test
  script:
    - echo "running scripts in the test job"
```

--------------------------------

### Docker Command Example with Volume Mounting

Source: https://docs.gitlab.com/ci/docker/using_docker_build

An example of running a Docker container with a volume mount, demonstrating how to share a local directory into the container. This is relevant when discussing potential issues with Docker socket binding.

```shell
docker run --rm -t -i -v $(pwd)/src:/home/app/src test-image:latest run_app_tests
```

--------------------------------

### Comprehensive Input Parameter Configuration

Source: https://docs.gitlab.com/ci/inputs

Configure multiple input parameters with various constraints including mandatory, optional, default values, options, types, and regular expressions. This example demonstrates a more complex setup for a website scanning job.

```yaml
spec:
  inputs:
    job-prefix:     # Mandatory string input
      description: "Define a prefix for the job name"
    job-stage:      # Optional string input with a default value when not provided
      default: test
    environment:    # Mandatory input that must match one of the options
      options: ['test', 'staging', 'production']
    concurrency:
      type: number  # Optional numeric input with a default value when not provided
      default: 1
    version:        # Mandatory string input that must match the regular expression
      type: string
      regex: ^v\d\.\d+(\.\d+)$ 
    export_results: # Optional boolean input with a default value when not provided
      type: boolean
      default: true
---

"$[[ inputs.job-prefix ]]-scan-website":
  stage: $[[ inputs.job-stage ]]
  script:
    - echo "scanning website -e $[[ inputs.environment ]] -c $[[ inputs.concurrency ]] -v $[[ inputs.version ]]"
    - if $[[ inputs.export_results ]]; then echo "export results"; fi
```

--------------------------------

### Install NPM Package

Source: https://docs.gitlab.com/ci/examples/semantic-release

Use npm to install a package from the configured registry. Ensure the package name matches the scope defined in .npmrc.

```shell
npm install --save @gitlab-examples/semantic-release-npm
```

--------------------------------

### Install Docker Build Prerequisites

Source: https://docs.gitlab.com/ci/examples/php

A script to install necessary dependencies like git and PHPUnit within the Docker environment before testing begins. It also installs the PDO MySQL extension.

```shell
#!/bin/bash

# You need to install dependencies only for Docker
[[ ! -e /.dockerenv ]] && exit 0

set -xe

# Install git (the php image doesn't have it) which is required by composer
apt-get update -yqq
apt-get install git -yqq

# Install phpunit, the tool that you will use for testing
curl --location --output /usr/local/bin/phpunit "https://phar.phpunit.de/phpunit.phar"
chmod +x /usr/local/bin/phpunit

# Install mysql driver
# Here you can install any other extension that you need
docker-php-ext-install pdo_mysql

```

--------------------------------

### Example of artifacts:paths

Source: https://docs.gitlab.com/ci/yaml

This example defines job artifacts to include the `.config` file and all files within the `binaries` directory. If `artifacts:name` is not used, the artifact file will be named `artifacts.zip`.

```yaml
job:
  artifacts:
    paths:
      - binaries/
      - .config
```

--------------------------------

### Job with Multiple Services and Base Image

Source: https://docs.gitlab.com/ci/services

This example shows a job using Alpine Linux as the base image but attempting to run commands from PHP, Node.js, and Go, which are not present in the base image. Services defined here are network-accessible, not installed in the job's container.

```yaml
job:
  services:
    - php:8.4
    - node:latest
    - golang:1.25
  image: alpine:3.23
  script:
    - php -v
    - node -v
    - go version
```

--------------------------------

### Use `npm ci` for Package Installation

Source: https://docs.gitlab.com/ci/pipeline_security

Use `npm ci` instead of `npm install` to ensure exact versions are installed from the lock file, promoting reproducibility.

```yaml
javascript-job:
  script:
    - npm ci
```

--------------------------------

### Install Dpl using RubyGems

Source: https://docs.gitlab.com/ci/examples/deployment

Install the Dpl deployment tool using RubyGems. This command can be run locally or within a CI environment that has Ruby installed.

```shell
gem install dpl
```

--------------------------------

### GitLab CI/CD Artifacts Example

Source: https://docs.gitlab.com/ci/migration/teamcity

An example `.gitlab-ci.yml` file showing how to define and use artifacts between jobs.

```yaml
stage:
  - generate
  - use

generate_cat:
  stage: generate
  script:
    - touch cat.txt
    - echo "meow" > cat.txt
  artifacts:
    paths:
      - cat.txt
    expire_in: 1 week

use_cat:
  stage: use
  script:
    - cat cat.txt
```

--------------------------------

### Use `yarn install --frozen-lockfile`

Source: https://docs.gitlab.com/ci/pipeline_security

Use `yarn install --frozen-lockfile` instead of `yarn install` to ensure package versions are strictly adhered to from the lock file.

```yaml
yarn install --frozen-lockfile
```

--------------------------------

### Custom CI/CD Configuration File Examples

Source: https://docs.gitlab.com/ci/pipelines/settings

Examples of specifying custom paths for your CI/CD configuration file. These paths can be relative to the project root, point to a file in another project, or reference a file on an external site.

```yaml
my/path/.gitlab-ci.yml
```

```yaml
my/path/.my-custom-file.yml
```

```yaml
http://example.com/generate/ci/config.yml
```

```yaml
.gitlab-ci.yml@namespace/another-project
```

```yaml
my/path/.my-custom-file.yml@namespace/subgroup/another-project
```

```yaml
my/path/.my-custom-file.yml@namespace/subgroup1/subgroup2/another-project:refname
```

--------------------------------

### Example: Expanding Variables and Truncating Input

Source: https://docs.gitlab.com/ci/inputs

This example demonstrates applying `expand_vars` and `truncate` functions to an input variable. The `expand_vars` function resolves environment variables, and `truncate` limits the output to a specified character range.

```yaml
spec:
  inputs:
    test:
      default: 'test $MY_VAR'
---

test-job:
  script: echo $[[ inputs.test | expand_vars | truncate(5,8) ]]
```

--------------------------------

### Example Relative Paths

Source: https://docs.gitlab.com/ci/testing/code_coverage/coverage_visualization

These are example relative file paths within a C# project that coverage reports might generate.

```plaintext
Auth/User.cs
Lib/Utils/User.cs
```

--------------------------------

### Immediate Start with `needs: []`

Source: https://docs.gitlab.com/ci/yaml/needs

Use `needs: []` to allow a job to start immediately when the pipeline is created, without waiting for other jobs or stages. This is suitable for tasks like linting or scanning that can run independently.

```yaml
stages:
  - build
  - test
  - deploy

build_app:
  stage: build
  script: echo "Building app..."

test_app:
  stage: test
  script: echo "Testing app..."

lint_yaml:
  stage: test
  needs: []
  script: echo "Linting YAML..."

lint_code:
  stage: test
  needs: []
  script: echo "Linting code..."

deploy_app:
  stage: deploy
  script: echo "Deploying app..."
```

--------------------------------

### Install Composer Dependencies in GitLab CI

Source: https://docs.gitlab.com/ci/examples/php

Set up your CI environment to install PHP dependencies using Composer. This example caches the vendor directory to speed up subsequent builds.

```yaml
# Composer stores all downloaded packages in the vendor/ directory.
# Do not use the following if the vendor/ directory is committed to
# your git repository.
default:
  cache:
    paths:
      - vendor/
  before_script:
    # Install composer dependencies
    - wget https://composer.github.io/installer.sig -O - -q | tr -d '\n' > installer.sig
    - php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
    - php -r "if (hash_file('SHA384', 'composer-setup.php') === file_get_contents('installer.sig')) { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
    - php composer-setup.php
    - php -r "unlink('composer-setup.php'); unlink('installer.sig');"
    - php composer.phar install
```

--------------------------------

### Install and Run Carmen in GitLab CI

Source: https://docs.gitlab.com/ci/sustainability/carmen

This job installs Carmen and its dependencies, clones the Carmen repository, installs npm packages, and then runs the carbon-daemon against example data. Ensure your runner has Python 3.12, pip, npm, Git, lsb-release, and bash.

```yaml
carbon-report:
  image: python:3.12
  before_script:
    - apt-get update && apt-get install -y nodejs npm git lsb-release
    - git clone https://github.com/Green-Software-Foundation/if-carmen.git
    - npm install -g "@grnsft/if@1.0.0" "@grnsft/if-plugins@0.3.2" "@grnsft/if-unofficial-plugins@0.3.1"
    - pip install --upgrade pip && pip install -e $CI_PROJECT_DIR/if-carmen
  script:
    - cd $CI_PROJECT_DIR/if-carmen/example-data && carbon-daemon
  artifacts:
    paths:
      - if-carmen/example-data/output/
    expire_in: 1 week
```

--------------------------------

### Component Project Structure Example

Source: https://docs.gitlab.com/ci/components

Illustrates a typical project structure for components, including README files, templates, and documentation.

```yaml
README.md    # with links to the specific docs.md
templates/
  ├── component-1/
  │   ├── template.yml
  │   └── docs.md
  └── component-2/
      ├── template.yml
      └── docs.md
```

--------------------------------

### Example of allow_failure

Source: https://docs.gitlab.com/ci/yaml

This example demonstrates how `allow_failure: true` affects pipeline execution. If `job2` fails, subsequent jobs in the `deploy` stage can still start, unlike `job1` which would block them.

```yaml
job1:
  stage: test
  script:
    - execute_script_1

job2:
  stage: test
  script:
    - execute_script_2
  allow_failure: true

job3:
  stage: deploy
  script:
    - deploy_to_staging
  environment: staging
```

--------------------------------

### Create main.go for Go Component Testing

Source: https://docs.gitlab.com/ci/components/examples

Provides a basic Go program with a main function that prints 'Hello, CI/CD Component'. This serves as a simple test case for the CI/CD component.

```go
// Specify the package, import required packages
// Create a main function
// Inside the main function, print "Hello, CI/CD Component"

package main

import "fmt"

func main() {
  fmt.Println("Hello, CI/CD Component")
}
```

--------------------------------

### Configure Interruptible Jobs with Default Behavior

Source: https://docs.gitlab.com/ci/yaml

This example demonstrates the default behavior of `interruptible` jobs. Jobs are interruptible unless a job with `interruptible: false` has started.

```yaml
workflow:
  auto_cancel:
    on_new_commit: conservative # the default behavior

stages:
  - stage1
  - stage2
  - stage3

step-1:
  stage: stage1
  script:
    - echo "Can be canceled."
  interruptible: true

step-2:
  stage: stage2
  script:
    - echo "Can not be canceled."

step-3:
  stage: stage3
  script:
    - echo "Because step-2 can not be canceled, this step can never be canceled, even though it's set as interruptible."
  interruptible: true
```

--------------------------------

### Example GitLab CI Configuration for RSpec

Source: https://docs.gitlab.com/ci/testing/unit_test_reports

This example shows a typical GitLab CI job configuration for a Ruby project using RSpec. It installs dependencies, runs RSpec with specific formatters to output a JUnit XML report, and configures artifacts to always be uploaded and include the test report.

```yaml
ruby:
  stage: test
  script:
    - bundle install
    - bundle exec rspec --format progress --format RspecJunitFormatter --out rspec.xml
  artifacts:
    when: always
    paths:
      - rspec.xml
    reports:
      junit: rspec.xml
```

--------------------------------

### Download Artifacts Using CI/CD Job Token

Source: https://docs.gitlab.com/ci/jobs/job_artifacts

This example shows how to use a CI/CD job token to authenticate and download artifacts from a different pipeline. Ensure `unzip` is installed.

```yaml
build_submodule:
  stage: test
  script:
    - apt update && apt install -y unzip
    - |
      curl --location --output artifacts.zip \
        --url "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/main/download?job=test&job_token=$CI_JOB_TOKEN"
    - unzip artifacts.zip
```

--------------------------------

### Merged configuration example

Source: https://docs.gitlab.com/ci/yaml/yaml_optimization

Illustrates the resulting merged configuration after applying `extends` and excluding keys.

```yaml
test1:
  script: test
  variables:
    VAR1: test1 var 1
    VAR2: test2 var 2

test2:
  script: test
  variables:
    VAR1: base var 1
    VAR2: test2 var 2

test3:
  script: test
  variables:
    VAR1: base var 1

test4:
  script: test
  variables: null
```

--------------------------------

### Deploy to Heroku using Dpl in GitLab CI/CD

Source: https://docs.gitlab.com/ci/examples/deployment

Configure a GitLab CI/CD job to deploy an application to Heroku. This example installs Dpl and then uses it to deploy a staging app with API key authentication.

```yaml
staging:
  stage: deploy
  script:
    - gem install dpl
    - dpl heroku api --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
  environment: staging
```

--------------------------------

### Configure Application to Use MySQL

Source: https://docs.gitlab.com/ci/services/mysql

Example configuration for an application to connect to the MySQL service. Ensure the user has the necessary permissions.

```yaml
Host: mysql
User: runner
Password: <your_mysql_password>
Database: <your_mysql_database>
```

--------------------------------

### Configure SSH Agent in GitLab CI/CD

Source: https://docs.gitlab.com/ci/jobs/ssh_keys

This script installs `openssh-client`, starts `ssh-agent`, adds your private key, and sets up the `.ssh` directory. Ensure your private key is stored in the `SSH_PRIVATE_KEY` CI/CD variable.

```yaml
before_script:
  ##
  ## Install ssh-agent if not already installed, it is required by Docker.
  ## (change apt-get to yum if you use an RPM-based image)
  ##
  - 'command -v ssh-agent >/dev/null || ( apt-get update -y && apt-get install openssh-client -y )'

  ##
  ## Run ssh-agent (inside the build environment)
  ##
  - eval $(ssh-agent -s)

  ##
  ## Give the right permissions, otherwise ssh-add will refuse to add files
  ## Add the SSH key stored in SSH_PRIVATE_KEY file type CI/CD variable to the agent store
  ##
  - chmod 400 "$SSH_PRIVATE_KEY"
  - ssh-add "$SSH_PRIVATE_KEY"

  ##
  ## Create the SSH directory and give it the right permissions
  ##
  - mkdir -p ~/.ssh
  - chmod 700 ~/.ssh

  ##
  ## Optionally, if you use Git commands, set the user name and email.
  ##
  # - git config --global user.email "user@example.com"
  # - git config --global user.name "User name"
```

--------------------------------

### Jenkinsfile Example

Source: https://docs.gitlab.com/ci/migration/jenkins

A basic Jenkins pipeline defined in Groovy format. Use this as a reference when migrating from Jenkins.

```groovy
pipeline {
    agent any

    stages {
        stage('hello') {
            steps {
                echo "Hello World"
            }
        }
    }
}
```

--------------------------------

### Configure Job Retries

Source: https://docs.gitlab.com/ci/yaml

Set up automatic retries for failed jobs. This example shows basic retry configuration and an advanced setup specifying retry conditions based on exit codes and failure types.

```yaml
test:
  script: rspec
  retry: 2
```

```yaml
test_advanced:
  script:
    - echo "Run a script that results in exit code 137."
    - exit 137
  retry:
    max: 2
    when: runner_system_failure
    exit_codes: 137
```

--------------------------------

### Example Dotenv File Content

Source: https://docs.gitlab.com/ci/variables/dotenv_variables

A sample .env file containing environment variables and their values.

```dotenv
REVIEW_URL=review.example.com/123456
BUILD_VERSION=v1.0.0
```

--------------------------------

### Define default `before_script` in an included file

Source: https://docs.gitlab.com/ci/yaml/includes

Use a `default` section in an included YAML file to apply common commands like setup or installation to all jobs in the pipeline. This promotes consistency across jobs.

```yaml
default:
  before_script:
    - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
    - gem install bundler --no-document
    - bundle install --jobs $(nproc)  "${FLAGS[@]}"
```

--------------------------------

### Use 'default' instead of global keywords

Source: https://docs.gitlab.com/ci/yaml/deprecated_keywords

Globally defined 'image', 'services', 'cache', 'before_script', and 'after_script' are deprecated. Use the 'default' keyword for global configurations.

```yaml
default:
  image: ruby:3.0
  services:
    - docker:dind
  cache:
    paths: [vendor/]
  before_script:
    - bundle config set path vendor/bundle
    - bundle install
  after_script:
    - rm -rf tmp/
```

--------------------------------

### Measure Individual Commands Separately with Eco CI

Source: https://docs.gitlab.com/ci/sustainability/eco_ci

Use this approach to measure specific commands within a job independently. Each command block is wrapped with Eco CI's start and get measurement scripts.

```yaml
build-job:
  image: node:alpine
  before_script:
    - apk add --no-cache curl jq gawk bash git coreutils
  script:
    - !reference [.start_measurement, script]
    - npm install
    - !reference [.get_measurement, script]
    - !reference [.display_results, script]

    - !reference [.start_measurement, script]
    - npm run build
    - !reference [.get_measurement, script]
    - !reference [.display_results, script]

    - !reference [.start_measurement, script]
    - npm test
    - !reference [.get_measurement, script]
    - !reference [.display_results, script]
  artifacts:
    paths:
      - eco-ci-output.txt
      - metrics.txt
    expire_in: 1 week
```

--------------------------------

### Example .gitlab-ci.yml for GPU job

Source: https://docs.gitlab.com/ci/runners/hosted_runners/gpu_enabled

This configuration demonstrates how to set up a CI/CD job to utilize a GPU-enabled runner. It specifies a runner tag, uses an NVIDIA CUDA base image, and installs Python within the job's script.

```yaml
gpu-job:
  stage: build
  tags:
    - saas-linux-medium-amd64-gpu-standard
  image: nvcr.io/nvidia/cuda:12.1.1-base-ubuntu22.04
  script:
    - apt-get update
    - apt-get install -y python3.10
    - python3.10 --version
```

--------------------------------

### Configure Interruptible Jobs with `interruptible` Setting

Source: https://docs.gitlab.com/ci/yaml

This example uses `workflow:auto_cancel:on_new_commit: interruptible` to ensure jobs are interruptible unless explicitly set to `false`. Jobs configured as `interruptible: true` will be canceled if a new pipeline starts.

```yaml
workflow:
  auto_cancel:
    on_new_commit: interruptible

stages:
  - stage1
  - stage2
  - stage3

step-1:
  stage: stage1
  script:
    - echo "Can be canceled."
  interruptible: true

step-2:
  stage: stage2
  script:
    - echo "Can not be canceled."

step-3:
  stage: stage3
  script:
    - echo "Can be canceled."
  interruptible: true
```

--------------------------------

### Configuring Custom Certificates in GitLab CI for Docker-in-Docker

Source: https://docs.gitlab.com/ci/docker/docker_build_troubleshooting

This GitLab CI configuration installs a custom CA certificate into the service container before starting the Docker daemon. This is necessary for Docker commands to trust custom certificates when using Docker-in-Docker.

```yaml
image_build:
  stage: build
  image:
    name: docker:19.03
  variables:
    DOCKER_HOST: tcp://localhost:2375
    DOCKER_TLS_CERTDIR: ""
    CA_CERTIFICATE: "$CA_CERTIFICATE"
  services:
    - name: docker:19.03-dind
      command:
        - /bin/sh
        - -c
        - |
          echo "$CA_CERTIFICATE" > /usr/local/share/ca-certificates/custom-ca.crt && \
          update-ca-certificates && \
          dockerd-entrypoint.sh || exit
  script:
    - docker info
    - docker login -u $DOCKER_USERNAME -p $DOCKER_PASSWORD $DOCKER_REGISTRY
    - docker build -t "${DOCKER_REGISTRY}/my-app:${CI_COMMIT_REF_NAME}" .
    - docker push "${DOCKER_REGISTRY}/my-app:${CI_COMMIT_REF_NAME}"
```

--------------------------------

### Define Job Inputs with Types and Options

Source: https://docs.gitlab.com/ci/yaml

This example demonstrates how to define various job inputs including string options, numbers, booleans, and their default values. It shows how to reference these inputs within the job's script.

```yaml
test_job:
  inputs:
    test_suite:
      default: unit
      description: Which test suite to run
      options: [unit, integration, e2e]
    parallel_count:
      type: number
      default: 5
      description: Number of parallel test runners
    verbose:
      type: boolean
      default: false
      description: Enable verbose test output
  script:
    - 'echo "Running ${{ job.inputs.test_suite }} tests"'
    - 'if [ "${{ job.inputs.verbose }}" == "true" ]; then export TEST_VERBOSE=1; fi'
    - ./run_tests.sh --suite ${{ job.inputs.test_suite }} --parallel ${{ job.inputs.parallel_count }}
```

--------------------------------

### Basic Deployment Job with Inputs

Source: https://docs.gitlab.com/ci/jobs/job_inputs

Define a manual deployment job with string inputs for target environment and version. Inputs are accessed using the `job.inputs` context.

```yaml
deploy:
  when: manual
  inputs:
    target_env:
      default: staging
      description: Target deployment environment
      options: [staging, production]
    version:
      default: latest
      description: Application version to deploy
  script:
    - 'echo "Deploying version ${{ job.inputs.version }} to ${{ job.inputs.target_env }}"'
    - ./deploy.sh --env ${{ job.inputs.target_env }} --version ${{ job.inputs.version }}
```

--------------------------------

### Conditional Pod Installation

Source: https://docs.gitlab.com/ci/runners/hosted_runners/macos

Use this script in your CI job to check if dependencies are installed before running `pod install`, preventing unnecessary installations and improving build times.

```shell
bundle exec pod check || bundle exec pod install
```

--------------------------------

### Install Ruby on Debian-based Linux

Source: https://docs.gitlab.com/ci/examples/deployment

Install Ruby development headers on Debian-compatible Linux systems if Ruby is not already present. This is a prerequisite for installing Dpl via RubyGems.

```shell
apt-get update
apt-get install ruby-dev
```

--------------------------------

### Application Database Configuration

Source: https://docs.gitlab.com/ci/services/postgres

Example configuration for an application to connect to the PostgreSQL database. Ensure the password matches the one set during user creation.

```yaml
Host: localhost
User: runner
Password: $password
Database: nice_marmot
```

--------------------------------

### Example Component YAML Configuration

Source: https://docs.gitlab.com/ci/components

Defines a CI/CD component with input parameters and a job. The `stage` input parameter is used to dynamically set the job's stage.

```yaml
spec:
  inputs:
    stage: 
      default: test
---
component-job:
  script: echo job 1
  stage: $[[ inputs.stage ]]
```

--------------------------------

### Use `pip install --require-hashes` or Lock File

Source: https://docs.gitlab.com/ci/pipeline_security

For Python projects, use `pip install -r requirements.txt --require-hashes` or `pip install -r requirements.lock` to ensure exact dependency versions.

```yaml
pip install -r requirements.txt --require-hashes
```

```yaml
pip install -r requirements.lock
```

--------------------------------

### Example Cost Factor Calculation

Source: https://docs.gitlab.com/ci/pipelines/compute_minutes

An example demonstrating the cost factor calculation for a Premium tier user with a 10,000-minute monthly compute quota. This reduced cost factor is applicable under specific conditions related to merge requests and project types.

```text
10,000 / 300,000 = 0.03333333333 cost factor.
```

--------------------------------

### Execute Docker Build Script

Source: https://docs.gitlab.com/ci/examples/php

Include a `before_script` section in your `.gitlab-ci.yml` to run the prerequisite installation script. Output is redirected to `/dev/null` to keep logs clean.

```yaml
before_script:
  - bash ci/docker_install.sh > /dev/null
```

--------------------------------

### Configure Job Inputs with Options and Types

Source: https://docs.gitlab.com/ci/jobs/job_inputs

Configure job inputs with a default value, description, type, and options. This example demonstrates setting up inputs for test framework, parallel count, integration tests, and test tags.

```yaml
test_job:
  inputs:
    test_framework:
      default: rspec
      description: Testing framework to use
      options: [rspec, minitest, cucumber]
    parallel_count:
      type: number
      default: 5
      description: Number of parallel test jobs
    run_integration_tests:
      type: boolean
      default: false
      description: Whether to run integration tests
    test_tags:
      type: array
      default: [smoke, regression]
      description: Test tags to run
  script:
    - bundle exec ${{ job.inputs.test_framework }}
    - 'echo "Running ${{ job.inputs.parallel_count }} parallel jobs"'
```

--------------------------------

### Configure Application to Use PostgreSQL

Source: https://docs.gitlab.com/ci/services/postgres

Example configuration for an application to connect to the PostgreSQL service using defined variables.

```yaml
Host: postgres
User: $POSTGRES_USER
Password: $POSTGRES_PASSWORD
Database: $POSTGRES_DB
```

--------------------------------

### Define Default and Job-Specific Variables

Source: https://docs.gitlab.com/ci/yaml

This example shows how default variables are applied and how job-specific variables can override them. The default `DEPLOY_SITE` is used in `deploy_job`, while `deploy_review_job` uses its own `DEPLOY_SITE` and an additional `REVIEW_PATH`.

```yaml
variables:
  DEPLOY_SITE: "https://example.com/"

deploy_job:
  stage: deploy
  script:
    - deploy-script --url $DEPLOY_SITE --path "/"
  environment: production

deploy_review_job:
  stage: deploy
  variables:
    DEPLOY_SITE: "https://dev.example.com/"
    REVIEW_PATH: "/review"
  script:
    - deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
  environment: production
```

--------------------------------

### Install semantic-release dependencies

Source: https://docs.gitlab.com/ci/examples/semantic-release

Install the necessary npm packages for semantic-release, including plugins for Git and GitLab integration.

```shell
npm install semantic-release @semantic-release/git @semantic-release/gitlab @semantic-release/npm --save-dev
```

--------------------------------

### Sample .gitlab-ci.yml Configuration

Source: https://docs.gitlab.com/ci/quick_start

This sample file defines four jobs: build-job, test-job1, test-job2, and deploy-prod. It illustrates how to specify stages, scripts, and use predefined variables like $GITLAB_USER_LOGIN and $CI_COMMIT_BRANCH. The comments within echo commands are visible in the UI.

```yaml
build-job:
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  script:
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
  environment: production
```

--------------------------------

### Create and Execute Build Container

Source: https://docs.gitlab.com/ci/services

This command creates a build container from the 'golang:latest' image, links it to the 'service-redis' container, and executes the 'build_script' via stdin.

```shell
docker run --name build -i --link=service-redis:redis golang:latest /bin/bash < build_script
```

--------------------------------

### Initialize Go Component Structure with Shell Commands

Source: https://docs.gitlab.com/ci/components/examples

These shell commands initialize the directory structure and Git repository for a new CI/CD component. They create necessary template files, add them to Git, and set up a remote origin.

```shell
git init

mkdir templates
touch templates/{format,build,test}.yml

touch README.md LICENSE.md .gitlab-ci.yml .gitignore

git add -A
git commit -avm "Initial component structure"

git remote add origin https://gitlab.example.com/components/golang.git

git push
```

--------------------------------

### Example Annotations Report

Source: https://docs.gitlab.com/ci/yaml/artifacts_reports

This JSON structure represents an example of a job annotations report, including external links with labels and URLs.

```json
{
  "my_annotation_section_1": [
    {
      "external_link": {
        "label": "URL 1",
        "url": "https://url1.example.com/"
      }
    },
    {
      "external_link": {
        "label": "URL 2",
        "url": "https://url2.example.com/"
      }
    }
  ]
}
```