### Run guided onboarding for Orbit setup

Source: https://docs.gitlab.com/orbit/local/access/glab

Initiates a guided setup process for Orbit. This command verifies reachability, installs the Orbit skill for AI agents, and installs the local Orbit binary.

```bash
glab orbit setup
```

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

### Install and Start GitLab Runner (System Account)

Source: https://docs.gitlab.com/runner/install/windows

Installs GitLab Runner as a service using the built-in system account and then starts the service. Assumes you are in the GitLab Runner directory.

```powershell
cd C:\GitLab-Runner
.\gitlab-runner.exe install
.\gitlab-runner.exe start
```

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

### Install and Start GitLab Runner (User Account)

Source: https://docs.gitlab.com/runner/install/windows

Installs GitLab Runner as a service using a specified user account and then starts the service. You must provide valid username and password. Assumes you are in the GitLab Runner directory.

```powershell
cd C:\GitLab-Runner
.\gitlab-runner.exe install --user ENTER-YOUR-USERNAME --password ENTER-YOUR-PASSWORD
.\gitlab-runner.exe start
```

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

### Install and Start GitLab Runner Service

Source: https://docs.gitlab.com/runner/install/osx

These commands install the GitLab Runner as a service and start it. The `gitlab-runner install` command creates a LaunchAgent plist and registers it with launchctl.

```bash
cd ~
gitlab-runner install
gitlab-runner start
```

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

### Run Xcode First Launch

Source: https://docs.gitlab.com/runner/configuration/macos_setup

Executes the initial setup for Xcode, including agreeing to the license and installing necessary components. This command is required after installing Xcode.

```bash
sudo xcodebuild -runFirstLaunch
```

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

### Install and Start GitLab Runner Service

Source: https://docs.gitlab.com/runner/install/linux-manually

Install GitLab Runner as a system service, specifying the user and working directory. Then, start the service.

```bash
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
```

```bash
sudo gitlab-runner start
```

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

### View Help for the 'run' Command

Source: https://docs.gitlab.com/runner/commands

This example shows how to get detailed help for the `run` command, including its options and environment variable support.

```bash
gitlab-runner run --help
```

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

### Python Script for Storage Analysis Example

Source: https://docs.gitlab.com/user/storage_management_automation

This example demonstrates how to set up environment variables and run a Python script to analyze project storage. It requires the `python-gitlab` library to be installed.

```shell
export GL_TOKEN=xxx
export GL_GROUP_ID=56595735

pip3 install python-gitlab
python3 get_all_projects_top_level_namespace_storage_analysis_cleanup_example.py

Project Developer Evangelism and Technical Marketing at GitLab  / playground / Artifact generator group / Gen Job Artifacts 4 statistics: {
    "commit_count": 2,
    "storage_size": 90241770,
    "repository_size": 3521,
    "wiki_size": 0,
    "lfs_objects_size": 0,
    "job_artifacts_size": 90238249,
    "pipeline_artifacts_size": 0,
    "packages_size": 0,
    "snippets_size": 0,
    "uploads_size": 0
}
```

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

### Example Deployment Job Configuration

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

This is an example of a CI/CD job configured for deployment. It specifies the environment name, URL, and explicitly sets the action to 'start', although this is the default behavior.

```yaml
deploy me:
  script:
    - deploy-to-cats.sh
  environment:
    name: production
    url: https://cats.example.com
    action: start
```

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

### Install and Start GitLab Runner Service on Windows

Source: https://docs.gitlab.com/runner/install/windows

Commands to install and start the GitLab Runner service on Windows. Ensure the user executing the service has the 'SeServiceLogonRight' permission to avoid logon failures.

```bash
gitlab-runner install --password WINDOWS_MACHINE_PASSWORD
gitlab-runner start
```

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

### Example: Ruby Style Guide Instructions

Source: https://docs.gitlab.com/user/gitlab_duo/customize_duo/review_instructions

