CI/CD Patterns & Best Practices

Beyond code review, Gemini CLI in CI/CD supports several high-value automation patterns. Changelog generation: trigger on release tag, have Gemini analyze commits since the last release, and generate a user-facing changelog. Documentation validation: check that code changes are reflected in documentation. Migration safety: analyze database migration files for backward compatibility. Test generation: identify changed functions and generate test stubs.

Security is the critical concern for CI/CD integration. Headless mode means no human in the loop for tool approval. Docker sandbox is strongly recommended for any CI workflow where Gemini executes tools. Constrain prompts to read-only analysis wherever possible. If Gemini must write files (test generation, documentation updates), scope its write access to specific directories and review the output before merging.

name: Generate Changelog
on:
  push:
    tags: ['v*']

jobs:
  changelog:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Install Gemini CLI
        run: npm install -g @google/gemini-cli
      - name: Generate Changelog
        env:
          GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
        run: |
          PREV_TAG=$(git describe --tags --abbrev=0 HEAD~1 2>/dev/null || echo "")
          COMMITS=$(git log ${PREV_TAG:+$PREV_TAG..}HEAD --oneline)
          gemini -p "Generate a user-facing changelog from these commits. Group by Features, Fixes, Improvements. Use clear non-technical language.\n\n$COMMITS" > CHANGELOG_ENTRY.md
      - name: Upload Changelog
        uses: actions/upload-artifact@v4
        with:
          name: changelog
          path: CHANGELOG_ENTRY.md

1. Start with automated PR review Highest value, lowest risk. Read-only analysis, standards enforcement, no file writes. Deploy this first and iterate on prompt quality.
2. Add changelog generation Trigger on release tags. Low risk because output is an artifact, not a commit. Review before publishing.
3. Add documentation validation Compare code changes against documentation. Flag when code changes are not reflected in docs. Read-only analysis.
4. Advanced: test generation Generate test stubs for changed functions. Higher risk because it writes files. Use Docker sandbox and review output in a separate PR.