Files
dance-lessons-coach/adr/0017-trunk-based-development-workflow.md
Gabriel Radureau a24b4fdb3b 📝 docs(adr): homogenize 23 ADRs + rewrite README (Tâche 7 migration) (#18)
## Summary

Homogenize all 23 ADRs to a single canonical header format, and rewrite `adr/README.md` to match the actual state of the corpus.

This is **Tâche 7** of the ARCODANGE Phase 1 migration (Claude Code → Mistral Vibe). Independent from PR #17 (Tâche 6 — restructure AGENTS.md) — both can merge in any order. No code changes; only documentation.

## Changes

### 1. Homogenize 21 ADR headers (commit `db09d0a`)

The audit (Tâche 6 Phase A, Mistral intent-router agent, 2026-05-02) had identified **3 inconsistent header formats** :

- **F1** — list bullets (`* Status:` / `* Date:` / `* Deciders:`) : 11 ADRs (0001-0008, 0011, 0014, 0023)
- **F2** — bold fields (`**Status:**` / `**Date:**` / `**Authors:**`) : 9 ADRs (0009, 0010, 0012, 0013, 0015, 0016, 0017, 0018, 0019)
- **F3** — dedicated section (`## Status\n**Value** `) : 5 ADRs (0020, 0021, 0022, 0024, 0025)

Plus mixed metadata names (Authors / Deciders / Decision Date / Implementation Date / Implementation Status / Last Updated) and decorative emojis on status values made the corpus hard to scan or template against.

**Canonical format adopted** (see `adr/README.md` for full template) :

```markdown
# NN. Title

**Status:** <Proposed | Accepted | Implemented | Partially Implemented | Approved | Rejected | Deferred | Deprecated | Superseded by ADR-NNNN>
**Date:** YYYY-MM-DD
**Authors:** Name(s)

[optional **Field:** ... lines]

## Context...
```

**Transformations applied** (via `/tmp/homogenize-adrs.py` script, 23 files scanned, 21 modified — 0010 and 0012 were already conform) :

- F1 list bullets → bold fields
- F2 cleanup : `**Deciders:**` → `**Authors:**`, strip status emojis
- F3 sections : `## Status\n**Value** ` → `**Status:** Value` (single line)
- Strip decorative emojis from `**Status:**` and `**Implementation Status:**`
- Convert `* Last Updated:` / `* Implementation Status:` / `* Decision Drivers:` / `* Decision Date:` to bold
- Date typo fix : `2024-04-XX` → `2026-04-XX` for ADRs 0018, 0019 (off-by-2-years in original)
- Normalize multiple blank lines after header (max 1)

**ADR body content is preserved unchanged.** Only headers transformed.

### 2. Rewrite `adr/README.md` (commit `d64ab02`)

Previous README had multiple inconsistencies :

- Index table listed wrong titles for ADRs 0010-0021 (looked like an aspirational forecast that never matched reality — e.g. "0011 = Trunk-Based Development" but real 0011 is absent and Trunk-Based Development is actually 0017)
- Listed entries for ADRs 0011 (validation library) and 0014 (gRPC) but **these files do not exist** in the repo
- 0024 (BDD Test Organization) was missing from the detail list
- Template still showed the obsolete F1 format (`* Status:`)
- Decorative emojis on every status entry

Rewrite :

- Index table **regenerated from actual file contents** (title from H1, status from `**Status:**` line) — emoji-free, accurate
- Notes that 0011 / 0014 are not currently in use (reserved)
- Updated template block matches the canonical format
- Status Legend extended with `Approved`, `Partially Implemented`, `Deferred`
- Added note that 0026 is the next free number for new ADRs

## Test plan

- [x] All 23 ADRs follow `**Status:**` / `**Date:**` / `**Authors:**` (verified via grep)
- [x] No more occurrences of `* Status:` (F1) or `## Status` (F3) in any ADR header
- [x] No more emojis on `**Status:**` lines
- [x] `adr/README.md` index links resolve to existing files (no more 0011 / 0014 dead links)
- [x] Pre-commit hooks pass (`go mod tidy`, `go fmt`, `swag fmt`)

## Migration context

Part of Phase 1 of the ARCODANGE migration from Claude Code to Mistral Vibe. Tâche 7 of the curriculum.

Independent from PR #17 (which restructures `AGENTS.md`). The two PRs touch disjoint files — no merge conflict expected when both are merged.

🤖 Generated with [Claude Code](https://claude.com/claude-code) (Opus 4.7, 1M context). Mistral Vibe (intent-router agent / mistral-medium-3.5) did the original audit identifying the 3 formats during Tâche 6 Phase A.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Mistral Vibe (devstral-2 / mistral-medium-3.5)
Reviewed-on: #18
Co-authored-by: Gabriel Radureau <arcodange@gmail.com>
Co-committed-by: Gabriel Radureau <arcodange@gmail.com>
2026-05-03 11:01:13 +02:00

9.8 KiB

17. Trunk-Based Development Workflow for CI/CD Safety

Date: 2026-04-05 Status: Approved Authors: Arcodange Team Decision Date: 2026-04-05 Implementation Status: Implemented

Context

dance-lessons-coach requires a safe workflow for making CI/CD changes to prevent breaking the main branch. The current workflow allows direct pushes to main, which poses risks for CI/CD configuration changes that could break the entire pipeline.

Decision Drivers

  • Safety: Prevent CI/CD misconfigurations from breaking main branch
  • Review Process: Ensure all CI/CD changes are properly reviewed
  • Trunk-Based: Maintain trunk-based development principles
  • Branch Protection: Protect main branch from direct CI/CD changes
  • Validation: Automatically validate workflow changes before merge
  • Rollback: Easy rollback capability for CI/CD issues

Decision

We will implement a Trunk-Based Development Workflow with Branch Protection specifically designed for CI/CD safety.

Selected Architecture: Protected Trunk with Validation Gates

graph TD
    A[Developer] -->|Create Branch| B[ci/* or feature/*]
    B -->|Push Changes| C[Git Server]
    C -->|Trigger| D[CI/CD Pipeline]
    D -->|Run| E[Workflow Validation Job]
    E -->|Success| F[Pull Request]
    F -->|Review| G[Team Review]
    G -->|Approve| H[Merge to Main]
    H -->|Trigger| I[Main Branch Pipeline]
    I -->|Success| J[Production]
    
    E -->|Failure| K[Fix Issues]
    K -->|Loop| B

Workflow Components

1. Branch Strategy

Branch Type Pattern Purpose Protection
Main main Production-ready code 🔒 Fully Protected
CI Updates ci/* CI/CD configuration changes 🛡️ Protected
Features feature/* New functionality 🛡️ Protected
Fixes fix/* Bug fixes 🛡️ Protected
Refactor refactor/* Code improvements 🛡️ Protected

2. Branch Protection Rules

Main Branch Protection:

  • Require pull request reviews (min 1 approval)
  • Require status checks to pass
  • Include administrators
  • Dismiss stale pull request approvals when new commits are pushed
  • Require conversation resolution before merging

Required Status Checks:

  • build-test - All tests must pass
  • lint-format - Code must be properly formatted
  • workflow-validation - CI/CD changes must be validated

3. CI/CD Workflow Triggers

on:
  workflow_dispatch: true
  push:
    branches:
      - main
      - 'ci/**'
      - 'feature/**'
      - 'fix/**'
      - 'refactor/**'
  pull_request:
    branches:
      - main
    types: [opened, synchronize, reopened, labeled]

4. Workflow Validation Job

A new workflow-validation job runs on:

  • All pull requests targeting main
  • Any push to ci/* branches

Validation Steps:

  1. YAML syntax validation
  2. Workflow structure validation
  3. Breaking change detection
  4. Required field verification

5. Merge Process for CI/CD Changes

# 1. Create dedicated CI branch
git checkout -b ci/update-workflow-v1

# 2. Make CI/CD changes
# (edit .gitea/workflows/ci-cd.yaml, scripts/cicd/, etc.)

# 3. Test locally first
./scripts/cicd.sh validate
./scripts/cicd.sh test-simple

# 4. Commit with clear message
git add .gitea/workflows/ci-cd.yaml scripts/cicd/
git commit -m "ci: update workflow with trunk protection"

# 5. Push and create PR
git push origin ci/update-workflow-v1
# Create Pull Request from ci/update-workflow-v1 to main

# 6. CI/CD pipeline automatically validates the workflow
# 7. Team reviews the changes
# 8. Merge after approval

Implementation

Workflow File Updates

.gitea/workflows/ci-cd.yaml:

  • Added workflow-validation job
  • Extended branch triggers to include ci/**, feature/**, fix/**, refactor/**
  • Added pull request triggers
  • Made version-check job depend on workflow-validation

Script Updates

scripts/cicd/validate-workflow.sh:

  • Enhanced to validate workflow changes in PR context
  • Added breaking change detection

Branch Protection Setup

Manual Gitea Configuration:

  1. Go to Repository Settings → Branches
  2. Add branch protection rule for main
  3. Enable required status checks
  4. Add workflow-validation to required checks

Consequences

Positive:

  • Main branch protected from CI/CD misconfigurations
  • All CI/CD changes go through validation and review
  • Automatic detection of workflow breaking changes
  • Clear rollback path (revert PR if issues arise)
  • Maintains trunk-based development principles
  • Encourages small, frequent CI/CD improvements

Negative:

  • Slightly more complex process for CI/CD changes
  • Requires discipline to use proper branch naming
  • Initial setup of branch protection rules

Future Enhancements

  1. Automatic Rollback: Add automatic rollback for failed CI/CD changes
  2. Canary Deployments: Test workflow changes on subset of runs first
  3. Workflow Diff Visualization: Show workflow changes in PR comments
  4. Breaking Change Detection: More sophisticated breaking change analysis
  5. Approver Assignment: Auto-assign CI/CD experts for workflow PRs

References

Implementation Observations

Gitea & GitHub Actions Compatibility Testing

Test Date: 2026-04-05 Test Method: act (GitHub Actions runner) with Gitea workflow syntax Result: FULL COMPATIBILITY CONFIRMED

Test Command

echo 'm' | act -n -W .gitea/workflows/ci-cd.yaml

Observations

  1. Syntax Compatibility:

    • Gitea workflow files work perfectly with GitHub Actions runner
    • All GitHub Actions syntax supported in Gitea
    • No syntax modifications needed
  2. Job Execution:

    • All jobs parsed correctly (build-test, lint-format, workflow-validation, version-check)
    • Job dependencies resolved properly
    • Conditional execution (if:) works as expected
  3. Action Compatibility:

    • actions/checkout@v4 - Working
    • actions/setup-go@v4 - Working
    • Standard GitHub actions work in Gitea context
  4. Local Testing Benefits:

    • No Gitea instance required for development
    • Instant feedback on workflow changes
    • Dry run mode prevents accidental executions
    • Container-based ensures clean environment
  5. Performance:

    • Fast execution (dry run completed in <1 second)
    • Minimal resource usage
    • Docker layer caching works efficiently

Sample Dry Run Output

*DRYRUN* [dance-lessons-coach CI/CD/Build and Test     ] ⭐ Run Set up job
*DRYRUN* [dance-lessons-coach CI/CD/Build and Test     ] 🚀  Start image=node:16-buster-slim
*DRYRUN* [dance-lessons-coach CI/CD/Build and Test     ]   ✅  Success - Set up job
*DRYRUN* [dance-lessons-coach CI/CD/Build and Test     ] ⭐ Run Main Checkout code
*DRYRUN* [dance-lessons-coach CI/CD/Build and Test     ]   ✅  Success - Main Checkout code [4.038875ms]
... (all steps succeeded)
*DRYRUN* [dance-lessons-coach CI/CD/Build and Test     ] 🏁  Job succeeded

1. Install act

# macOS (Homebrew)
brew install act

# Linux
curl https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash

2. Configure act

mkdir -p ~/Library/Application\ Support/act
cat > ~/Library/Application\ Support/act/actrc << 'EOF'
{
  "defaultImage": "medium:latest",
  "containerArchitecture": "linux/amd64"
}
EOF

3. Test Workflow Changes

# Dry run (no execution)
act -n -W .gitea/workflows/ci-cd.yaml

# Full test execution
act -W .gitea/workflows/ci-cd.yaml

# Test specific job
act -j build-test -W .gitea/workflows/ci-cd.yaml

4. Development Cycle

# 1. Create feature branch
git checkout -b ci/new-feature

# 2. Make workflow changes
# (edit .gitea/workflows/ci-cd.yaml)

# 3. Test locally
act -n -W .gitea/workflows/ci-cd.yaml

# 4. Commit and push
git add .gitea/workflows/ci-cd.yaml
git commit -m "ci: add new feature to workflow"
git push origin ci/new-feature

# 5. Create PR and let CI validate
# 6. Merge after approval

Benefits of This Approach

No Remote Dependencies - Test without Gitea instance Instant Feedback - Catch issues before pushing Reduced PR Churn - Fewer workflow patch iterations Better Developer Experience - Local testing = faster iteration Production Confidence - What works locally works in Gitea Team Efficiency - No more "wait and see" with remote CI

Future Enhancements

  1. CI/CD Test Script - Add act testing to our CI/CD scripts
  2. Pre-commit Hook - Automatically validate workflows before commit
  3. GitHub Actions Cache - Speed up local testing with caching
  4. Matrix Testing - Test across multiple runner versions
  5. Workflow Visualization - Generate diagrams from workflow files

Decision Record

Approved by: Arcodange Team Approved on: 2026-04-05 Implementation Owner: CI/CD Team Reviewers: Development Team Tested by: Local act dry run Compatibility: GitHub Actions ↔ Gitea Actions

Change Log:

  • 2026-04-05: Initial decision and implementation
  • 2026-04-05: Added workflow validation job
  • 2026-04-05: Updated branch protection rules
  • 2026-04-05: Confirmed Gitea/GitHub compatibility via act testing
  • 2026-04-05: Documented local development workflow