This example defines instructions for Ruby files, focusing on documentation, style conventions, and the preference for symbols over strings for hash keys. It targets Ruby files in the root and lib directories while excluding test files.

```yaml
instructions:
  - name: Ruby Style Guide
    fileFilters:
      - "*.rb"           # Ruby files in the root directory
      - "lib/**/*.rb"    # Ruby files in lib and its subdirectories
      - "!spec/**/*.rb"  # Exclude test files
    instructions: |
      1. Ensure all methods have proper documentation
      2. Follow Ruby style guide conventions
      3. Prefer symbols over strings for hash keys
```

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

### Example of `needs` for out-of-order execution

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

This example demonstrates how to use `needs` to create multiple execution paths. Jobs with `needs: []` start immediately, while others start as soon as their specified dependencies are met. The `production` job runs after all its preceding jobs 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
```

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

### Install the managed Orbit binary

Source: https://docs.gitlab.com/orbit/local/access/glab

Installs the Orbit binary, verifies its checksum, and keeps it updated. Use this command to get started with Orbit Local.

```bash
glab orbit local --install
```

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

### Configure GitLab Installation

Source: https://docs.gitlab.com/install/self_compiled

Set up essential GitLab configuration files and directories. This includes copying example configuration files, setting permissions, and creating necessary directories for logs, temporary files, and uploads.

```bash
# Go to GitLab installation folder
cd /home/git/gitlab

# Copy the example GitLab config
sudo -u git -H cp config/gitlab.yml.example config/gitlab.yml

# Update GitLab config file, follow the directions at top of the file
sudo -u git -H editor config/gitlab.yml

# Copy the example secrets file
sudo -u git -H cp config/secrets.yml.example config/secrets.yml
sudo -u git -H chmod 0600 config/secrets.yml
```

```bash
# Make sure GitLab can write to the log/ and tmp/ directories
sudo chown -R git log/
sudo chown -R git tmp/
sudo chmod -R u+rwX,go-w log/
sudo chmod -R u+rwX tmp/
```

```bash
# Make sure GitLab can write to the tmp/pids/ and tmp/sockets/ directories
sudo chmod -R u+rwX tmp/pids/
sudo chmod -R u+rwX tmp/sockets/
```

```bash
# Create the public/uploads/ directory
sudo -u git -H mkdir -p public/uploads/

# Make sure only the GitLab user has access to the public/uploads/ directory
# now that files in public/uploads are served by gitlab-workhorse
sudo chmod 0700 public/uploads
```

```bash
# Change the permissions of the directory where CI job logs are stored
sudo chmod -R u+rwX builds/
```

```bash
# Change the permissions of the directory where CI artifacts are stored
sudo chmod -R u+rwX shared/artifacts/
```

```bash
# Change the permissions of the directory where GitLab Pages are stored
sudo chmod -R ug+rwX shared/pages/
```

```bash
# Copy the example Puma config
sudo -u git -H cp config/puma.rb.example config/puma.rb

# Refer to https://github.com/puma/puma#configuration for more information.
# You should scale Puma workers and threads based on the number of CPU
# cores you have available. You can get that number via the `nproc` command.
sudo -u git -H editor config/puma.rb
```

```bash
# Configure Redis connection settings
sudo -u git -H cp config/resque.yml.example config/resque.yml
sudo -u git -H cp config/cable.yml.example config/cable.yml

# Change the Redis socket path if you are not using the default Debian / Ubuntu configuration
sudo -u git -H editor config/resque.yml config/cable.yml
```

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

### Run setup script

Source: https://docs.gitlab.com/runner/configuration/slot_based_cgroups

Commands to make the setup script executable and run it with root privileges.

```bash
chmod +x gitlab-runner-cgroup-setup.sh
sudo ./gitlab-runner-cgroup-setup.sh
```

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

### Start GitLab Rails Console (Source Installation)

Source: https://docs.gitlab.com/administration/feature_flags

Command to start a GitLab Rails console session for installations from source.

```bash
sudo -u git -H bundle exec rails console -e production
```

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

### Example: Instructions for All Files

Source: https://docs.gitlab.com/user/gitlab_duo/customize_duo/review_instructions

This example applies a general instruction to all files in the repository, emphasizing the explanation of the 'why' behind each suggestion made by GitLab Duo.

```yaml
instructions:
  - name: All Files
    fileFilters:
      - "**/*"   # All files in the repository
    instructions: |
      1. Explain the "why" behind each suggestion
