Chapter 12 — CI/CD Integration

Day 1 — Floci Inside a GitHub Actions Pipeline

1. Concept Primer

Because Floci starts in milliseconds and needs no auth token, it's cheap to spin up fresh per CI job — giving every pipeline run a clean, isolated AWS-shaped environment to deploy into and test against, then throw away.

2. Hands-on Exercise

Write a GitHub Actions workflow that starts Floci, deploys the CloudFormation stack from Chapter 9, and asserts the resources exist — all inside one job.

3. Exact Commands / Config

# .github/workflows/floci-ci.yml
name: floci-integration-test

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Floci
        run: curl -fsSL https://floci.io/install.sh | sh

      - name: Start Floci
        run: floci start -d

      - name: Wait for Floci to be healthy
        run: |
          for i in {1..30}; do
            floci doctor && break
            sleep 1
          done

      - name: Configure AWS CLI env
        run: eval $(floci env) >> $GITHUB_ENV

      - name: Deploy stack
        run: |
          aws cloudformation deploy \
            --template-file stack.yaml \
            --stack-name ci-stack

      - name: Assert resources exist
        run: |
          aws dynamodb list-tables | grep NotesTable
          aws s3 ls | grep notes-bucket-day1

      - name: Tear down
        if: always()
        run: aws cloudformation delete-stack --stack-name ci-stack

4. Gotchas

• eval $(floci env) >> $GITHUB_ENV doesn't work as written in a real workflow — eval runs in a subshell whose exports don't propagate to $GITHUB_ENV automatically. In practice you need to either export each variable individually into $GITHUB_ENV (e.g. echo "AWS_ENDPOINT_URL=http://localhost:4566" >> $GITHUB_ENV) or run every subsequent step inside a script that sources floci env itself. Treat the snippet above as the conceptual shape, and adjust the env-propagation step to your CI's actual mechanics before trusting it to run unattended.
• if: always() on the teardown step matters — without it, a failed assertion step skips cleanup and the next job run may collide with leftover resources.

5. Self-Check

Why is a fresh floci start per CI job generally safer for test isolation than reusing one long-running Floci instance across multiple pipeline runs?