android/.claude/skills/reviewing-changes/checklists/infrastructure.md

Infrastructure Review Checklist

Multi-Pass Strategy

First Pass: Understand the Change

1. Identify the goal:

• What problem does this solve?
• Is this optimization, fix, or new capability?
• What's the expected impact?

2. Assess risk:

• Does this affect production builds?
• Could this break CI/CD pipelines?
• Impact on developer workflow?

3. Performance implications:

• Will builds be faster or slower?
• CI time impact?
• Resource usage changes?

Second Pass: Verify Implementation

4. Configuration correctness:

• Syntax valid?
• References correct?
• Secrets/credentials handled securely?

5. Impact analysis:

• What workflows/builds are affected?
• Rollback plan if this breaks?
• Documentation for team?

6. Testing strategy:

• How can this be tested before merge?
• Canary/gradual rollout possible?
• Monitoring for issues post-merge?

What to CHECK

✅ Configuration Correctness

• YAML/Groovy syntax valid
• File references correct
• Version numbers/tags valid
• Conditional logic sound

✅ Security

• No hardcoded secrets or credentials
• GitHub secrets used properly
• Permissions appropriately scoped
• No sensitive data in logs

✅ Performance Impact

• Build time implications understood
• CI queue time impact assessed
• Resource usage reasonable

✅ Rollback Plan

• Can this be reverted easily?
• Dependencies on other changes?
• Gradual rollout possible?

✅ Documentation

• Changes documented for team?
• README or CONTRIBUTING updated?
• Breaking changes clearly noted?

What to SKIP

❌ Bikeshedding Configuration - Unless clear performance/maintenance benefit ❌ Over-Optimization - Unless current system has proven problems ❌ Suggesting Major Rewrites - Unless current approach is fundamentally broken

Red Flags

🚩 Hardcoded secrets - Use GitHub secrets or secure storage 🚩 No rollback plan - Critical infrastructure should be revertible 🚩 Untested changes - CI changes should be validated 🚩 Breaking changes without notice - Team needs advance warning 🚩 Performance regression - Builds shouldn't get significantly slower

Key Questions to Ask

Use reference/review-psychology.md for phrasing:

• "What's the rollback plan if this breaks CI?"
• "Can we test this on a feature branch before main?"
• "Will this impact build times? By how much?"
• "Should this be documented in CONTRIBUTING.md?"

Common Infrastructure Patterns

GitHub Actions

# ✅ GOOD - Secure, clear, tested
name: Build and Test
on:
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 30  # Prevent runaway builds
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        env:
          API_KEY: ${{ secrets.API_KEY }}  # Secure secret usage
        run: ./gradlew test

# ❌ BAD - Insecure, unclear
name: Build
on: push  # Too broad, runs on all branches
jobs:
  build:
    runs-on: ubuntu-latest
    # No timeout - could run forever
    steps:
      - run: |
          export API_KEY="hardcoded_key_here"  # Hardcoded secret!
          ./gradlew test

Gradle Configuration

// ✅ GOOD - Clear, maintainable
dependencies {
    implementation(libs.androidx.core.ktx)  // Version catalog
    implementation(libs.hilt.android)

    testImplementation(libs.junit5)
    testImplementation(libs.mockk)
}

// ❌ BAD - Hardcoded versions
dependencies {
    implementation("androidx.core:core-ktx:1.12.0")  // Hardcoded version
    implementation("com.google.dagger:hilt-android:2.48")
}

Build Optimization

// ✅ GOOD - Parallel, cached
tasks.register("checkAll") {
    dependsOn("detekt", "ktlintCheck", "testStandardDebug")
    group = "verification"
    description = "Run all checks in parallel"

    // Enable caching for faster builds
    outputs.upToDateWhen { false }
}

// ❌ BAD - Sequential, no caching
tasks.register("checkAll") {
    doLast {
        exec { commandLine("./gradlew", "detekt") }
        exec { commandLine("./gradlew", "ktlintCheck") }  // Sequential
        exec { commandLine("./gradlew", "test") }
    }
}

Prioritizing Findings

Use reference/priority-framework.md to classify findings as Critical/Important/Suggested/Optional.

Output Format

See examples/review-outputs.md for the required output format and inline comment structure.

Example Review

## Summary
Optimizes CI build by parallelizing test execution and caching dependencies

Impact: Estimated 40% reduction in CI time (12 min → 7 min per build)

## Critical Issues
None

## Suggested Improvements

**.github/workflows/build.yml:23** - Add timeout for safety
```yaml
jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 30  # Prevent builds from hanging
    steps:
      # ...

This prevents runaway builds if something goes wrong.

.github/workflows/build.yml:45 - Consider matrix strategy for module tests Can we run module tests in parallel using a matrix strategy?

strategy:
  matrix:
    module: [app, data, network, ui]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - run: ./gradlew :${{ matrix.module }}:test

This could further reduce CI time.

build.gradle.kts:12 - Document caching strategy Can we add a comment explaining the caching configuration? Future maintainers will appreciate understanding why these specific cache keys are used.

Rollback Plan

If CI breaks:

• Revert commit: git revert [commit-hash]
• Previous workflow available at: .github/workflows/build.yml@main^
• Monitor CI times at: https://github.com/[org]/[repo]/actions