```

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

### Install GKE Authentication Plugin

Source: https://docs.gitlab.com/tutorials/configure_gitlab_runner_to_use_gke

Install the plugin required for kubectl to authenticate with GKE clusters. This is a one-time setup.

```bash
gcloud components install gke-gcloud-auth-plugin
```

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

### Enable Git Setup Tracing

Source: https://docs.gitlab.com/topics/git/troubleshooting_git

Use GIT_TRACE_SETUP to trace Git's repository and environment discovery process.

```bash
GIT_TRACE_SETUP=1
```

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

### Start GitLab Rails Console (Linux Package)

Source: https://docs.gitlab.com/administration/feature_flags

Command to start a GitLab Rails console session for Linux package installations.

```bash
sudo gitlab-rails console
```

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

### Running the systemd Setup Script

Source: https://docs.gitlab.com/runner/configuration/slot_based_cgroups

After creating the setup script, make it executable and run it with sudo privileges to apply the systemd slice configurations.

```bash
chmod +x gitlab-runner-systemd-slice-setup.sh
sudo ./gitlab-runner-systemd-slice-setup.sh
```

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

### Example: General Instructions for All Files Except Tests

Source: https://docs.gitlab.com/user/gitlab_duo/customize_duo/review_instructions

This example sets general instructions for all files in the repository, excluding any files identified as tests or specs. It focuses on consistent code style, meaningful comments, and proper error handling.

```yaml
instructions:
  - name: All Files Except Tests
    fileFilters:
      - "!**/*.test.*"   # Exclude all test files
      - "!**/*.spec.*"   # Exclude all spec files
      - "!test/**/*"     # Exclude test directories
      - "!spec/**/*"     # Exclude spec directories
    instructions: |
      1. Follow consistent code style
      2. Add meaningful comments for complex logic
      3. Ensure proper error handling
