datarobot-app-framework-cicd

DataRobot Application Templates CI/CD Skill

This skill provides comprehensive guidance for setting up production-grade CI/CD pipelines for DataRobot application templates, including automated testing, review deployments, and continuous delivery.

Quick Start

Default behavior: When a user asks to "set up CI/CD" without specifying a platform or backend, always use the [Simple Path](#simple-path-pulumi-cloud--github-secrets) below — three workflow files, two GitHub Secrets, done. Do not create infra/scripts/, do not add CI/CD tasks to infra/Taskfile.yaml, do not involve GPG encryption unless the user explicitly asks for it.

Only deviate from the simple path when the user specifies:

• A specific Pulumi state backend (Azure Blob, S3, GCS) → use scripts/ and see [Implementation Pattern](#implementation-pattern)
• GitLab CI/CD → see [GitLab CI/CD Configuration](#gitlab-cicd-configuration)
• Many secrets to manage → consider GPG approach in scripts/

Simple Path: Pulumi Cloud + GitHub Secrets

For most data scientists and AI engineers, this is all you need. No GPG encryption, no cloud storage account, no extra scripts.

What to create in the user's repository:

1. Copy the three workflow files to .github/workflows/:

| Source | Destination | Trigger | |--------|-------------|---------| | examples/github-cd-pulumi-cloud.yml | .github/workflows/cd.yml | Automatic — every merge to main | | examples/github-deploy-pulumi-cloud.yml | .github/workflows/deploy-pr.yml | Manual — user picks PR branch + enters stack name (e.g. pr-42) | | examples/github-destroy-pulumi-cloud.yml | .github/workflows/destroy.yml | Manual — user enters stack name to tear down |

1. Create .github/workflows/README.md from examples/workflows-README.md. This is the setup guide that tells the user exactly what secrets and variables to add and how.

1. Tell the user to follow the setup guide in .github/workflows/README.md.

That's it. Do not add anything to infra/Taskfile.yaml or create infra/scripts/ for this path.

Required GitHub Secrets (both required — no defaults):

| Name | Kind | |------|------| | DATAROBOT_API_TOKEN | Secret | | PULUMI_ACCESS_TOKEN | Secret |

Optional GitHub Variable (defaults to ci if not set):

| Name | Kind | Default | |------|------|---------| | PULUMI_STACK_CI_NAME | Variable | ci |

When to use the advanced approach (GPG + DIY backends) instead:

• You have many secrets (GPG encrypts all of .env behind a single passphrase — only one GitHub Secret needed)
• Your organization prohibits Pulumi Cloud and requires a self-managed backend (Azure Blob / S3 / GCS)
• You need GitLab CI/CD

The templates and scripts for all of these are in scripts/ in this skill directory. If the skill has already been propagated to the project's infra/ directory (common in downstream templates), look in infra/scripts/ instead. See the [Implementation Pattern](#implementation-pattern) section below for full setup guidance.

| Scenario | Key files in scripts/ | |----------|------------------------| | Azure Blob / S3 / GCS Pulumi backend | pulumi-setup.sh, taskfile-snippets.yaml | | GitHub Actions + GPG secrets | github-deploy.yml, github-cd.yml, encrypt-secrets.sh, setup-github-secrets.sh | | GitLab CI/CD | gitlab-ci.yml, setup-gitlab-variables.sh |

Adapting the deploy command

The example workflows use uv run pulumi up --yes directly. Before copying them, check infra/Taskfile.yaml — the project may already wrap the deploy command in a task:

cat infra/Taskfile.yaml   # look for 'up-yes', 'deploy', or similar tasks

| What you find | What to use in CI | |---------------|-------------------| | up-yes task | task up-yes — non-interactive, purpose-built for CI; prefer this over raw Pulumi | | deploy task (alias for up) | Avoid — typically runs pulumi up interactively; only safe in CI if you confirm it passes -y internally | | No Taskfile or no relevant task | Keep uv run pulumi up --yes as-is |

To use task in a workflow, add an install step and swap the run command:

- name: Install Task
  run: pip install go-task-bin

- name: Deploy
  working-directory: infra
  env:
    DATAROBOT_API_TOKEN: ${{ secrets.DATAROBOT_API_TOKEN }}
    PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
  run: |
    uv sync --all-extras
    task up-yes

DataRobot API token (service account)

DATAROBOT_API_TOKEN should come from a DataRobot service account — a DataRobot user created for automation, not tied to anyone's personal login. This prevents CI/CD from breaking when the engineer who originally set it up leaves the team.

To set one up: ask your DataRobot admin to create a dedicated user (e.g. ci-bot@your-org.com). Under that account, go to Developer Tools → API Key and generate a token. Store it as the DATAROBOT_API_TOKEN secret in GitHub.

Note: This is purely a DataRobot concept — it has no relation to Pulumi state management or backend configuration. "Service account" here just means a non-personal DataRobot user.

Implementation Pattern

When implementing CI/CD for an application template, follow this structure:

Project Structure:

application-template-root/
├── infra/
│   ├── README.md                   # ⚠️ GENERATE THIS — tailored to the chosen CI/CD platform and Pulumi backend
│   ├── Taskfile.yaml               # ⚠️ CI/CD tasks go HERE — copy from infra/scripts/taskfile-snippets.yaml
│   └── scripts/                    # Copy entire scripts/ directory here
│       ├── README.md               # Copy from scripts/infra-README.md
│       ├── setup-github-secrets.sh
│       ├── setup-gitlab-variables.sh
│       ├── encrypt-secrets.sh
│       ├── decrypt-secrets.sh
│       ├── pulumi-setup.sh
│       ├── gitlab-ci.yml
│       ├── github-deploy.yml
│       ├── github-cd.yml
│       ├── github-destroy.yml
│       └── taskfile-snippets.yaml
├── .env                            # User's secrets (never commit!)
├── .env.gpg                        # Encrypted secrets (commit for GitHub)
├── .gitlab-ci.yml                  # Copy from infra/scripts/gitlab-ci.yml
├── .github/
│   └── workflows/
│       ├── deploy.yml              # Copy from infra/scripts/github-deploy.yml (PR review deploys)
│       ├── cd.yml                  # Copy from infra/scripts/github-cd.yml (push-to-main CD)
│       └── destroy.yml             # Copy from infra/scripts/github-destroy.yml
└── Taskfile.yml                    # Root Taskfile — ADD ONLY one `includes` entry (see below). DO NOT add tasks here.

Key Points:

• ⚠️ ALWAYS generate infra/README.md tailored to the chosen platform and backend — see "Generating infra/README.md" below
• All CI/CD scripts go in infra/scripts/ directory
• ⚠️ CRITICAL: All CI/CD tasks go in infra/Taskfile.yaml — NEVER add CI/CD tasks directly to the root Taskfile.yml
• .env and .env.gpg stay in project root
• Scripts in infra/scripts/ reference ../../.env (two levels up)
• Root Taskfile.yml gets exactly ONE addition: an includes entry pointing to ./infra/Taskfile.yaml
• CI/CD configs (.gitlab-ci.yml, .github/workflows/) are copied to standard locations

Root Taskfile.yml — the only change needed:

# Add this includes block to the existing root Taskfile.yml:
includes:
  infra:
    taskfile: ./infra/Taskfile.yaml
    dir: infra
# Tasks are then run as: task infra:encrypt-secrets, task infra:setup-github-secrets, etc.

Generating infra/README.md

After determining the user's CI/CD platform (GitHub/GitLab) and Pulumi backend, always create infra/README.md with content tailored to their choices. It should cover:

1. Architecture overview — which platform was chosen and why, and which Pulumi backend
2. First-time setup — the exact sequence of task infra:* commands needed to bootstrap
3. Day-to-day tasks — a table or list of