|
1 | | -# workflow-order |
| 1 | +# Workflow Order Example Project |
| 2 | + |
| 3 | +This project demonstrates a GitHub Actions workflow structure with two child workflows and one parent workflow, where the parent workflow executes after both child workflows complete. |
| 4 | + |
| 5 | +## Project Structure |
| 6 | + |
| 7 | +``` |
| 8 | +.github/workflows/ |
| 9 | +├── child-workflow-1.yml # Child Workflow 1 - Tests |
| 10 | +├── child-workflow-2.yml # Child Workflow 2 - Build & Security |
| 11 | +└── parent-workflow.yml # Parent Workflow - Comprehensive CI/CD |
| 12 | +``` |
| 13 | + |
| 14 | +## Workflow Architecture |
| 15 | + |
| 16 | +### Child Workflows |
| 17 | + |
| 18 | +#### 1. Child Workflow 1 - Tests (`child-workflow-1.yml`) |
| 19 | +- **Purpose**: Runs unit tests and generates test reports |
| 20 | +- **Jobs**: |
| 21 | + - `run-tests`: Sets up Node.js, installs dependencies, runs tests |
| 22 | +- **Artifacts**: Uploads test results to `test-results-child1` |
| 23 | +- **Triggers**: Can be called by other workflows or triggered on push/PR |
| 24 | + |
| 25 | +#### 2. Child Workflow 2 - Build & Security (`child-workflow-2.yml`) |
| 26 | +- **Purpose**: Builds the application and performs security scans |
| 27 | +- **Jobs**: |
| 28 | + - `build`: Builds the application and creates build artifacts |
| 29 | + - `security-scan`: Runs security vulnerability scanning |
| 30 | +- **Artifacts**: |
| 31 | + - Uploads build artifacts to `build-artifacts-child2` |
| 32 | + - Uploads security results to `security-results-child2` |
| 33 | +- **Triggers**: Can be called by other workflows or triggered on push/PR |
| 34 | + |
| 35 | +### Parent Workflow |
| 36 | + |
| 37 | +#### Parent Workflow - Comprehensive CI/CD (`parent-workflow.yml`) |
| 38 | +- **Purpose**: Orchestrates the entire CI/CD pipeline |
| 39 | +- **Execution Order**: |
| 40 | + 1. **Parallel Execution**: Runs both child workflows simultaneously |
| 41 | + - `run-tests` (calls child-workflow-1.yml) |
| 42 | + - `run-build-security` (calls child-workflow-2.yml) |
| 43 | + 2. **Sequential Execution**: After both children complete |
| 44 | + - `collect-and-deploy`: Collects results and performs deployment |
| 45 | + |
| 46 | +## Workflow Execution Flow |
| 47 | + |
| 48 | +```mermaid |
| 49 | +graph TD |
| 50 | + A[Parent Workflow Triggered] --> B[Child Workflow 1: Tests] |
| 51 | + A --> C[Child Workflow 2: Build & Security] |
| 52 | + B --> D[Parent: Collect Results & Deploy] |
| 53 | + C --> D |
| 54 | + D --> E[Deployment Complete] |
| 55 | +``` |
| 56 | + |
| 57 | +## Key Features |
| 58 | + |
| 59 | +### 1. **Parallel Child Execution** |
| 60 | +- Both child workflows run simultaneously for efficiency |
| 61 | +- Each child workflow is independent and can be reused |
| 62 | + |
| 63 | +### 2. **Dependency Management** |
| 64 | +- Parent workflow waits for both children using `needs: [run-tests, run-build-security]` |
| 65 | +- Uses `if: always()` to run collection job even if children fail |
| 66 | + |
| 67 | +### 3. **Artifact Aggregation** |
| 68 | +- Parent workflow downloads all artifacts from child workflows |
| 69 | +- Combines and processes results from multiple sources |
| 70 | +- Creates a final deployment package |
| 71 | + |
| 72 | +### 4. **Error Handling** |
| 73 | +- Checks the result status of each child workflow |
| 74 | +- Fails the parent workflow if any required child fails |
| 75 | +- Provides clear status reporting |
| 76 | + |
| 77 | +## Usage |
| 78 | + |
| 79 | +### Triggering the Workflows |
| 80 | + |
| 81 | +The parent workflow (`parent-workflow.yml`) is the main entry point and will automatically trigger both child workflows when: |
| 82 | +- Code is pushed to `main` or `develop` branches |
| 83 | +- A pull request is opened against `main` or `develop` branches |
| 84 | + |
| 85 | +### Individual Child Workflow Testing |
| 86 | + |
| 87 | +Each child workflow can also be triggered independently for testing: |
| 88 | +- Push changes to trigger individual workflows |
| 89 | +- Manually trigger workflows from the GitHub Actions tab |
| 90 | + |
| 91 | +## Customization |
| 92 | + |
| 93 | +### Adding More Child Workflows |
| 94 | +1. Create a new workflow file in `.github/workflows/` |
| 95 | +2. Add `workflow_call` trigger for reusability |
| 96 | +3. Update the parent workflow to include the new child in the `needs` array |
| 97 | + |
| 98 | +### Modifying Execution Order |
| 99 | +- To run children sequentially: Add `needs` dependencies between child workflows |
| 100 | +- To add more parent jobs: Create additional jobs with appropriate `needs` dependencies |
| 101 | + |
| 102 | +## Benefits of This Architecture |
| 103 | + |
| 104 | +1. **Modularity**: Each workflow has a specific purpose and can be maintained independently |
| 105 | +2. **Reusability**: Child workflows can be called by multiple parent workflows |
| 106 | +3. **Parallel Execution**: Improves overall pipeline performance |
| 107 | +4. **Clear Dependencies**: Easy to understand execution order and dependencies |
| 108 | +5. **Artifact Management**: Centralized collection and processing of build artifacts |
| 109 | +6. **Error Handling**: Robust error checking and reporting |
| 110 | + |
| 111 | +## Example Scenarios |
| 112 | + |
| 113 | +This pattern is useful for: |
| 114 | +- **Complex CI/CD Pipelines**: Where different teams manage different parts |
| 115 | +- **Multi-Environment Deployments**: Running tests in parallel before deployment |
| 116 | +- **Compliance Requirements**: Separate security and quality checks |
| 117 | +- **Large Monorepos**: Different workflows for different components |
0 commit comments