Guided Tutorials

Generate CI/CD Pipeline Configuration

Create GitHub Actions, GitLab CI, or Jenkins pipeline configurations tailored to your project. Autohand reads your package.json, existing scripts, and project structure to produce a pipeline that actually fits your stack.

Intermediate 15 min
autohand "Generate a GitHub Actions CI/CD pipeline for this Node.js project. Include lint, test, build, and deploy stages. Use caching for node_modules. Deploy to production on main branch pushes."

What you'll learn

  • How to generate a multi-stage CI/CD pipeline from your existing project structure
  • How to test the workflow locally with act before pushing to GitHub
  • How to customize stages for security audits, staging deploys, and GitLab CI
  • How to configure deployment secrets for Vercel, AWS, or other providers

Before you start

  • Autohand Code installed. Run autohand --version to check. See Your First Autohand Session if you need to install it.
  • A Node.js project with package.json. The prompt works best when your project already has lint and test scripts defined.
  • A GitHub repository with Actions enabled. GitLab CI and Jenkins variants are covered in the Customize stages section.
  • Deployment target in mind. Know where you are deploying: Vercel, AWS, Railway, Fly.io, or a custom server.

Describe your pipeline needs

The default prompt is a good starting point for most Node.js projects. You can make it more specific by describing your environment and deployment target before running it.

Open your project directory and start a session.

bash

cd path/to/your-project
autohand

Then paste the prompt, adjusting the details to match your setup. For a project deploying to Vercel via a preview and production environment:

bash

Generate a GitHub Actions CI/CD pipeline for this Node.js project.
Include lint, test, build, and deploy stages.
Use caching for node_modules with the correct cache key based on package-lock.json.
On pull requests: run lint and test only.
On pushes to main: run the full pipeline and deploy to Vercel production.
Use Node.js 20 and run jobs on ubuntu-latest.

Autohand reads your package.json scripts, identifies your test runner, and builds the workflow file from your actual project rather than a generic template.

Generate the configuration

After you run the prompt, Autohand creates .github/workflows/ci.yml in your project. Here is a representative example of what it produces for a project using ESLint, Vitest, and Vite.

yaml

name: CI/CD

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  lint:
    name: Lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint

  test:
    name: Test
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run test -- --coverage

  build:
    name: Build
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/

  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    needs: build
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist/
      - uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'

Tip: Notice that npm ci is used instead of npm install. Autohand chooses ci because it produces deterministic installs and respects your lockfile exactly. This is always the right choice for CI environments.

Review the workflow file

Before committing, read through the generated YAML and verify a few things.

  • Node version. The generated file uses the version you specified. If your project has a .nvmrc or .node-version file, Autohand uses that value automatically.
  • Script names. Confirm that npm run lint, npm run test, and npm run build match your actual package.json scripts. Autohand reads the file but double-checking takes ten seconds.
  • Cache key. The cache key should reference package-lock.json or yarn.lock depending on your package manager. A wrong key means the cache never hits.
  • Secret names. The deploy step references secrets by name. Note each one and add them to your repository's Settings > Secrets and variables > Actions before pushing.

If anything looks off, describe the issue in the same Autohand session and ask it to fix the specific line. You do not need to start over.

bash

The test script is actually "npm run test:unit" not "npm run test". Fix that in the workflow.

Test locally with act

act is a tool that runs GitHub Actions workflows locally using Docker. It is the fastest way to catch syntax errors and logic bugs before pushing to GitHub.

Install act on macOS.

bash

brew install act

Run a dry-run to see what jobs would execute.

bash

act --dryrun

Run the lint job only to validate the early stages.

bash

act -j lint

If act reports an error in the generated workflow, paste the error output into your Autohand session.

bash

act gave this error when running the lint job:
Error: yaml: line 14: mapping values are not allowed in this context

Fix the workflow YAML.

Tip: act requires Docker to be running. It pulls runner images on first use, which can take a few minutes. Use act -P ubuntu-latest=catthehacker/ubuntu:act-latest for a smaller image that starts faster.

Customize stages

The default prompt generates a four-stage pipeline. Here are prompts to extend it for common requirements.

Add a security audit stage that runs after lint.

bash

Add a security audit stage after lint that runs "npm audit --audit-level=high"
and fails the pipeline if high or critical vulnerabilities are found.

Add a staging deploy step that runs on all pushes to the develop branch.

bash

Add a staging deploy job that runs on pushes to the develop branch.
It should use the same Vercel action but without the --prod flag.
Store the preview URL as a job output and post it as a PR comment.

Generate a GitLab CI equivalent instead of GitHub Actions.

bash

Now generate the equivalent pipeline as a GitLab CI .gitlab-ci.yml file.
Use the node:20-alpine Docker image. Keep the same stages.

Autohand generates the GitLab format automatically, translating caching, artifacts, and conditional logic into GitLab CI syntax.

Add deployment secrets

The generated deploy step references secrets that you must add to your GitHub repository before the workflow can run successfully.

Go to your repository on GitHub, then navigate to Settings > Secrets and variables > Actions > New repository secret. Add each secret the workflow references.

For a Vercel deployment, you need three secrets.

bash

# Get these values from the Vercel dashboard or CLI
vercel env ls         # shows project environment info
vercel whoami         # confirms your account

For AWS deployments using aws-actions/configure-aws-credentials, ask Autohand for the IAM policy you need.

bash

What IAM permissions does the deploy job need?
We're deploying a static site to S3 and invalidating a CloudFront distribution.

Autohand outputs the exact IAM policy JSON you need to attach to a deployment role, along with instructions for creating the role in AWS.

Tip: Never put secrets directly in your workflow YAML. Always reference them with ${{ secrets.SECRET_NAME }}. Autohand always generates secrets references this way and will flag it if you accidentally try to inline a value.

What you learned

  • Generated a GitHub Actions CI/CD pipeline with lint, test, build, and deploy stages
  • Reviewed the workflow file for correct Node versions, script names, and cache keys
  • Tested the pipeline locally with act before pushing to GitHub
  • Extended the pipeline with security audits, staging deploys, and alternative CI providers

Try next

autohand "Add a staging environment to the pipeline that deploys on pushes to develop and posts the preview URL as a PR comment"

Related tutorials

Write Database Migrations

Generate safe, reversible migration scripts with proper up and down functions.

Automate Release Notes from Git History

Generate well-organized release notes from your commit history grouped by type.