ci: refactor the workflows to unblock faster runners

[sandydoo]

No description provided.

[github-actions]

🔍 Suggested Reviewers

Based on git blame analysis of the changed lines, the following contributors have significant experience with the modified code:

• @domenkozar - 100.0% of changed lines (1 lines)

Please consider reviewing this PR as you have authored significant portions of the code being modified. Your expertise would be valuable! 🙏

This comment was automatically generated by git-blame-auto-reviewer

Last updated: 2025-09-25T01:09:24.279Z

[claude]

Claude finished @sandydoo's task —— View job

---

PR Review: CI Workflow Refactoring

I've completed my analysis of the GitHub Actions workflow refactoring. Here's my detailed feedback focusing on areas for improvement:

Todo List:

• Read and understand the current workflow structure
• Analyze each modified/added workflow file
• Check for security concerns in workflow configurations
• Identify performance optimization opportunities
• Look for potential bugs or configuration issues
• Provide constructive feedback and recommendations

Key Issues and Recommendations

1. Complex Matrix Logic Duplication

The system matrix selection logic is duplicated across all workflow files (build.yml:20-34, examples.yml:38-52, test.yml:20-34). This creates several problems:

# Repeated in build.yml, examples.yml, test.yml, pr-test.yml
systems: >-
  ${{
    inputs.system && fromJSON(format('[{0}]',
      inputs.system == 'aarch64-linux' && '{"system": "aarch64-linux", "runs-on": ["self-hosted", "linux", "ARM64"]}' ||
      # ... more conditions
    )) || fromJSON('[...full matrix...]')
  }}

Issues:

• Maintenance burden: Changes to runner configurations require updates in 4+ files
• Error-prone: Easy to introduce inconsistencies between workflows
• Hard to read: Complex nested conditional expressions are difficult to understand

Recommendation: Create a composite action or move this logic to a central location. Consider:

# .github/actions/get-matrix/action.yml
name: 'Get System Matrix'
inputs:
  system:
    description: 'Optional system filter'
    required: false
outputs:
  matrix:
    description: 'System matrix JSON'
    value: ${{ steps.matrix.outputs.result }}
runs:
  using: 'composite'
  steps:
    - id: matrix
      # Centralized logic here

2. Inconsistent Spacing in YAML

There are inconsistent spacing patterns in the ref parameter usage in release.yml:

# Line 35: Missing space
ref: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.ref || ''}}
# Line 51: Proper spacing  
ref: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.ref || '' }}

Recommendation: Use consistent spacing throughout. Consider adding a YAML linter to your CI.

3. Per-System Job Chain Complexity

The new approach in pr-test.yml and release.yml creates individual job chains per system:

build-aarch64-linux -> test-aarch64-linux -> examples-aarch64-linux
build-x86_64-linux -> test-x86_64-linux -> examples-x86_64-linux
# etc...

Potential Issues:

• Job limit concerns: GitHub has limits on concurrent jobs (20 for free accounts, 180 for paid)
• Resource contention: Self-hosted runners might become bottlenecks
• Debugging complexity: More jobs mean more places for failures

Recommendations:

• Monitor actual runner availability and job queue times
• Consider adding timeout limits to prevent hanging jobs from blocking runners
• Add job-level timeouts:

jobs:
  build-aarch64-linux:
    timeout-minutes: 30  # Add appropriate timeouts

4. Missing Error Handling for External Dependencies

In examples.yml:29, there's shell command that could fail:

json=$(nix shell nixpkgs#tree -c tree -J -L 1 examples | nix shell nixpkgs#jq -c jq -c '[.[0].contents[] | .name]')

Issues:

• No validation if the examples directory exists
• Pipeline could fail silently if tree or jq commands fail
• Complex shell pipeline is hard to debug

Recommendation: Add error checking and break down the command:

- name: Fetch examples to run
  id: set-examples
  run: |
    set -euxo pipefail
    if [[ ! -d examples ]]; then
      echo "examples=[]" >> $GITHUB_OUTPUT
      exit 0
    fi
    tree_output=$(nix shell nixpkgs#tree -c tree -J -L 1 examples)
    json=$(echo "$tree_output" | nix shell nixpkgs#jq -c jq -c '[.[0].contents[] | .name]')
    echo "examples=$json" >> $GITHUB_OUTPUT

5. Resource Optimization Opportunities

Current approach: Examples always run with if: always() even when tests fail.

Recommendation: Consider using if: success() || failure() to skip examples when tests are cancelled, but still run them when tests fail (which might be intentional for debugging).

6. Security Considerations

Token usage: GITHUB_TOKEN is properly scoped and CACHIX_AUTH_TOKEN is correctly referenced as a secret.

Minor improvement: In examples.yml:68 there's inconsistent quoting:

authToken: "${{ secrets.CACHIX_AUTH_TOKEN }}"  # Quoted
# vs elsewhere:
authToken: ${{ secrets.CACHIX_AUTH_TOKEN }}    # Unquoted

Both work, but consistency would be better.

7. Performance Analysis

Positive changes:

• Per-system chains eliminate cross-system waiting
• Examples run in parallel with other systems after their tests complete
• Build artifacts are properly cached via Cachix

Potential concerns:

• More concurrent jobs may strain self-hosted runners
• The complex matrix logic adds YAML parsing overhead (minimal impact)

Overall Assessment

The refactoring achieves its goal of unblocking faster runners through better parallelization. The architectural changes are sound, but the implementation could be more maintainable and robust.

Priority improvements:

1. High: Centralize the matrix selection logic
2. Medium: Add job timeouts and better error handling
3. Low: Fix spacing inconsistencies and improve documentation

[cloudflare-workers-and-pages]

Deploying devenv with    Cloudflare Pages

Latest commit:	24ad0ce
Status:	✅  Deploy successful!
Preview URL:	https://a5148779.devenv.pages.dev
Branch Preview URL:	https://ci-faster.devenv.pages.dev

View logs