CI/CD 2026-03-10

Generate Unique Test IDs for Integration Tests in GitHub Actions

Q: What if I need the same UUID across multiple steps in a job?

Generate the UUID once in an early step and write it to $GITHUB_OUTPUT or $GITHUB_ENV. All subsequent steps in the same job can reference it as ${{ steps.uuid.outputs.test_id }} or $TEST_ID.

Q: How do I track which resources belong to which CI run?

Include the GitHub run URL in resource tags: --tag ci-run-url=https://github.com/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID. This makes cleanup and cost attribution easy in AWS, GCP, and Azure.

Generate collision-free UUIDs for test resources, database seeds, and isolated test environments in GitHub Actions. Prevent test interference between parallel jobs.

⚙️ Uses: UUID Generator — Free

The Problem

Your integration tests create database records, S3 buckets, or Kubernetes namespaces with hardcoded names. When two CI jobs run in parallel — a PR build and a main branch build — they collide on the same resource names, causing intermittent test failures.

Why This Matters

Test isolation is critical for reliable CI. When integration tests share resource names, they interfere with each other — one job's teardown deletes another's setup. UUID-based resource naming gives each job a unique namespace with zero coordination overhead, enabling safe parallel test execution.

Step-by-Step Instructions

Generate a UUID locally using the tool below

Use the UUID generator to create sample UUIDs for your test fixtures and database seed files. Verify the format matches what your database or API expects (UUID v4 is standard for most systems).

Generate a unique run ID at workflow start

Use uuidgen (Linux/macOS) or cat /proc/sys/kernel/random/uuid in your workflow. Or use GitHub's built-in ${{ github.run_id }}-${{ github.run_attempt }} as a shorter unique identifier.

Prefix all test resources with the run ID

Name test databases as testdb_$RUN_ID, S3 buckets as ci-test-$RUN_ID, and Kubernetes namespaces as test-$RUN_ID. This guarantees isolation between parallel jobs.

Clean up resources in a post-job step

Use a job-level if: always() cleanup step that deletes all resources with the run ID prefix. This prevents resource accumulation and keeps CI costs low.

Try It Now — UUID Generator

Open full page →

UUID Generator — Live Demo

All processing happens in your browser — no data is sent to any server.

Before & After Example

Problem: hardcoded test resource names cause parallel job collisions

# Job A and Job B both run simultaneously
# Both create a database named "test_orders"

- name: Setup test database  # Job A
  run: psql -c "CREATE DATABASE test_orders;"

- name: Setup test database  # Job B (runs at same time)
  run: psql -c "CREATE DATABASE test_orders;"
  # ❌ Error: database "test_orders" already exists
  # OR: Job A's teardown drops Job B's data mid-test

Solution: UUID-based resource naming for isolated parallel jobs

name: Integration Tests
on: [push, pull_request]

jobs:
  integration-test:
    runs-on: ubuntu-latest
    env:
      # Unique ID for this specific run attempt
      TEST_RUN_ID: ${{ github.run_id }}-${{ github.run_attempt }}

    steps:
      - uses: actions/checkout@v4

      - name: Generate UUID for test resources
        id: uuid
        run: |
          # Use run ID for traceability, or generate a UUID
          UUID=$(cat /proc/sys/kernel/random/uuid | tr -d '-')
          echo "test_id=ci_${UUID:0:12}" >> $GITHUB_OUTPUT
          echo "Test isolation ID: ci_${UUID:0:12}"

      - name: Create isolated test database
        run: |
          DB_NAME="testdb_${{ steps.uuid.outputs.test_id }}"
          echo "DB_NAME=$DB_NAME" >> $GITHUB_ENV
          psql -c "CREATE DATABASE $DB_NAME;"
          echo "Created isolated database: $DB_NAME"

      - name: Run integration tests
        run: |
          DATABASE_URL="postgresql://localhost/$DB_NAME" \
            pytest tests/integration/ -v --tb=short

      - name: Cleanup test resources
        if: always()  # Runs even if tests fail
        run: |
          echo "Cleaning up: $DB_NAME"
          psql -c "DROP DATABASE IF EXISTS $DB_NAME;"
          echo "✓ Cleanup complete"

Frequently Asked Questions

Should I use UUID v4 or v7 for test IDs?

UUID v4 (random) is fine for test isolation. UUID v7 (time-ordered) is better if you need to sort tests by creation time or use UUIDs as database primary keys (better index performance). The UUID Generator tool creates v4 by default.

What if I need the same UUID across multiple steps in a job?

Generate the UUID once in an early step and write it to $GITHUB_OUTPUT or $GITHUB_ENV. All subsequent steps in the same job can reference it as ${{ steps.uuid.outputs.test_id }} or $TEST_ID.

How do I track which resources belong to which CI run?

Include the GitHub run URL in resource tags: --tag ci-run-url=https://github.com/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID. This makes cleanup and cost attribution easy in AWS, GCP, and Azure.

Related Workflows

🆔

Open the standalone tool for more space, keyboard shortcuts, and additional features.

Open UUID Generator →

← All Developer Guides