### Example C# Project Setup Prompt

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/user/gitlab_duo_chat/best_practices.md

This snippet shows an example of a basic prompt for starting a C# project, demonstrating a conversational approach.

```plaintext
c# start project best practices
```

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

### Install Poetry with Mise

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/python_guide/getting_started.md

Installs Poetry using the Mise version manager. This command assumes Mise is already installed and available in your PATH.

```shell
mise install poetry
```

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

### Install Python with Mise

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/python_guide/getting_started.md

Installs a specific version of Python using the Mise version manager. Ensure Mise is installed and configured before running this command.

```shell
mise use python@3.14
```

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

### Create and Install Python Project with Poetry

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/python_guide/getting_started.md

Creates a new Python project, navigates into its directory, and installs its dependencies using Poetry. This requires Poetry to be installed and configured.

```shell
poetry new my_project
cd my_project
poetry install
```

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

### Get started Page Markdown Format

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/documentation/topic_types/get_started.md

This snippet shows the standard Markdown format for a 'Get started' page. It includes placeholders for the title, introductory text, a workflow diagram, and step-by-step instructions with links to further resources. This structure helps users understand the high-level concepts and workflow of a feature area.

```markdown
title: Get started with abc
---

These features work together in this way. You can use them to achieve these goals.
Include a paragraph that ties together the features without describing what
each individual feature does.

Then add this sentence and a diagram. Details about the diagram
file are below.

The process of <abc> is part of a larger workflow:

![Workflow](img/workflow diagram.png)

## Step 1: Do this thing

Each step should group features by workflow. For example, step 1 might be:

`## Step 1: Determine your release cadence`

Then the content can explain milestones, iterations, labels, etc.
The terms can exist elsewhere in the docs, but the descriptions
on this page should be relatively brief.

Finally, add links, in this format:

For more information, see:

- [Create your first abc](link.md).
- [Learn more about abc](link.md).

## Step 2: The next thing

Don't link in the body content. Save links for the `for more information` area.

For more information, see:

- [Create your first abc](link.md).
- [Learn more about abc](link.md).

```

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

### Initial GitLab Configuration Setup

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/install/self_compiled/_index.md

This snippet performs the initial setup for GitLab configuration. It navigates to the GitLab installation directory, copies example configuration files for gitlab.yml and secrets.yml, and sets appropriate permissions. It also ensures that the log and tmp directories are writable by the 'git' user and have the correct permissions for GitLab to operate.

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

# 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/

# 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/

# 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

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

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

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

# 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

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

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

### Node.js Application Setup for Scanning

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/tutorials/dependency_scanning.md

A basic Node.js application setup using the Fastify framework. This code defines server routes and starts the server, serving static files. It's used as an example application to demonstrate dependency scanning.

```javascript
// Require the framework and instantiate it
const fastify = require('fastify')({ logger: true })
const path = require('path')
//const fetch = require('node-fetch')

fastify.register(require('fastify-static'), {
  root: path.join(__dirname, 'public'),
  prefix: '/'
})

fastify.register(require('./routes'), {
  message: "hello"
})

// fastify.register(require('fastify-redis'), { url: constants.redisUrl, /* other redis options */ })

// Run the server!
const start = async () => {
  try {
    await fastify.listen(8080, "0.0.0.0")
    fastify.log.info(`server listening on ${fastify.server.address().port}`)

  } catch (error) {
    fastify.log.error(error)
    //process.exit(1)
  }
}
start()

```

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

### Install Poetry with Curl

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/python_guide/getting_started.md

Installs Poetry, a Python dependency management tool, using a curl command to download and execute the installation script. This method requires Python 3 to be installed.

```shell
curl --silent --show-error --location "https://install.python-poetry.org" | python3 -
```

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

### Markdown Ordered List Example

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/documentation/styleguide/_index.md

Provides an example of an ordered list in Markdown, used for sequential steps. Each item should start with '1.' and be followed by the step description. Blank lines are required before and after the list.

```markdown
Follow these steps to do something.