```

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

### Start Gitaly using systemd

Source: https://docs.gitlab.com/install/self_compiled

Starts the Gitaly service using systemd. This command is used to ensure Gitaly is running before proceeding with other GitLab setup steps.

```bash
sudo systemctl start gitlab-gitaly.service
```

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

### Start GitLab Instance (SysV init)

Source: https://docs.gitlab.com/install/self_compiled

Starts the GitLab instance on systems using the SysV init script.

```bash
sudo service gitlab start
```

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

### Gitaly Log Entry: Daily Scheduled Housekeeping Starts

Source: https://docs.gitlab.com/administration/housekeeping

Example log entry indicating the start of a daily scheduled housekeeping task. It includes the log level, message, process ID, and the scheduled start time.

```json
{"level":"info","msg":"maintenance: daily scheduled","pid":197260,"scheduled":"2023-09-27T13:10:00+13:00","time":"2023-09-27T00:08:31.624Z"}
```

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

### Object Storage Configuration (GCP Example)

Source: https://docs.gitlab.com/administration/reference_architectures/2k_users

Example configuration for enabling and setting up Object Storage with Google Cloud Platform.

```ruby
# Object Storage
# This is an example for configuring Object Storage on GCP
# Replace this config with your chosen Object Storage provider as desired
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
```

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

### Install rbenv and GitLab Runner with Homebrew

Source: https://docs.gitlab.com/runner/configuration/macos_setup

Installs rbenv (a Ruby version manager) and GitLab Runner using Homebrew. It also starts the GitLab Runner service.

```bash
brew install rbenv gitlab-runner
brew services start gitlab-runner
```

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

### Example JSON Log Entry for Sidekiq

Source: https://docs.gitlab.com/administration/logs

This is an example of a single log entry in JSON format, which is the default for GitLab 16.0 and later installations via Helm chart.

```json
{
  "severity":"INFO",
  "time":"2018-04-03T22:57:22.071Z",
  "queue":"cronjob:update_all_mirrors",
  "args":[],
  "class":"UpdateAllMirrorsWorker",
  "retry":false,
  "queue_namespace":"cronjob",
  "jid":"06aeaa3b0aadacf9981f368e",
  "created_at":"2018-04-03T22:57:21.930Z",
  "enqueued_at":"2018-04-03T22:57:21.931Z",
  "pid":10077,
  "worker_id":"sidekiq_0",
  "message":"UpdateAllMirrorsWorker JID-06aeaa3b0aadacf9981f368e: done: 0.139 sec",
  "job_status":"done",
  "duration":0.139,
  "completed_at":"2018-04-03T22:57:22.071Z",
  "db_duration":0.05,
  "db_duration_s":0.0005,
  "gitaly_duration":0,
  "gitaly_calls":0
}
```

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

### Backup Upload Connection Configuration (GCP Example)

Source: https://docs.gitlab.com/administration/reference_architectures/2k_users

Example configuration for setting up backup uploads to Google Cloud Storage.

```ruby
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
```

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

### Production JSON Log Entry Example

Source: https://docs.gitlab.com/administration/logs

This is an example of a structured log entry from the production JSON log file. It details a GET request with performance metrics and request parameters.

```json
{
  "method":"GET",
  "path":"/gitlab/gitlab-foss/issues/1234",
  "format":"html",
  "controller":"Projects::IssuesController",
  "action":"show",
  "status":200,
  "time":"2017-08-08T20:15:54.821Z",
  "params":[{"key":"param_key","value":"param_value"}],
  "remote_ip":"18.245.0.1",
  "user_id":1,
  "username":"admin",
  "queue_duration_s":0.0,
  "gitaly_calls":16,
  "gitaly_duration_s":0.16,
  "redis_calls":115,
  "redis_duration_s":0.13,
  "redis_read_bytes":1507378,
  "redis_write_bytes":2920,
  "correlation_id":"O1SdybnnIq7",
  "cpu_s":17.50,
  "db_duration_s":0.08,
  "view_duration_s":2.39,
  "duration_s":20.54,
  "pid": 81836,
  "worker_id":"puma_0"
}
```

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

### Start GitLab Instance (systemd)

Source: https://docs.gitlab.com/install/self_compiled

Starts the GitLab instance on systems using systemd.

```bash
sudo systemctl start gitlab.target
```

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

### Install and Set Global Ruby Version

Source: https://docs.gitlab.com/runner/configuration/macos_setup

Installs a specific Ruby version (3.3.4 in this example) and sets it as the global default using rbenv. This ensures consistent Ruby environments for jobs.

```bash
rbenv install 3.3.4
rbenv global 3.3.4
```

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

### Cron Period Examples

Source: https://docs.gitlab.com/runner/configuration/advanced-configuration

Examples demonstrating the application of cron syntax for time-based policy activation.

```text
Period

Affect

`1 * * * * *`

Rule enabled for the period of 1 minute every hour (unlikely to be very effective)

`* 0-12 * * *`

Rule enabled for the period of 12 hours at the beginning of each day

`0-30 13,16 * * SUN`

Rule enabled for the period of each Sunday for 30 minutes at 1pm and 30 minutes at 4pm.
```

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

### Configure Incoming Email for Self-Compiled Installation

Source: https://docs.gitlab.com/administration/incoming_email

Configure incoming email processing for GitLab installed from source. This example uses YAML format to set IMAP details and email address patterns.

```yaml
incoming_email:
    enabled: true
    address: "incoming-%{key}@exchange.example.com"
    user: "incoming@ad-domain.example.com"
    password: "[REDACTED]"
    host: "exchange.example.com"
    port: 993
    ssl: true
    delete_after_delivery: true
    expunge_deleted: true
