Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 17 additions & 10 deletions .github/copilot-instructions.md
Original file line number Diff line number Diff line change
Expand Up @@ -295,28 +295,35 @@ docker compose -f docker/docker-compose.chrome.yml up -d --scale github-runner-c

**CRITICAL**: Direct pushes to `main` and `develop` are blocked by branch protection rules.

### Post-Merge Back-Sync Workflow
### Merge Strategy

After merging a PR from `develop` to `main` with squash merge:
**This repository uses a DUAL merge strategy:**
- **Feature branches → `develop`**: **Squash merge** (one clean commit per feature)
- **`develop` → `main`**: **Regular merge** (preserves shared history, no back-sync needed)

**Why this approach?**
- Squash merging features into `develop` keeps one commit per feature/fix
- Regular merging `develop` → `main` preserves commit ancestry so no back-sync is needed
- No post-merge back-sync step eliminates an entire class of errors

**How to merge:**
```bash
# Sync develop with main to prevent "ahead" status
git checkout develop
git pull origin develop
git merge main -m "chore: sync develop with main after squash merge"
git push origin develop
# Feature branch → develop (SQUASH merge):
gh pr merge <PR_NUMBER> --squash --delete-branch --body "<brief summary>"

# This triggers CI/CD validation on develop branch
# Ensures develop stays in sync with main after squash merges
# develop → main (REGULAR merge — do NOT squash):
gh pr merge <PR_NUMBER> --merge --body "Promote develop to main"
```

**ℹ️ No back-sync needed!** Because `develop` → `main` uses a regular merge (not squash), both branches share the same commit history. There is no divergence after merging.

### Dependabot Automation (ZERO-TOUCH UPDATES)

The repository has fully automated dependency management:

**Auto-Merge Workflow** (`.github/workflows/dependabot-auto-merge.yml`):
- Automatically approves Dependabot PRs
- Enables auto-merge with squash strategy
- Enables auto-merge with squash strategy (Dependabot PRs target `develop`)
- Merges after all CI checks pass
- To disable for specific PR: `gh pr merge <PR_NUMBER> --disable-auto`

Expand Down
111 changes: 20 additions & 91 deletions .github/instructions/pull-request.instructions.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,16 +8,18 @@ description: 'Comprehensive pull request template and instructions for copilot-a

### 🔀 Merge Strategy

**This repository uses SQUASH MERGE as the standard merge strategy.**

**Why Squash Merge?**
- ✅ **Clean, linear commit history** on `main` branch - easier to understand project evolution
- ✅ **One commit per feature/fix** - easier rollbacks and cherry-picking
- ✅ **Better release notes** - automated changelog generation from squashed commits
- ✅ **Simplified CI/CD** - cleaner git history for automated release processes
- ✅ **Consistent with Dependabot** - auto-merge configuration uses squash strategy
- ✅ **Reduced noise** - no "fix typo" or "address review comments" commits in main
- ✅ **Easier bisecting** - each commit represents a complete, logical change
**This repository uses a DUAL merge strategy:**
- **Feature branches → `develop`**: **Squash merge** (one clean commit per feature)
- **`develop` → `main`**: **Regular merge** (preserves shared history, no back-sync needed)

**Why this approach?**
- ✅ **Clean integration branch** - squash merging features into `develop` keeps one commit per feature/fix
- ✅ **No back-sync required** - regular merging `develop` → `main` preserves commit ancestry
- ✅ **Easier rollbacks** - each squashed commit on `develop` represents a complete, logical change
- ✅ **Better release notes** - automated changelog generation from squashed commits on `develop`
- ✅ **Simplified workflow** - no post-merge back-sync step eliminates an entire class of errors
- ✅ **Reduced noise** - no "fix typo" or "address review comments" commits on `develop`
- ✅ **Consistent Dependabot** - auto-merge uses squash strategy for PRs targeting `develop`

**How to Create a PR (Recommended):**
```bash
Expand All @@ -33,18 +35,17 @@ gh pr create --base main --head develop --title "chore: promote develop to main"

**How to Merge (Recommended):**
```bash
# Via GitHub CLI (recommended - ensures squash merge):
gh pr merge <PR_NUMBER> --squash --delete-branch --body "Squash merge: <brief summary>"
# Feature branch → develop (SQUASH merge):
gh pr merge <PR_NUMBER> --squash --delete-branch --body "<brief summary>"

# develop → main (REGULAR merge — do NOT squash):
gh pr merge <PR_NUMBER> --merge --body "Promote develop to main"

