Standardize GitHub Actions Workflows

Standardize all GitHub Actions workflow files across our repositories:

1. Update all action versions to current pinned versions:
   - actions/checkout → actions/checkout@v4
   - actions/setup-node → actions/setup-node@v4
   - actions/setup-python → actions/setup-python@v5
   - actions/cache → actions/cache@v4
   - actions/upload-artifact → actions/upload-artifact@v4
   - actions/download-artifact → actions/download-artifact@v4
2. Add timeout-minutes: 30 to every job that doesn't have a timeout set
3. Add concurrency group to prevent duplicate runs on the same branch:
   concurrency:
     group: ${{ github.workflow }}-${{ github.ref }}
     cancel-in-progress: true
4. Ensure every workflow has a descriptive name: field

Do not change build commands, test scripts, or deployment logic.

The Problem

When every team writes their own GitHub Actions workflows, they diverge. One team pins `actions/checkout@v3`, another uses `@v4`, a third uses `@main`. Some workflows have timeouts, most don't. Caching is implemented differently everywhere, or not at all. Naming conventions are inconsistent, making it hard to search or report on CI status across the organization.

This drift creates real problems: inconsistent build times, unexpected failures when unpinned actions release breaking changes, and difficulty enforcing organizational policies. Fixing it means touching every workflow file in every repo.

What Tidra Does

1. Scans all .github/workflows/*.yml files in each repository
2. Identifies outdated action version references and updates them to the specified pinned versions
3. Adds missing timeout-minutes and concurrency configuration to jobs
4. Ensures every workflow has a name: field, generating one from the filename if missing
5. Creates a PR with changes and a description summarizing what was standardized

Before & After

Customization Tips

• Custom actions: Add your organization's internal actions to the version pinning list in the prompt.
• Timeout values: Adjust timeout-minutes based on your build complexity, 30 minutes is a safe default, but long-running integration test suites may need more.
• Concurrency scope: The default concurrency group (workflow-ref) works for most cases. For monorepos, you may want path-based concurrency groups.