```

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

### Run verify_setup.rb script with bundle exec rails runner

Source: https://docs.gitlab.com/user/duo_agent_platform/troubleshooting

For self-compiled GitLab instances, download `verify_setup.rb`, copy it to your server, and run it from the application directory using `bundle exec rails runner`. Replace `<group/project>` with the full project path.

```bash
sudo -u git bundle exec rails runner \
"load '/tmp/verify_setup.rb'; Gitlab::Duo::Administration::VerifySetup.new('<group/project>').execute"
```

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

### Configure Incoming Email for Linux Package Installation

Source: https://docs.gitlab.com/administration/incoming_email

Set up incoming email processing for GitLab installed via Linux packages. This example configures IMAP settings and specifies the email address format.

```ruby
gitlab_rails['incoming_email_enabled'] = true
gitlab_rails['incoming_email_address'] = "incoming-%{key}@exchange.example.com"
gitlab_rails['incoming_email_email'] = "incoming@ad-domain.example.com"
gitlab_rails['incoming_email_password'] = "[REDACTED]"
gitlab_rails['incoming_email_host'] = "exchange.example.com"
gitlab_rails['incoming_email_port'] = 993
gitlab_rails['incoming_email_ssl'] = true
gitlab_rails['incoming_email_expunge_deleted'] = true
```

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

### Install and Configure Tomcat

Source: https://docs.gitlab.com/administration/integration/plantuml

Downloads, extracts, and sets ownership/permissions for Tomcat.

```bash
wget https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.33/bin/apache-tomcat-10.1.33.tar.gz -P /tmp
sudo tar xzvf /tmp/apache-tomcat-10*tar.gz -C /opt/tomcat --strip-components=1
sudo chown -R tomcat:tomcat /opt/tomcat/
sudo chmod -R u+x /opt/tomcat/bin
```

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

### Dedicated Email Address Configuration for Linux Package Installations

Source: https://docs.gitlab.com/administration/incoming_email

Configure GitLab for a dedicated email address using `gitlab.rb` for Linux package installations. This setup supports Reply by email but not Service Desk.

```ruby
gitlab_rails['incoming_email_enabled'] = true
gitlab_rails['incoming_email_address'] = "incoming@office365.example.com"
gitlab_rails['incoming_email_email'] = "incoming@office365.example.com"
gitlab_rails['incoming_email_password'] = "[REDACTED]"
gitlab_rails['incoming_email_host'] = "outlook.office365.com"
gitlab_rails['incoming_email_port'] = 993
gitlab_rails['incoming_email_ssl'] = true
gitlab_rails['incoming_email_expunge_deleted'] = true
```

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

### Run verify_setup.rb script in Docker container

Source: https://docs.gitlab.com/user/duo_agent_platform/troubleshooting

For Docker installations, download `verify_setup.rb`, copy it into the container, and execute it using `docker exec` with `gitlab-rails runner`. Replace `<container-id>` and `<group/project>` accordingly.

```bash
docker cp verify_setup.rb <container-id>:/tmp/verify_setup.rb
docker exec -it <container-id> gitlab-rails runner \
"load '/tmp/verify_setup.rb'; Gitlab::Duo::Administration::VerifySetup.new('<group/project>').execute"
```

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

### Define a Ruby Job

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

Example of a basic job definition for a Ruby project, including installing dependencies and running a command.

```yaml
my-ruby-job:
  script:
    - bundle install
    - bundle exec my_ruby_command
```

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

### Install Gitaly

Source: https://docs.gitlab.com/install/self_compiled

Installs Gitaly, including fetching source code and compiling with Go. It requires creating and restricting access to the repository data directory. Ensure Gitaly is configured afterwards.

```bash
# Create and restrict access to the git repository data directory
sudo install -d -o git -m 0700 /home/git/repositories