# Via GitHub Web UI:
# 1. Click "Squash and merge" button (NOT "Merge pull request" or "Rebase and merge")
# 2. Edit the commit message if needed
# 3. Confirm the merge
# 4. Delete the branch
# Feature → develop: Click "Squash and merge"
# develop → main: Click "Merge pull request" (NOT squash)
```

**⚠️ CRITICAL: After squash merging to `main`, you MUST back-sync `develop`** (see Post-Merge Back-Sync section below).

### ⚠️ Pre-Submission Checklist

<!-- CRITICAL: Complete these steps BEFORE creating this PR -->
Expand Down Expand Up @@ -73,79 +74,7 @@ git checkout <your-feature-branch>
git rebase develop # or 'main' depending on your target branch
```

**Post-Merge Back-Sync (CRITICAL after squash merging to main):**

**⚠️ MANDATORY STEP - DO NOT SKIP THIS!**

**Why is this needed?**
When you squash merge a PR from `develop` to `main`, the individual commits from `develop` are condensed into a single commit on `main`. This causes `develop` to appear "ahead" of `main` in git history, even though the code is identical. The back-sync merge resolves this divergence and prevents:
- ❌ Incorrect "X commits ahead" status on `develop`
- ❌ Merge conflicts on subsequent PRs
- ❌ CI/CD pipeline confusion
- ❌ Duplicate commits in future merges

