### GitHub Actions Setup for Wodby CLI

Source: https://wodby.com/docs/2.0/cicd/third-party

The `wodby/actions/setup-wodby-cli@v1` action in GitHub Actions automatically installs the Wodby CLI, exports the `WODBY_API_KEY`, and runs `wodby ci init` if `app-service-id` is provided. This simplifies integration for GitHub Actions users.

```yaml
steps:
  - uses: wodby/actions/setup-wodby-cli@v1
    with:
      app-service-id: "${{ env.APP_SERVICE_ID }}"
```

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

### Wodby CI Pipeline Example

Source: https://wodby.com/docs/2.0/cicd/wodby-ci?q=

This is a complete example of a Wodby CI pipeline configuration file. It includes defining workflows, jobs, and steps for building, releasing, and deploying an application.

```yaml
version: 0.1

workflows:
  main:
    jobs:
      - build

jobs:
  build:
    steps:
      - clone

      - cache_restore:
          path: ~/.composer
          key: 'composer-{{ hash "composer.lock" }}-v1'

      - run: wget -qO- https://api.wodby.com/v1/get/cli | sh
      - run: wodby ci init $WODBY_BUILD_ID
      - run: wodby ci run -v $HOME/.composer:/home/wodby/.composer -- composer install -n --no-ansi

      - cache_save:
          key: 'composer-{{ hash "composer.lock" }}-v1'
          path: ~/.composer

      - run: wodby ci build
      - run: wodby ci release
      - run: wodby ci deploy

```

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

### Selector Match Labels Example

Source: https://wodby.com/docs/2.0/services/workloads?q=

An example of a Kubernetes selector using matchLabels to identify a specific workload based on instance and name labels.

```yaml
selector:
  matchLabels:
    app.kubernetes.io/instance: "{{helm.release}}"
    app.kubernetes.io/name: php

```

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

### Wodby CI Pipeline Configuration

Source: https://wodby.com/docs/2.0/cicd/wodby-ci

Define the CI pipeline for a buildable service. This example includes cloning, restoring composer cache, initializing Wodby CI, installing dependencies, saving cache, and running build, release, and deploy steps.

```yaml
version: 0.1

workflows:
  main:
    jobs:
      - build

jobs:
  build:
    steps:
      - clone

      - cache_restore:
          path: ~/.composer
          key: 'composer-{{ hash "composer.lock" }}-v1'

      - run: wget -qO- https://api.wodby.com/v1/get/cli | sh
      - run: wodby ci init $WODBY_BUILD_ID
      - run: wodby ci run -v $HOME/.semaphore/build/php:/home/wodby/.composer -- composer install -n --no-ansi

      - cache_save:
          key: 'composer-{{ hash "composer.lock" }}-v1'
          path: ~/.composer

      - run: wodby ci build
      - run: wodby ci release
      - run: wodby ci deploy

```

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

### Run Dependency Installation with Wodby CI

Source: https://wodby.com/docs/2.0/cicd/third-party?q=

Use `wodby ci run` for dependency installation or other one-off commands within your CI pipeline.

```bash
wodby ci run ...
```

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

### List Organizations

Source: https://wodby.com/docs/2.0/dev/api

This example demonstrates how to authenticate with an API key and retrieve a list of organizations.

```APIDOC
## GET /orgs

### Description
Retrieves a list of organizations accessible via the API.

### Method
GET

### Endpoint
https://api.wodby.com/v1/orgs

### Authentication
Requires an API key sent in the `X-API-KEY` header.

### Request Example
```bash
export WODBY_API_KEY=...

curl -sS \
  -H "X-API-KEY: ${WODBY_API_KEY}" \
  "https://api.wodby.com/v1/orgs"
```

### Response
#### Success Response (200)
Returns a JSON array of organization objects.

#### Response Example
```json
[
  {
    "id": "org_12345",
    "name": "Example Organization"
  }
]
```
```

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

### Container Image Helm Mapping Example

Source: https://wodby.com/docs/2.0/services/workloads?q=