# Fetch Gitaly source with Git and compile with Go
cd /home/git/gitlab
sudo -u git -H bundle exec rake "gitlab:gitaly:install[/home/git/gitaly,/home/git/repositories]" RAILS_ENV=production
```

```bash
sudo -u git -H bundle exec rake "gitlab:gitaly:install[/home/git/gitaly,/home/git/repositories,https://example.com/gitaly.git]" RAILS_ENV=production
```

```bash
# Restrict Gitaly socket access
sudo chmod 0700 /home/git/gitlab/tmp/sockets/private
sudo chown git /home/git/gitlab/tmp/sockets/private

# If you are using non-default settings, you need to update config.toml
cd /home/git/gitaly
sudo -u git -H editor config.toml
```

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

### Restart GitLab Runner Container After Upgrade

Source: https://docs.gitlab.com/runner/install/docker

Start the GitLab Runner container with the same volume mounts as the original installation after pulling the latest image.

```bash
docker run -d --name gitlab-runner --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  gitlab/gitlab-runner:latest
```

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

### Install NGINX

Source: https://docs.gitlab.com/install/self_compiled

Installs the NGINX web server using apt-get.

```bash
sudo apt-get install -y nginx
```

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

### Source: Plaintext Incoming Email Configuration

Source: https://docs.gitlab.com/administration/incoming_email

Example of initial incoming email configuration using plaintext credentials in `/home/git/gitlab/config/gitlab.yml` for self-compiled installations.

```yaml
production:
  incoming_email:
    user: 'incoming-email@mail.example.com'
    password: 'examplepassword'
```

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

### Omnibus: Plaintext Incoming Email Configuration

Source: https://docs.gitlab.com/administration/incoming_email

Example of initial incoming email configuration using plaintext credentials in `/etc/gitlab/gitlab.rb` for Omnibus installations.

```ruby
gitlab_rails['incoming_email_email'] = "incoming-email@mail.example.com"
gitlab_rails['incoming_email_password'] = "examplepassword"
```

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

### Example config.toml with Session Server

Source: https://docs.gitlab.com/runner/configuration/advanced-configuration

This example shows a basic `config.toml` file with the `[session_server]` section configured for terminal support. It includes global settings for concurrency and log level.

```toml
concurrent = 100
log_level = "warning"
log_format = "runner"
check_interval = 3

[session_server]
  listen_address = "[::]:8093"
  advertise_address = "runner-host-name.tld:8093"
  session_timeout = 1800
```

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

### Example Write Benchmark Output

Source: https://docs.gitlab.com/administration/operations/filesystem_benchmarking

This is an example of the output you might see after running the filesystem write benchmark. The 'real' time is the most important metric.

```text
real    0m0.116s
user    0m0.025s
sys     0m0.091s
```

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

### Get Advanced Search Info

Source: https://docs.gitlab.com/integration/advanced_search/elasticsearch

Outputs debugging information for the advanced search integration. Use this task to diagnose issues with your Elasticsearch setup.

```bash
sudo gitlab-rake gitlab:elastic:info
```

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

### Example: TypeScript Source Files Instructions

Source: https://docs.gitlab.com/user/gitlab_duo/customize_duo/review_instructions

This example provides instructions for TypeScript files, emphasizing proper type usage, naming conventions, and documentation for complex functions. It targets all TypeScript files but excludes test and spec files.

```yaml
instructions:
  - name: TypeScript Source Files
    fileFilters:
      - "**/*.ts"        # Typescript files in any directory
      - "!**/*.test.ts"  # Exclude test files
      - "!**/*.spec.ts"  # Exclude spec files
    instructions: |
      1. Ensure proper TypeScript types (avoid 'any')
      2. Follow naming conventions
      3. Document complex functions
```

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

### Example: `interruptible` with default behavior (`conservative`)

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

Demonstrates how `interruptible: true` and `interruptible: false` affect pipeline cancellation with the default `conservative` auto-cancel behavior. Jobs not yet started are always interruptible. Once a job with `interruptible: false` starts, the pipeline is no longer interruptible.

```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
```