agentleFS
stackqlstackql/stackql-skills/skills/setup-ci/SKILL.md

setup-ci

Skill0 starsChanged 8 months agoMITView on GitHub

Generate CI/CD pipeline configuration for stackql-deploy stacks. Supports GitHub Actions. Creates workflows for build, test, and teardown of cloud infrastructure.

  • Reads credentials
  • Installs packages

6 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

7 rules. 0 are common, 3 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow these steps in order.

    line 15
  2. Distinctive:

    Look for an existing stackql-deploy stack in the current project:

    line 19
  3. Very specific:

    If --stack is specified, use that path.

    line 25
  4. Very specific:

    If no manifest is found, suggest using /stackql-skills:scaffold-stack first.

    line 27
  5. Very specific:

    Read the stackql_manifest.yml to understand:

    line 31
  6. Very specific:

    If --provider is specified, use that.

    line 39
  7. Distinctive:

    Default to GitHub Actions if nothing is detected.

    line 47

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

You are helping the user set up CI/CD pipelines for deploying cloud infrastructure using stackql-deploy.

Input: $@

Follow these steps in order.

Step 1 - Detect the stack

Look for an existing stackql-deploy stack in the current project:

find . -name "stackql_manifest.yml" -not -path '*/.git/*' 2>/dev/null

If --stack is specified, use that path. If multiple manifests are found, ask the user which one to configure.

If no manifest is found, suggest using /stackql-skills:scaffold-stack first.

Step 2 - Read the manifest

Read the stackql_manifest.yml to understand:

  • Stack name
  • Providers used
  • Resources being deployed
  • Variables/parameters needed

Step 3 - Determine the CI provider

If --provider is specified, use that. Otherwise, check for existing CI configuration:

test -d .github/workflows && echo "github-actions"
test -f .gitlab-ci.yml && echo "gitlab"
test -d .circleci && echo "circleci"

Default to GitHub Actions if nothing is detected. Currently supported:

  • github-actions (primary support)

Step 4 - Determine auth requirements

Based on the providers in the manifest, determine what secrets need to be configured:

StackQL ProviderRequired CI Secrets
googleGOOGLE_CREDENTIALS (service account JSON key)
aws / awsccAWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION
azureAZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_SUBSCRIPTION_ID
githubGITHUB_TOKEN (built-in) or a custom PAT

Step 5 - Generate the workflow

GitHub Actions

Create .github/workflows/stackql-deploy.yml:

name: StackQL Deploy

on:
  push:
    branches: [main]
    paths:
      - '<stack-path>/**'
  pull_request:
    branches: [main]
    paths:
      - '<stack-path>/**'
  workflow_dispatch:
    inputs:
      action:
        description: 'Action to perform'
        required: true
        default: 'test'
        type: choice
        options:
          - build
          - test
          - teardown
      environment:
        description: 'Target environment'
        required: true
        default: 'dev'

env:
  STACK_NAME: <stack-name>
  STACK_DIR: <stack-path>

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ github.event.inputs.environment || 'dev' }}

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install stackql-deploy
        run: pip install stackql-deploy

      - name: Install StackQL
        uses: stackql/setup-stackql@v2

      - name: Pull providers
        run: |
          stackql exec "REGISTRY PULL <provider>;"

      # Add auth steps based on provider (see Step 4)

      - name: Test (on PR)
        if: github.event_name == 'pull_request'
        run: |
          stackql-deploy test ${{ env.STACK_NAME }} ${{ github.event.inputs.environment || 'dev' }} \
            --env-file ${{ env.STACK_DIR }}/vars/${{ github.event.inputs.environment || 'dev' }}.json
        env:
          # Provider-specific env vars from secrets

      - name: Build (on push to main)
        if: github.event_name == 'push' || (github.event_name == 'workflow_dispatch' && github.event.inputs.action == 'build')
        run: |
          stackql-deploy build ${{ env.STACK_NAME }} ${{ github.event.inputs.environment || 'dev' }} \
            --env-file ${{ env.STACK_DIR }}/vars/${{ github.event.inputs.environment || 'dev' }}.json
        env:
          # Provider-specific env vars from secrets

      - name: Teardown (manual only)
        if: github.event_name == 'workflow_dispatch' && github.event.inputs.action == 'teardown'
        run: |
          stackql-deploy teardown ${{ env.STACK_NAME }} ${{ github.event.inputs.environment || 'dev' }} \
            --env-file ${{ env.STACK_DIR }}/vars/${{ github.event.inputs.environment || 'dev' }}.json
        env:
          # Provider-specific env vars from secrets

Customize the auth steps based on the provider:

Google:

      - name: Authenticate to Google Cloud
        uses: google-github-actions/auth@v2
        with:
          credentials_json: ${{ secrets.GOOGLE_CREDENTIALS }}

AWS:

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

Azure:

      - name: Azure Login
        uses: azure/login@v2
        with:
          creds: |
            {
              "clientId": "${{ secrets.AZURE_CLIENT_ID }}",
              "clientSecret": "${{ secrets.AZURE_CLIENT_SECRET }}",
              "tenantId": "${{ secrets.AZURE_TENANT_ID }}",
              "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}"
            }

Step 6 - Report

Summarize what was created and what the user needs to do:

  1. Files created: List the workflow file(s)
  2. Secrets to configure: List the repository secrets that need to be set in GitHub (Settings -> Secrets and variables -> Actions)
  3. How it works:
    • PRs run test to validate the stack
    • Push to main runs build to deploy
    • Manual workflow_dispatch supports build, test, and teardown with environment selection
  4. Next steps: Configure the required secrets in the repository settings

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.