pipeline ci-schedule

Home › Reference › Eac › Commands › Pipeline › Ci Schedule

Replaces wave-based dispatch with a pull-based scheduler that:

1. Filters modules (CI cache check, same as get ci-dispatch)
2. Builds dependency graph from repository config
3. Dispatches modules as capacity allows and deps are satisfied
4. Polls for completion, dispatches next ready modules
5. Exits 0 when all complete successfully, 1 on any failure

This command is the CI-level analog of the local DependencyScheduler.

It handles the full dispatch lifecycle: filter, dispatch, poll, report.

Example: pipeline ci schedule --directly-changed "core" --invalidated "eac docs" --head-sha abc123 --max-concurrent 6 pipeline ci schedule --directly-changed "core" --max-concurrent 20 --timeout 3600

Usage: pipeline ci schedule [flags]

---

Flag	Description
--directly-changed <string> (optional)	Space-separated list of directly changed modules
--invalidated <string> (optional)	Space-separated list of invalidated (dependent) modules
--head-sha <string> (optional)	Commit SHA to dispatch CI for
--dispatch-ref <string> (optional)	Git ref to dispatch workflows on (default: current branch)
--max-concurrent <int> (optional, default: 6)	Maximum number of concurrent CI dispatches
--timeout <int> (optional, default: 3600)	Maximum time in seconds to wait for all CI
--poll-interval <int> (optional, default: 10)	How often to check for completed workflows (seconds)
--trigger-run-id <string> (optional)	Run ID of the triggering workflow (for artifact download)
--mock <string> (optional)	Mock CI cache status (JSON format) for testing

Overview

pipeline ci schedule is a pull-based scheduler that orchestrates CI workflow dispatch with concurrency control and dependency awareness. It replaces wave-based dispatch with intelligent scheduling that:

1. Filters modules - Uses CI cache check (same as get ci-dispatch)
2. Builds dependency graph - Analyzes module dependencies from repository config
3. Dispatches intelligently - Dispatches modules as capacity allows and dependencies are satisfied
4. Monitors completion - Polls for workflow completion and dispatches next ready modules
5. Reports results - Exits 0 when all complete successfully, 1 on any failure

This is the CI-level analog of the local DependencyScheduler, handling the full dispatch lifecycle.

Output

Console Output

=== CI Schedule Results ===
  Completed: core auth api
  Failed: payment
  Cascade-skipped: order checkout
  Cached (not dispatched): docs website
  Total time: 15m 42s

Exit Codes

• 0 - All dispatched workflows completed successfully
• 1 - One or more workflows failed, or scheduling error occurred

GitHub Actions Summary

When running in GitHub Actions (GITHUB_STEP_SUMMARY set), writes a formatted summary:

## CI Scheduler Results

Dispatched **8** module(s) with concurrency-limited scheduling.

**Completed**: `core`, `auth`, `api`

**Failed**: `payment`

**Cascade-skipped**: `order`, `checkout`

**Cached** (valid CI at HEAD): `docs`, `website`

**Total time**: 15m 42s

Common Workflows

GitHub Actions Integration

name: CI Scheduler

on:
  push:
    branches: [main]

jobs:
  schedule:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Detect Changes
        id: changes
        run: |
          CHANGED=$(eac get changed-modules-ci | jq -r '.changed_modules | join(" ")')
          INVALIDATED=$(eac get changed-modules-ci | jq -r '.invalidated_modules | join(" ")')
          echo "changed=$CHANGED" >> $GITHUB_OUTPUT
          echo "invalidated=$INVALIDATED" >> $GITHUB_OUTPUT

      - name: Schedule CI
        run: |
          eac pipeline ci schedule \
            --directly-changed "${{ steps.changes.outputs.changed }}" \
            --invalidated "${{ steps.changes.outputs.invalidated }}" \
            --head-sha ${{ github.sha }} \
            --max-concurrent 10

Local Testing

# Test scheduling logic locally with mock cache
pipeline ci schedule \
  --directly-changed "core auth" \
  --invalidated "api" \
  --mock '{"core": {"has_ci": false}, "auth": {"has_ci": false}, "api": {"has_ci": true, "ci_passed": true}}' \
  --max-concurrent 2

Troubleshooting

No Modules Dispatched

Symptom: Scheduler completes immediately with no dispatches.

Causes:

• All modules have valid CI cache at HEAD SHA
• Module filtering excluded all candidates
• Empty --directly-changed and --invalidated lists

Solution: Check cache status with get ci-dispatch --head-sha <sha>

Workflows Not Starting

Symptom: Scheduler dispatches but workflows don't start.

Causes:

• GitHub API rate limiting
• Invalid workflow dispatch configuration
• Missing GitHub Actions workflows for modules

Solution: Check GitHub Actions logs and verify workflow files exist

Timeout Exceeded

Symptom: Scheduler exits with timeout error.

Causes:

• Workflows taking longer than --timeout value
• Stuck or hanging workflows
• Insufficient concurrent capacity

Solution:

# Increase timeout and concurrent capacity
pipeline ci schedule \
  --max-concurrent 15 \
  --timeout 7200 \
  ...

Cascade Failures

Symptom: Many modules marked as "cascade-skipped".

Causes:

• Early dependency failure cascading to dependents
• Build failures in foundational modules

Solution: Fix root cause failures in base modules first

See Also

• pipeline ci - Wave-based CI orchestration
• pipeline status - Check pipeline status
• pipeline wait - Wait for pipeline completion
• get ci-dispatch - Module filtering logic
• pipeline Commands - All pipeline commands

---

Tutorials | How-to Guides | Explanation | Reference

You are here: Reference — information-oriented technical descriptions of the system.