Configure container image settings for Helm. Set registry to "" to keep the full image path in the repository value.

```yaml
image:
  repository: dagsterWebserver.image.repository
  tag: dagsterWebserver.image.tag
  registry: ""

```

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

### Initialize CI Pipeline with Wodby CLI

Source: https://wodby.com/docs/2.0/cicd

Use `wodby ci init` to start the CI pipeline. Pass `$WODBY_BUILD_ID` for Wodby CI or `$WODBY_APP_SERVICE_ID` for third-party CI. The command automatically detects build and git metadata from common CI providers. If outside these providers, specify `--build-id`, `--build-num`, and `--provider`.

```bash
wodby ci init $WODBY_BUILD_ID
```

```bash
wodby ci init $WODBY_APP_SERVICE_ID
```

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

### Typical CI/CD Workflow Commands

Source: https://wodby.com/docs/2.0/cicd

This sequence outlines a common CI/CD flow using Wodby CLI commands. It includes optional dependency installation, building and pushing images, and deploying the application.

```bash
# Optional one-off commands, for example dependency installation
wodby ci run -- composer install -n --no-ansi

# Build, push, and deploy images
wodby ci build
wodby ci release
wodby ci deploy

```

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

### Build All Buildable Services

Source: https://wodby.com/docs/2.0/cicd/build

Use this command to build all services that are configured for building in the current application configuration.

```bash
wodby ci build
```

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

### Initialize Wodby CI for Other Providers

Source: https://wodby.com/docs/2.0/cicd/third-party?q=

For CI providers that do not automatically detect build metadata, pass `--build-id`, `--build-num`, and `--provider` to `wodby ci init` to ensure Wodby can identify the build correctly.

```bash
wodby ci init $WODBY_APP_SERVICE_ID --build-id "$BUILD_ID" --build-num "$BUILD_NUM" --provider "$PROVIDER"
```

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

### Build All Buildable Services - Wodby CLI

Source: https://wodby.com/docs/2.0/cicd/build?q=

Use this command to build all services that are configured for building in the current application context. The CLI will prioritize the main service if multiple are buildable.

```bash
wodby ci build

```

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

### Initialize Wodby CI Build

Source: https://wodby.com/docs/2.0/dev/cli

Initializes a new build or loads an existing one within the Wodby CI environment. It logs into the Docker registry, discovers the service working directory, and sets up local CI state. Use flags like `--build-id` or `--dind` for specific configurations.

```bash
wodby ci init [OPTIONS] WODBY_APP_SERVICE_ID|WODBY_BUILD_ID

```

```bash
-i, --build-id string 
    Custom build id when auto-detection cannot determine it
-n, --build-num int     
    Custom build number when auto-detection cannot determine it
-c, --context string    
    Build context directory (default: current directory)
    --dind              
    Use docker-in-docker workflow with a data container
    --fix-permissions   
    Fix codebase permissions explicitly
    --provider string   
    Custom CI provider name when auto-detection cannot determine it

```

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

### Typical Wodby CLI CI Workflow

Source: https://wodby.com/docs/2.0/dev/cli?q=

This sequence demonstrates a common CI workflow using the Wodby CLI, including initialization, building, releasing, and deploying services.

```bash
export WODBY_API_KEY=...

wodby ci init 12345
wodby ci build php nginx
wodby ci release php nginx
wodby ci deploy php nginx

```

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

### Example service.yml for Drupal 11 PHP Service

Source: https://wodby.com/docs/2.0/services/template

This example demonstrates a comprehensive service.yml configuration for a Drupal 11 PHP service. It includes settings for versioning, links to other services like Redis, volume definitions, cron jobs, environment variables, Kubernetes workloads, build configurations, Helm settings, and token generation.

