webgrip/workflows

Fork 0

[PR #2] [CLOSED] feat: implement modular gitflow workflows with component-based architecture and application examples #27

New issue

Closed

opened 2026-06-08 09:03:55 +00:00 by ryangr0 · 0 comments

ryangr0 commented

2026-06-08 09:03:55 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/webgrip/workflows/pull/2
Author: @Copilot
Created: 8/30/2025
Status: ❌ Closed

Base: main ← Head: copilot/fix-1

📝 Commits (5)

8b10215 Initial plan
0f667f4 feat: add gitflow-esque release workflow with keepachangelog support
60b1a76 fix: improve error handling and add comprehensive validation and migration docs
b946e33 feat: add example on_source_change.yml and on_release.yml for applications
2e7c2c3 refactor: separate development and release workflows with direct component calls

📊 Changes

9 files changed (+1244 additions, -1 deletions)

View changed files

📝 .github/composite-actions/semantic-release/action.yml (+25 -1)
➕ .github/workflows/gitflow-application.yml (+49 -0)
➕ .github/workflows/gitflow-release.yml (+297 -0)
➕ .releaserc.gitflow.json (+95 -0)
➕ docs/gitflow-workflow.md (+194 -0)
➕ docs/migration-guide.md (+183 -0)
➕ examples/README.md (+142 -0)
➕ examples/on_release.yml (+109 -0)
➕ examples/on_source_change.yml (+150 -0)

📄 Description

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:

Component-based approach: Copy examples/on_source_change.yml and examples/on_release.yml for maximum control
Unified approach: Use gitflow-application.yml for simplicity
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.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/webgrip/workflows/pull/2 **Author:** [@Copilot](https://github.com/apps/copilot-swe-agent) **Created:** 8/30/2025 **Status:** ❌ Closed **Base:** `main` ← **Head:** `copilot/fix-1` --- ### 📝 Commits (5) - [`8b10215`](https://github.com/webgrip/workflows/commit/8b102154a6fc351e41e1cb97f91d05a6bbad9cd3) Initial plan - [`0f667f4`](https://github.com/webgrip/workflows/commit/0f667f44d203983a959cc90a200b4686687ab2e5) feat: add gitflow-esque release workflow with keepachangelog support - [`60b1a76`](https://github.com/webgrip/workflows/commit/60b1a76f68c1fdbb681a042a904807bf160095b9) fix: improve error handling and add comprehensive validation and migration docs - [`b946e33`](https://github.com/webgrip/workflows/commit/b946e33ecbb8a4f2990f020a24fea96cc31f3894) feat: add example on_source_change.yml and on_release.yml for applications - [`2e7c2c3`](https://github.com/webgrip/workflows/commit/2e7c2c30b4a4004c931fc32b8d80aef99e547c90) refactor: separate development and release workflows with direct component calls ### 📊 Changes **9 files changed** (+1244 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `.github/composite-actions/semantic-release/action.yml` (+25 -1) ➕ `.github/workflows/gitflow-application.yml` (+49 -0) ➕ `.github/workflows/gitflow-release.yml` (+297 -0) ➕ `.releaserc.gitflow.json` (+95 -0) ➕ `docs/gitflow-workflow.md` (+194 -0) ➕ `docs/migration-guide.md` (+183 -0) ➕ `examples/README.md` (+142 -0) ➕ `examples/on_release.yml` (+109 -0) ➕ `examples/on_source_change.yml` (+150 -0) </details> ### 📄 Description 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: ```yaml # 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](https://github.com/webgrip/workflows/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

ryangr0

2026-06-08 09:03:55 +00:00

closed this issue
added the
pull-request
label

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

webgrip/workflows#27

No description provided.

Rows
Columns