1. First, do the first step.
1. Then, do the next step.
1. Finally, do the last step.
```

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

### Install GitLab Observability (Shell)

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/operations/observability.md

Shell commands to clone the GitLab Observability repository, navigate into the deployment directory, and start the services using Docker Compose. Includes an option to increase the HTTP timeout for `docker-compose up` if needed.

```shell
cd /mnt/data
git clone -b main https://gitlab.com/gitlab-org/embody-team/experimental-observability/gitlab_o11y.git
cd gitlab_o11y/deploy/docker
docker-compose up -d
```

```shell
COMPOSE_HTTP_TIMEOUT=300 docker-compose up -d
```

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

### Start Gitaly Service using systemd

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/install/self_compiled/_index.md

This command starts the Gitaly service using systemd. It assumes that the systemd service unit for Gitaly has already been installed and configured. This is the recommended method for starting Gitaly on systems using systemd.

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

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

### Start GitLab Instance (systemd)

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/install/self_compiled/_index.md

Starts the GitLab instance on systems that use systemd as their init system.

```shell
sudo systemctl start gitlab.target
```

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

### Go Hello World Program

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/tutorials/scan_execution_policy/_index.md

A basic 'Hello, World!' program written in Go. This serves as a simple project to demonstrate the setup and testing of a scan execution policy. It requires no external dependencies beyond a Go environment.

```go
package main
import "fmt"
func main() {
    fmt.Println("Hello world")
}
```

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

### Initialize Go Component Project Structure with Shell Commands

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/ci/components/examples.md

This snippet shows the shell commands used to initialize a new project for a Go CI/CD component. It includes setting up Git, creating a directory for templates, and generating essential files like README, LICENSE, and .gitlab-ci.yml.

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

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

### Install Jekyll in CI/CD Pipeline

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/user/project/pages/getting_started/pages_from_scratch.md

Defines the script steps within a CI/CD job to install Jekyll and build the static site. It uses Bundler to manage Ruby dependencies.

```yaml
script:
  - gem install bundler
  - bundle install
  - bundle exec jekyll build
```

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

### GDK Setup: Install Bundles

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/data_seeder.md

Installs all the necessary Ruby gem dependencies for the GitLab Development Kit (GDK) using Bundler. This command should be run after starting the GDK services.

```shell
$ bundle install
Bundle complete!
```

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

### Tutorial Markdown Format Example

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/documentation/topic_types/tutorial.md

This snippet provides a template for structuring tutorial Markdown files. It includes essential sections like title, introduction, step-by-step instructions, and optional 'before you begin' content. The format emphasizes clear, sequential guidance for readers.

```markdown
title: Title (starts with "Tutorial:" followed by an active verb, like "Tutorial: Create a website")
---

<!-- vale gitlab_base.FutureTense = NO -->

A paragraph that explains what the tutorial does, and the expected outcome.

To create a website:

1. [Do the first task](#do-the-first-task)
1. [Do the second task](#do-the-second-task)

## Before you begin

This section is optional.

- Thing 1
- Thing 2
- Thing 3

## Do the first task

To do step 1:

1. First step.
1. Another step.
1. Another step.

## Do the second task

Before you begin, make sure you have [done the first task](#do-the-first-task).

To do step 2:

1. First step.
1. Another step.
1. Another step.
```

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

### GDK Setup: Start PostgreSQL and Redis Services

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/data_seeder.md

Starts the PostgreSQL and Redis services required for the GitLab Development Kit (GDK). This is a preliminary step before installing bundles and migrating the database.

```shell
$ gdk start db
ok: run: services/postgresql: (pid n) 0s, normally down
ok: run: services/redis: (pid n) 74s, normally down
```

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

### Example GraphQL Query and Setup

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/graphql_guide/reviewing.md

This snippet demonstrates how to include a sample GraphQL query with setup instructions in a merge request description. It suggests running the query locally using GraphiQL for verification.

```graphql
query GetProjectDetails($fullPath: ID!) {
  project(fullPath: $fullPath) {
    id
    name
    description
  }
}

# Setup: Replace $fullPath with the actual project path, e.g., "gitlab-org/gitlab"
```

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

### Initialize Go Modules (Shell)

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/ci/components/examples.md

Initializes a new Go project by creating a go.mod file. This command is typically run in the root directory of a Go project and specifies the module path.

```shell
go mod init example.gitlab.com/components/golang
```

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

### Docker Setup (Without GDK): Start GitLab EE Instance

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/data_seeder.md

Starts a detached GitLab Enterprise Edition Docker container. This command is used when not using GDK and requires Docker to be installed. The instance will be accessible at http://localhost:8080.

```shell
docker run \
  -p 8080:80 \
  --name gitlab \
  -d \
  gitlab/gitlab-ee:16.9.8-ee.0
```

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

### Start the GitLab Development Kit (Shell)

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/contributing/first_contribution/configure-dev-env-gdk.md

This command starts all the necessary services for the GitLab Development Kit, including the GitLab instance itself, PostgreSQL, Redis, and others. Once running, GitLab will be available at http://127.0.0.1:3000.

```shell
gdk start
```

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

### Install Docker on Ubuntu/Debian (Shell)

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/operations/observability.md

Commands to update package lists, install Docker and Docker Compose, enable and start the Docker service, and add the current user to the docker group. These steps are necessary for setting up a self-hosted GitLab Observability instance.

```shell
sudo apt update
sudo apt install -y docker.io docker-compose
sudo systemctl enable docker
sudo systemctl start docker
sudo usermod -aG docker $(whoami)
```

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

### Install Docker on Amazon Linux (Shell)

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/operations/observability.md

Commands to update package lists, install Docker, enable and start the Docker service, and add the current user to the docker group. These steps are required for setting up a self-hosted GitLab Observability instance on Amazon Linux.

```shell
sudo dnf update
sudo dnf install -y docker
sudo systemctl enable docker
sudo systemctl start docker
sudo usermod -aG docker $(whoami)
```

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

### Initialize Rust Project using Cargo CLI

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/ci/components/examples.md

Demonstrates the command to initialize a new Rust project using the Cargo build system. This command creates the necessary file structure and initial files for a Rust project, including the main source file.

```shell
cargo init
```

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

### GitLab CLI Commands for Project and Pipeline Management

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/tutorials/setup_steps/_index.md

A series of GitLab CLI commands used to manage a project and its CI/CD pipeline. These commands include creating a project, navigating to its directory, creating and committing files, pushing changes, and checking the CI status.

```shell
glab project create zero-to-steps
cd zero-to-steps
touch step.yml
touch .gitlab-ci.yml
git add .
git commit -m 'Part 1 complete'
git push --set-upstream origin main
glab ci status
```

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

### Install and Start Jenkins using Homebrew (Shell)

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/integrations/jenkins.md

Installs the Jenkins service using Homebrew and then starts the Jenkins service. Ensure Homebrew is installed before running these commands.

```shell
brew install jenkins
brew services start jenkins
```

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

### Start Rails Console

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/import_project.md

Commands to start a Ruby on Rails console for GitLab. Differentiates between Omnibus installations and source installations.

```shell
# Omnibus GitLab
gitlab-rails console

# For installations from source
sudo -u git -H bundle exec rails console -e production
```

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

### Setup GitLab from source

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/gitlab_shell/_index.md

Compiles the GitLab Shell binaries and ensures that various paths on the file system exist with the correct permissions. This command should only be used if your installation method documentation instructs you to.

```shell
make setup
```

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

### Rustプロジェクトの初期化

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc-locale/ja-jp/ci/components/examples.md

新しいRustプロジェクトを初期化するためのシェルコマンド。`cargo init`コマンドを使用して、`src/main.rs`の「hello world」サンプルを含む必要なプロジェクトファイルを作成します。

```shell
cargo init

```

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

### Get Group Issues Statistics - Filtering Examples (Plaintext)

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/api/issues_statistics.md

Provides examples of GET requests to retrieve group issues statistics with various query parameters. These examples illustrate filtering by labels, milestones, iids, search terms, author, assignee, reactions, and confidentiality.

```plaintext
GET /groups/:id/issues_statistics
GET /groups/:id/issues_statistics?labels=foo
GET /groups/:id/issues_statistics?labels=foo,bar
GET /groups/:id/issues_statistics?labels=foo,bar&state=opened
GET /groups/:id/issues_statistics?milestone=1.0.0
GET /groups/:id/issues_statistics?milestone=1.0.0&state=opened
GET /groups/:id/issues_statistics?iids[]=42&iids[]=43
GET /groups/:id/issues_statistics?search=issue+title+or+description
GET /groups/:id/issues_statistics?author_id=5
GET /groups/:id/issues_statistics?assignee_id=5
GET /groups/:id/issues_statistics?my_reaction_emoji=star
GET /groups/:id/issues_statistics?confidential=true
```

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

### Example GraphQL Queries

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/api/graphql/getting_started.md

Collection of example GraphQL queries demonstrating data retrieval for groups, projects, and issues.

```APIDOC
## GraphQL Queries

### Description
Examples of GraphQL queries to retrieve specific data from GitLab.

### Method
N/A (These are query structures, not direct endpoints)

### Endpoint
N/A

### Parameters
Refer to the query examples for specific parameters.

### Request Example

**Example 1: Get group details and project names**
```graphql
query {
  group(fullPath: "gitlab-org") {
    id
    name
    projects {
      nodes {
        name
      }
    }
  }
}
```

**Example 2: Get a specific project and issue title**
```graphql
query {
  project(fullPath: "gitlab-org/graphql-sandbox") {
    name
    issue(iid: "2") {
      title
    }
  }
}
```

**Example 3: Get project name and titles of all its issues**
```graphql
query {
  project(fullPath: "gitlab-org/graphql-sandbox") {
    name
    issues {
      nodes {
        title
        description
      }
    }
  }
}
```

### Response
#### Success Response
The structure of the response will mirror the requested fields in the query.

#### Response Example
(Response will vary based on the executed query and available data)
```

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

### HTML for GitLab Pages Website

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/user/project/pages/getting_started/pages_from_scratch.md

A basic HTML file to serve as the content for a GitLab Pages website. This is a simple example that displays a heading.

```html
<html>
<head>
  <title>Home</title>
</head>
<body>
  <h1>Hello World!</h1>
</body>
</html>
```

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

### Install Courier IMAP Server

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/administration/reply_by_email_postfix_setup.md

Installs the courier-imap package and starts the IMAP service. It also ensures the courier-authdaemon is running and configured to start on boot for proper IMAP authentication.

```shell
sudo apt-get install courier-imap
imapd start
sudo service courier-authdaemon start
sudo systemctl enable courier-authdaemon
```

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

### Basic Go Program for Testing CI/CD Component (Go)

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/ci/components/examples.md

A simple Go program that prints 'Hello, CI/CD Component' to the console. This can be used as a basic test case for CI/CD components involving Go projects.

```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")
}
```

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

### Define External OmniAuth Providers (Source)

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/integration/omniauth.md

This configuration defines a list of external OmniAuth providers. Users signing in through these providers are marked as external and do not get access to internal projects. This is for self-compiled (source) installations. Example providers include 'saml' and 'google_oauth2'.

```yaml
omniauth:
  external_providers: ['saml', 'google_oauth2']
```

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

### Markdown Structure for GitLab Duo Prompt Examples

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/documentation/topic_types/prompt_example.md

This snippet shows the standard Markdown structure for creating a prompt example page for GitLab Duo. It includes sections for title, description, estimates, prerequisites, challenge, approach, steps, tips, and verification.

```markdown
title: Title (active verb + object, like "Refactor legacy code")
---

One-sentence description of when to use this approach.

- Time estimate: X-Y minutes
- Level: Beginner/Intermediate/Advanced
- Prerequisites: What users need before starting

## The challenge

1-2 sentence description of the specific problem this solves.

## The approach

Brief description of the overall strategy and which GitLab Duo tools to use (usually 2-4 key phrases).

### Step 1: [Action verb]

[Specify which GitLab Duo tool to use] Brief description of what this step accomplishes.

```plaintext
Prompt template with placeholders in [brackets]
```

Expected outcome: What should happen when this prompt is used.

### Step 2: [Action verb]

[Specify which GitLab Duo tool to use] Brief description of what this step accomplishes.

```plaintext
Next prompt template with placeholders in [brackets]
```

Expected outcome: What should happen when this prompt is used.

## Tips

- Specific actionable advice for better results
- Common pitfalls to avoid
- How to iterate if first attempt doesn't work

## Verify

Ensure that:

- Quality check 1 - specific and measurable
- Quality check 2 - specific and measurable
- Quality check 3 - specific and measurable
```

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

### Configure GitLab External URL

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/install/azure/_index.md

Sets the external URL for GitLab in the configuration file. This is crucial for correct domain name resolution and HTTPS setup. It also shows how to disable HTTP to HTTPS redirection and comment out SSL certificate paths if not needed.

```ruby
external_url 'https://gitlab-prod.eastus.cloudapp.azure.com'

#nginx['redirect_http_to_https'] = true
#nginx['ssl_certificate'] = "/etc/gitlab/ssl/server.crt"
#nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/server.key"
```

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

### Initialize Docusaurus Site

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/ci/quick_start/tutorial.md

Initializes a new Docusaurus static site generator project within the current directory. This command uses npm to run the Docusaurus initialization wizard, which prompts for site configuration details.

```shell
cd pipeline-tutorial
npm init docusaurus
```

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

### Ruby DatabaseMetric Batch Counters Example

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/internal_analytics/metrics/metrics_instrumentation.md

This Ruby code demonstrates a 'CountIssuesMetric' class inheriting from 'DatabaseMetric', configured for batch counting. It defines custom 'start' and 'finish' methods to specify the ID range for batching and uses a simple 'Issue' relation.

```ruby
module Gitlab
  module Usage
    module Metrics
      module Instrumentations
        class CountIssuesMetric < DatabaseMetric
          operation :count

          start { Issue.minimum(:id) }
          finish { Issue.maximum(:id) }

          relation { Issue }
        end
      end
    end
  end
end
```

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

### Implement Step with Shell Command

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/tutorials/setup_steps/_index.md

Provides the implementation for a GitLab CI/CD step using a shell command. It executes a bash command that echoes a greeting, incorporating the 'who' input parameter. The '---' separates the specification from the implementation.

```yaml
spec:
  inputs:
    who:
      type: string
      default: world
---
exec:
  command:
    - bash
    - -c
    - echo 'hello ${{inputs.who}}'
```

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

### Start GitLab Rails Console (Source Installation)

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/administration/feature_flags/_index.md

Command to start the GitLab Rails console for installations from source, specifically for the production environment. This allows direct manipulation of GitLab's state.

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

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

### Starting a Rails Console Session

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/user/project/integrations/slack.md

These commands show how to start a Rails console session, which is a prerequisite for running the diagnostic and administrative scripts provided in this document. The first command is for Omnibus installations, while the second is for source installations. Ensure you use the correct command based on your GitLab installation method.

```shell
sudo gitlab-rails console -e production
```

```shell
bundle exec rails console -e production
```

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

### Enable GitLab to Start on Boot

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/install/self_compiled/_index.md

This command enables the `gitlab.target` unit, which ensures that GitLab services start automatically when the system boots up. This is a standard practice for ensuring GitLab is available after a server restart.

```shell
sudo systemctl enable gitlab.target
```

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

### Example Pod Output

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/tutorials/configure_gitlab_runner_to_use_gke/_index.md

Illustrates the expected output when `kubectl get pods` is run after a successful GitLab Runner Operator installation. It shows a sample pod name and its status as 'Running', confirming the runners are operational in the cluster.

```plaintext
NAME                             READY   STATUS    RESTARTS   AGE
gitlab-runner-hash-short_hash    1/1     Running   0          5m
```

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

### Example successful job output with remote step

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/tutorials/setup_steps/_index.md

This is an example log output demonstrating a successful GitLab CI/CD pipeline execution after implementing remote steps. It shows the Step Runner version, output from individual steps including the echoed message from the remote step, and confirmation of job success.

```text
Step Runner version: a7c7c8fd
See https://gitlab.com/gitlab-org/step-runner/-/blob/main/CHANGELOG.md for changes.
... 
{"name":"greeting","value":"hello world"}
{"name":"greeting","value":"hello gitlab steps"}
all my greetings say hello world and hello gitlab steps
Cleaning up project directory and file based variables
Job succeeded
```

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

### Start GitLab AI Gateway Container

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/install/install_ai_gateway.md

This command starts the GitLab AI Gateway container. It requires specifying your GitLab instance URL, API URL, and a signing key. Ensure necessary ports are forwarded and the AI gateway tag matches your GitLab version.

```shell
docker run -d -p 5052:5052 -p 50052:50052 \
 -e AIGW_GITLAB_URL=<your_gitlab_instance> \
 -e AIGW_GITLAB_API_URL=https://<your_gitlab_domain>/api/v4/ \
 -e DUO_WORKFLOW_SELF_SIGNED_JWT__SIGNING_KEY="$(cat duo_workflow_jwt.key)" \
 registry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/model-gateway:<ai-gateway-tag> \

```

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

### Define External OmniAuth Providers (Omnibus)

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/integration/omniauth.md

This configuration defines a list of external OmniAuth providers. Users signing in through these providers are marked as external and do not get access to internal projects. This is for the Linux package (Omnibus) installation. Example providers include 'saml' and 'google_oauth2'.

```ruby
gitlab_rails['omniauth_external_providers'] = ['saml', 'google_oauth2']
```

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

### Run Jaeger All-in-One with Docker

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/distributed_tracing.md

This command starts the Jaeger all-in-one service using Docker. It configures various ports for communication and sets an environment variable for Zipkin HTTP port. This is a convenient way to get Jaeger running without manual installation.

```shell
docker run \
  --rm \
  -e COLLECTOR_ZIPKIN_HTTP_PORT=9411  \
  -p 5775:5775/udp \
  -p 6831:6831/udp \
  -p 6832:6832/udp \
  -p 5778:5778 \
  -p 16686:16686 \
  -p 14268:14268 \
  -p 9411:9411 \
  jaegertracing/all-in-one:latest
```

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

### Query Chat for `setup.py` Adjustments

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/user/gitlab_duo/tutorials/fix_code_python_shop.md

This example prompt is designed for GitLab's Chat feature, specifically within the context of a `setup.py` file. It asks for potential adjustments and improvements to the generated Python configuration code for a Flask web application.

```plaintext
You have used Code Suggestions to generate a Python configuration file, `setup.py`,
for a Flask web application. This file includes dependencies for Flask, testing,
and database functionality. If I were to review this file, what might I want
to change and adjust?
```

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

### Placeholder Format Example

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/documentation/topic_types/prompt_example.md

Illustrates the correct format for placeholders within prompt templates, emphasizing descriptive names.

```plaintext
[ClassName]
[file_path]
[specific_framework]
```

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

### Get Public Signing Key - Shell Example

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/api/web_commits.md

Example of how to make a GET request to the Web Commits API to retrieve the public signing key using curl. This demonstrates the full URL and method.

```shell
curl --request GET \
  --url "https://gitlab.example.com/api/v4/web_commits/public_key"
```

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

### Get Latest Pipeline Response Example

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/api/pipelines.md

An example JSON response structure for a successful request to get the latest pipeline details. Includes information such as pipeline ID, status, timestamps, and associated user.

```json
{
    "id": 287,
    "iid": 144,
    "project_id": 21,
    "name": "Build pipeline",
    "sha": "50f0acb76a40e34a4ff304f7347dcc6587da8a14",
    "ref": "main",
    "status": "success",
    "source": "push",
    "created_at": "2022-09-21T01:05:07.200Z",
    "updated_at": "2022-09-21T01:05:50.185Z",
    "web_url": "http://127.0.0.1:3000/test-group/test-project/-/pipelines/287",
    "before_sha": "8a24fb3c5877a6d0b611ca41fc86edc174593e2b",
    "tag": false,
    "yaml_errors": null,
    "user": {
        "id": 1,
        "username": "root",
        "name": "Administrator",
        "state": "active",
        "avatar_url": "https://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80&d=identicon",
        "web_url": "http://127.0.0.1:3000/root"
    },
    "started_at": "2022-09-21T01:05:14.197Z",
    "finished_at": "2022-09-21T01:05:50.175Z",
    "committed_at": null,
    "duration": 34,
    "queued_duration": 6,
    "coverage": null,
    "detailed_status": {
        "icon": "status_success",
        "text": "passed",
        "label": "passed",
        "group": "success",
        "tooltip": "passed",
        "has_details": false,
        "details_path": "/test-group/test-project/-/pipelines/287",
        "illustration": null,
        "favicon": "/assets/ci_favicons/favicon_status_success-8451333011eee8ce9f2ab25dc487fe24a8758c694827a582f17f42b0a90446a2.png"
    },
    "archived": false
}
```

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

### Linux Package Setup: Change Directory to GitLab Installation

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/data_seeder.md

Changes the current working directory to the root of the GitLab installation when using a Linux package. This is necessary to execute subsequent setup scripts correctly.

```shell
cd /opt/gitlab/embedded/service/gitlab-rails
```

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

### Create .gitlab-ci.yml for First Pipeline

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/ci/quick_start/_index.md

This YAML file defines the stages and scripts for a basic GitLab CI/CD pipeline. It includes jobs for building, testing, and deploying, utilizing predefined GitLab CI/CD variables. Ensure you have GitLab runners configured for your project to execute these jobs.

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

```

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

### Add Metadata to GraphQL Example Page

Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/documentation/graphql_styleguide.md

This snippet shows the front matter metadata required at the top of a new GraphQL example page. It includes essential fields like 'stage', 'group', 'info', and 'title', which help categorize and manage documentation content.

```markdown
---
stage: Create
group: Source Code
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: List branch rules for a project by using GraphQL
---

{{</* details */>}}

- Tier: Free, Premium, Ultimate
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{</* /details */>}}

```