feat: implement modular gitflow workflows with component-based architecture and application examples

[Copilot]

This PR implements a comprehensive gitflow-style development workflow that provides both monolithic and modular approaches for better branch management and automated release processes.

Key Features

Modular Component Architecture: The implementation now offers two distinct approaches:

• Monolithic workflow: gitflow-release.yml provides a single comprehensive workflow for teams preferring unified execution
• Component-based workflows: Individual workflow components (static-analysis.yml, tests.yml, semantic-release.yml, etc.) can be called directly for maximum flexibility

Application-Ready Examples: The examples/ directory contains production-ready workflow templates:

• on_source_change.yml: Focused development workflow that calls static analysis and testing components directly, with automatic release PR creation
• on_release.yml: Dedicated release workflow that orchestrates semantic versioning, Docker builds, and Helm deployments using individual components

Clean Separation of Concerns:

• Development workflows (on_source_change.yml) handle validation, testing, and release PR automation
• Release workflows (on_release.yml) handle versioning, building, and deployment
• No cross-dependency between development and release processes

Direct Component Integration: Applications can now choose their preferred approach:

# Option 1: Use individual components directly
jobs:
  static-analysis:
    uses: webgrip/workflows/.github/workflows/static-analysis.yml@main
  tests:
    uses: webgrip/workflows/.github/workflows/tests.yml@main
  semantic-release:
    uses: webgrip/workflows/.github/workflows/semantic-release.yml@main

# Option 2: Use the unified workflow
jobs:
  gitflow:
    uses: webgrip/workflows/.github/workflows/gitflow-release.yml@main

Architecture Benefits

• Transparency: Clear visibility into which specific components are executing
• Modularity: Teams can mix and match components based on their needs
• Debugging: Easier to isolate and fix issues in specific workflow stages
• Customization: Simple to replace individual components with custom implementations
• Scalability: Development and release processes can evolve independently

Migration Path

Applications can choose between:

1. Component-based approach: Copy examples/on_source_change.yml and examples/on_release.yml for maximum control
2. Unified approach: Use gitflow-application.yml for simplicity
3. Hybrid approach: Mix direct component calls with unified workflows as needed

The implementation maintains backward compatibility while providing a clear path toward more modular, maintainable CI/CD architecture.

Fixes #1.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Ryangr0]

@copilot Please make an example on_source_change.yml and on_release.yml, that will live in the application repo. Those will call the workflows inside webgrip/workflows (this repo)

[Copilot]

@copilot Please make an example on_source_change.yml and on_release.yml, that will live in the application repo. Those will call the workflows inside webgrip/workflows (this repo)

I've created the example workflow files you requested! You can find them in the examples/ directory:

• examples/on_source_change.yml - Handles development activities (static analysis, testing, release PR creation)
• examples/on_release.yml - Handles release activities (semantic versioning, building, deployment)

Both files call the webgrip/workflows/.github/workflows/gitflow-release.yml workflow with appropriate configurations. The examples/README.md provides detailed usage instructions and migration guidance.

Applications can copy these files directly to their .github/workflows/ directory for a clean separation between development and release processes.

Commit: b946e33

[Ryangr0]

@copilot webgrip/workflows/.github/workflows/gitflow-release.yml@main should not be used in on_source_change.yml. Split up the tests and the static analysis, and use the semantic release and deploy from helm directly in the on_release.yml. Make things make sense. Look over everything and give good direction.

[Copilot]

@copilot webgrip/workflows/.github/workflows/gitflow-release.yml@main should not be used in on_source_change.yml. Split up the tests and the static analysis, and use the semantic release and deploy fr...

I've completely restructured the example workflows to address your feedback:

Changes Made:

• on_source_change.yml now calls individual workflows directly:

  • webgrip/workflows/.github/workflows/static-analysis.yml
  • webgrip/workflows/.github/workflows/tests.yml
  • Custom release PR creation logic for development branches

• on_release.yml now calls individual workflows directly:

  • webgrip/workflows/.github/workflows/semantic-release.yml
  • webgrip/workflows/.github/workflows/docker-build-and-push.yml
  • webgrip/workflows/.github/workflows/helm-chart-deploy.yml
  • webgrip/workflows/.github/workflows/helm-charts-deploy.yml for secrets

Key Benefits:

• Clean separation of development vs release concerns
• No dependency on the monolithic gitflow-release.yml
• Direct workflow component calls for better transparency
• Focused job execution and clearer error diagnosis

Both workflows are now self-contained and call the appropriate underlying workflows directly, making the architecture much more modular and understandable.

Commit: 2e7c2c3