**When to perform back-sync:**
- ✅ **ALWAYS** after merging a promotion PR (`develop` → `main`) with squash merge
- ✅ **ALWAYS** after merging any PR directly to `main` with squash merge
- ✅ **IMMEDIATELY** after the squash merge completes (don't wait!)
- ❌ NOT needed when merging feature branches to `develop` (develop will be promoted later)

**How to perform back-sync:**
```bash
# Step 1: Ensure your local branches are up-to-date
git fetch --all

# Step 2: Switch to develop and pull latest
git checkout develop
git pull origin develop

# Step 3: Merge main back into develop (creates a merge commit)
git merge main -m "chore: sync develop with main after squash merge"

# Step 4: Push the back-sync to remote
git push origin develop

# This ensures develop stays in sync with main after squash merges
# The merge commit preserves the development history in develop
# while keeping main's linear squashed history
```

**Alternative (using GitHub CLI):**
```bash
# Create a back-sync PR (for teams requiring PR workflow)
git checkout develop
git pull origin develop
git checkout -b chore/backsync-main-to-develop
git merge main -m "chore: sync develop with main after squash merge"
git push origin chore/backsync-main-to-develop
gh pr create --base develop --head chore/backsync-main-to-develop \
--title "chore: back-sync main to develop after squash merge" \
--body "Automatic back-sync after squash merging to main. This prevents 'ahead' status."
gh pr merge --merge --delete-branch # Use regular merge, not squash!
```

**Verification:**
```bash
# After back-sync, these commands should show no differences:
git diff main..develop # Should be empty (no code differences)
git log --oneline main..develop # Should only show merge commits (no unique commits)

# Check branch status (should show "up to date"):
git checkout develop
git status
# Should NOT say "Your branch is ahead of 'origin/develop'"
```

**Troubleshooting:**
```bash
# If you forgot to back-sync and now have conflicts:
git checkout develop
git pull origin develop
git fetch origin main
git merge origin/main -m "chore: late back-sync after squash merge"
# Resolve any conflicts, then:
git push origin develop
```
**ℹ️ No back-sync needed!** Because `develop` → `main` uses a regular merge (not squash), both branches share the same commit history. There is no divergence after merging.

### Summary

Expand Down
111 changes: 20 additions & 91 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,16 +2,18 @@

### 🔀 Merge Strategy

**This repository uses SQUASH MERGE as the standard merge strategy.**

**Why Squash Merge?**
- ✅ **Clean, linear commit history** on `main` branch - easier to understand project evolution
- ✅ **One commit per feature/fix** - easier rollbacks and cherry-picking
- ✅ **Better release notes** - automated changelog generation from squashed commits
- ✅ **Simplified CI/CD** - cleaner git history for automated release processes
- ✅ **Consistent with Dependabot** - auto-merge configuration uses squash strategy
- ✅ **Reduced noise** - no "fix typo" or "address review comments" commits in main
- ✅ **Easier bisecting** - each commit represents a complete, logical change
**This repository uses a DUAL merge strategy:**
- **Feature branches → `develop`**: **Squash merge** (one clean commit per feature)
- **`develop` → `main`**: **Regular merge** (preserves shared history, no back-sync needed)

**Why this approach?**
- ✅ **Clean integration branch** - squash merging features into `develop` keeps one commit per feature/fix
- ✅ **No back-sync required** - regular merging `develop` → `main` preserves commit ancestry
- ✅ **Easier rollbacks** - each squashed commit on `develop` represents a complete, logical change
- ✅ **Better release notes** - automated changelog generation from squashed commits on `develop`
- ✅ **Simplified workflow** - no post-merge back-sync step eliminates an entire class of errors
- ✅ **Reduced noise** - no "fix typo" or "address review comments" commits on `develop`
- ✅ **Consistent Dependabot** - auto-merge uses squash strategy for PRs targeting `develop`

**How to Create a PR (Recommended):**
```bash
Expand All @@ -27,18 +29,17 @@ gh pr create --base main --head develop --title "chore: promote develop to main"

**How to Merge (Recommended):**
```bash
# Via GitHub CLI (recommended - ensures squash merge):
gh pr merge <PR_NUMBER> --squash --delete-branch --body "Squash merge: <brief summary>"
# Feature branch → develop (SQUASH merge):
gh pr merge <PR_NUMBER> --squash --delete-branch --body "<brief summary>"

# develop → main (REGULAR merge — do NOT squash):
gh pr merge <PR_NUMBER> --merge --body "Promote develop to main"

# Via GitHub Web UI:
# 1. Click "Squash and merge" button (NOT "Merge pull request" or "Rebase and merge")
# 2. Edit the commit message if needed
# 3. Confirm the merge
# 4. Delete the branch
# Feature → develop: Click "Squash and merge"
# develop → main: Click "Merge pull request" (NOT squash)
```

**⚠️ CRITICAL: After squash merging to `main`, you MUST back-sync `develop`** (see Post-Merge Back-Sync section below).

### ⚠️ Pre-Submission Checklist

<!-- CRITICAL: Complete these steps BEFORE creating this PR -->
Expand Down Expand Up @@ -67,79 +68,7 @@ git checkout <your-feature-branch>
git rebase develop # or 'main' depending on your target branch
```

**Post-Merge Back-Sync (CRITICAL after squash merging to main):**

**⚠️ MANDATORY STEP - DO NOT SKIP THIS!**

**Why is this needed?**
When you squash merge a PR from `develop` to `main`, the individual commits from `develop` are condensed into a single commit on `main`. This causes `develop` to appear "ahead" of `main` in git history, even though the code is identical. The back-sync merge resolves this divergence and prevents:
- ❌ Incorrect "X commits ahead" status on `develop`
- ❌ Merge conflicts on subsequent PRs
- ❌ CI/CD pipeline confusion
- ❌ Duplicate commits in future merges

**When to perform back-sync:**
- ✅ **ALWAYS** after merging a promotion PR (`develop` → `main`) with squash merge
- ✅ **ALWAYS** after merging any PR directly to `main` with squash merge
- ✅ **IMMEDIATELY** after the squash merge completes (don't wait!)
- ❌ NOT needed when merging feature branches to `develop` (develop will be promoted later)

**How to perform back-sync:**
```bash
# Step 1: Ensure your local branches are up-to-date
git fetch --all

# Step 2: Switch to develop and pull latest
git checkout develop
git pull origin develop

# Step 3: Merge main back into develop (creates a merge commit)
git merge main -m "chore: sync develop with main after squash merge"

# Step 4: Push the back-sync to remote
git push origin develop

# This ensures develop stays in sync with main after squash merges
# The merge commit preserves the development history in develop
# while keeping main's linear squashed history
```

**Alternative (using GitHub CLI):**
```bash
# Create a back-sync PR (for teams requiring PR workflow)
git checkout develop
git pull origin develop
git checkout -b chore/backsync-main-to-develop
git merge main -m "chore: sync develop with main after squash merge"
git push origin chore/backsync-main-to-develop
gh pr create --base develop --head chore/backsync-main-to-develop \
--title "chore: back-sync main to develop after squash merge" \
--body "Automatic back-sync after squash merging to main. This prevents 'ahead' status."
gh pr merge --merge --delete-branch # Use regular merge, not squash!
```

**Verification:**
```bash
# After back-sync, these commands should show no differences:
git diff main..develop # Should be empty (no code differences)
git log --oneline main..develop # Should only show merge commits (no unique commits)

# Check branch status (should show "up to date"):
git checkout develop
git status
# Should NOT say "Your branch is ahead of 'origin/develop'"
```

**Troubleshooting:**
```bash
# If you forgot to back-sync and now have conflicts:
git checkout develop
git pull origin develop
git fetch origin main
git merge origin/main -m "chore: late back-sync after squash merge"
# Resolve any conflicts, then:
git push origin develop
```
**ℹ️ No back-sync needed!** Because `develop` → `main` uses a regular merge (not squash), both branches share the same commit history. There is no divergence after merging.

### Summary

Expand Down
2 changes: 1 addition & 1 deletion .github/workflows/dependabot-auto-merge.yml
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ jobs:

- name: Enable auto-merge
run: |
# Enable auto-merge with squash merge strategy
# Enable auto-merge with squash strategy (Dependabot PRs target develop)
gh pr merge "${{ github.event.pull_request.number }}" \
--auto --squash \
--subject "chore(deps): ${{ github.event.pull_request.title }}" \
Expand Down
32 changes: 24 additions & 8 deletions .github/workflows/seed-trivy-sarif.yml
Original file line number Diff line number Diff line change
Expand Up @@ -12,8 +12,8 @@
#
# Triggers:
# - Manual: workflow_dispatch with scan type selection
# - Automatic: Push to main branch (production deployments)
# - Scheduled: Weekly on Monday 2 AM UTC
# - Automatic: After CI/CD Pipeline completes on main (workflow_run)
# - Scheduled: Weekly on Monday 4 AM UTC
#
# Fixes Applied:
# - PR #1048: Removed multi-platform build incompatibility with docker exporter
Expand All @@ -38,8 +38,10 @@ on:
- all
- filesystem
- container
push:
branches: [main] # Only on production deployments
workflow_run:
workflows: ["CI/CD Pipeline"] # Run after CI/CD completes on main — avoids duplicate Trivy scans
types: [completed]
branches: [main]
schedule:
- cron: '0 4 * * 1' # Weekly deep scan on Monday 4 AM UTC (staggered from maintenance at 2AM, advisories at 3AM)

Expand All @@ -48,11 +50,20 @@ permissions:
security-events: write
packages: write

concurrency:
group: trivy-baseline-${{ github.ref }}
cancel-in-progress: true

jobs:
seed-filesystem-baseline:
name: Seed Trivy filesystem SARIF baseline
runs-on: ubuntu-latest
if: github.event.inputs.scan_type == 'filesystem' || github.event.inputs.scan_type == 'all' || github.event_name == 'push' || github.event_name == 'schedule'
# Run on: dispatch (filesystem/all), schedule, or successful CI/CD completion on main
if: |
github.event.inputs.scan_type == 'filesystem' ||
github.event.inputs.scan_type == 'all' ||
github.event_name == 'schedule' ||
(github.event_name == 'workflow_run' && github.event.workflow_run.conclusion == 'success')
steps:
- name: Checkout code
uses: actions/checkout@v6
Expand Down Expand Up @@ -91,7 +102,12 @@ jobs:
seed-container-baseline:
name: Seed Trivy container SARIF baseline
runs-on: ubuntu-latest
if: github.event.inputs.scan_type == 'container' || github.event.inputs.scan_type == 'all' || github.event_name == 'push' || github.event_name == 'schedule'
# Run on: dispatch (container/all), schedule, or successful CI/CD completion on main
if: |
github.event.inputs.scan_type == 'container' ||
github.event.inputs.scan_type == 'all' ||
github.event_name == 'schedule' ||
(github.event_name == 'workflow_run' && github.event.workflow_run.conclusion == 'success')
strategy:
matrix:
variant: [standard, chrome, chrome-go]
Expand Down Expand Up @@ -177,8 +193,8 @@ jobs:
echo "- \`container-scan-chrome-go\` - Chrome-Go runner container vulnerabilities" >> $GITHUB_STEP_SUMMARY
echo "" >> $GITHUB_STEP_SUMMARY
echo "### Schedule:" >> $GITHUB_STEP_SUMMARY
echo "- 📅 Weekly automated scan: Monday 2 AM UTC" >> $GITHUB_STEP_SUMMARY
echo "- 🚀 Automatic on production deployments (main branch)" >> $GITHUB_STEP_SUMMARY
echo "- 📅 Weekly automated scan: Monday 4 AM UTC" >> $GITHUB_STEP_SUMMARY
echo "- 🚀 Automatic after CI/CD Pipeline succeeds on main (workflow_run)" >> $GITHUB_STEP_SUMMARY
echo "- 🔧 Manual trigger available via workflow_dispatch" >> $GITHUB_STEP_SUMMARY
echo "" >> $GITHUB_STEP_SUMMARY
echo "View results in the [Security tab](https://github.com/${{ github.repository }}/security/code-scanning)" >> $GITHUB_STEP_SUMMARY
Loading