```yaml
name: drupal11-php
type: service
from: php
title: PHP (Drupal 11)
labels:
  - drupal
  - drupal11

options:
  - version: "8.3"
    default: true
    eol: "2026-11-23T00:00:00+00:00"

update: auto

links:
  - name: files
    title: Files storage
    required: true
    selectors:
      - type: storage
  - name: redis
    title: Redis
    env:
      - name: REDIS_PORT
        value: "{{link.port}}"
      - name: REDIS_HOST
        value: "{{link.host}}"
      - name: REDIS_PASSWORD
        value: "{{link.tokens.password}}"
        secret: true
    selectors:
      - type: datastore
        labels:
          - redis
      - type: datastore
        labels:
          - valkey

volumes:
  - name: files
    title: Files
    shared: true
    size: 10
    link: files
    path: /mnt/files
    import:
      owner: 82
      group: 82

cron:
  - name: drush
    title: Drupal cron
    command: drush -r ${HTTP_ROOT} -l ${WODBY_PRIMARY_URL} cron
    schedule: "0 0 * * *"

env:
  - name: DRUPAL_FILES_SYNC_SALT
    value: "{{sync_salt}}"
    secret: true
  - name: DRUPAL_HASH_SALT
    value: "{{hash_salt}}"
    secret: true
  - name: DRUPAL_VERSION
    value: "11"

workloads:
  - name: main
    selector:
      matchLabels:
        app.kubernetes.io/instance: "{{helm.release}}"
    kind: deployment
    primary: true
    containers:
      - name: php
        image: wodby/drupal-php
        build: true
        helm:
          resources: resources
          env: extraEnvVars
          mounts: extraVolumeMounts
          image:
            repository: image.repository
            tag: image.tag
            registry: image.registry
            pullPolicy: image.pullPolicy
    helm:
      labels: commonLabels
      annotations: commonAnnotations
      volumes: extraVolumes
      sidecars: extraSidecars

build:
  dockerfile: Dockerfile
  connect: true
  templates:
    - name: vanilla
      title: Vanilla Drupal
      repo: https://github.com/wodby/drupal-vanilla
      branch: 11.x

helm:
  name: wodby
  source: oci://registry-1.docker.io/wodby/php
  chart: oci://registry-1.docker.io/wodby/php
  version: 0.1.0
  imagePullSecrets: image.pullSecrets

settings:
  - name: docroot
    title: Drupal root subdirectory
    description: Composer-based projects usually keep Drupal under the web directory
    placeholder: path/relative/to/git/root
    default: web
    var: DOCROOT_SUBDIR

tokens:
  - name: sync_salt
    generate:
      regex: "[0-9a-z]{32}"
  - name: hash_salt
    generate:
      regex: "[0-9a-z]{32}"

actions:
  - name: clear_cache
    args: ["drush", "cc", "all"]
    type: button
    title: Clear all cache
  - name: user_login
    args: ["make", "user-login"]
    type: output
    title: Generate one-time login link
    privileged: true

```

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

### Kubernetes Selector Example

Source: https://wodby.com/docs/2.0/services/workloads

Specifies a Kubernetes selector using matchLabels to identify a specific workload resource.

```yaml
selector:
  matchLabels:
    app.kubernetes.io/instance: "{{helm.release}}"
    app.kubernetes.io/name: php


```

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

### List Organizations

Source: https://wodby.com/docs/2.0/dev/api?q=

This example demonstrates how to authenticate with the Wodby API using an API key and retrieve a list of organizations.

```APIDOC
## GET /orgs

### Description
Retrieves a list of organizations accessible via the Wodby API.

### Method
GET

### Endpoint
https://api.wodby.com/v1/orgs

### Authentication
Requires an API key sent in the `X-API-KEY` header.

### Request Example
```bash
export WODBY_API_KEY=...

curl -sS \
  -H "X-API-KEY: ${WODBY_API_KEY}" \
  "https://api.wodby.com/v1/orgs"
```

### Response
#### Success Response (200)
Returns a JSON array of organization objects.

### Response Example
```json
{
  "example": "[\n  {\n    \"id\": \"org_123\",\n    \"name\": \"Example Organization\"\n  }\n]"
}
```
```