Optimizing GitHub Actions: Streamlining Your Software Development Plan with Composite Actions

Unpacking Slow GitHub Actions Setup with Composite Actions

In the world of continuous integration and delivery, every second counts. A recent GitHub Community discussion highlighted a significant pain point for developers using GitHub Actions: unexpectedly slow 'Setup Job' times when leveraging the new self-repository syntax ($/) for composite actions, particularly within large monorepos. This can seriously impede an efficient software development plan.

The original post by tstellar described how switching to the $/ syntax for composite actions led to 'Setup Job' steps taking several minutes to complete. An example from the llvm/llvm-project repository showed a setup job consuming almost three minutes, with the vast majority of that time attributed to Download action repository 'llvm/llvm-project@b10b3f59…'. This isn't just a minor delay; it's a bottleneck that can significantly impact developer productivity and the overall velocity of a project.

The Root Cause: Monorepo Downloads

As clarified by community member tomm1990, the issue isn't 'mysterious slowness' but a direct consequence of how GitHub Actions resolves the $/ syntax. When you reference a composite action using $/path/to/action, the runner interprets this as needing to download the entire monorepo as an action package before any explicit checkout steps are executed. For repositories like llvm-project, which are massive, this means pulling gigabytes of data just to access a small composite action. Crucially, any sparse-checkout configurations defined inside the composite action itself cannot mitigate this initial, full repository download.

Key Questions and Potential Workarounds

tomm1990 posed critical questions that point towards potential solutions and the core requirements of users:

• Is the composite action needed before any repository checkout occurs in the main job?
• Have users tested a scenario where actions/checkout with sparse paths is performed before calling the composite action?
• Is the primary ask a product enhancement (e.g., for $/ to intelligently fetch only the necessary action paths) or an immediate workaround?

Based on this discussion, here's a potential workaround to avoid the full monorepo download:

Strategy: Pre-Composite Sparse Checkout

Instead of relying on $/ to implicitly download the entire repository, you can explicitly checkout only the necessary paths for your composite action using actions/checkout with sparse-checkout-paths. This should be done before you call your composite action, and then you would reference the composite action using its relative path (./.github/workflows/my-composite-action).

jobs:   build:     runs-on: ubuntu-latest     steps:       - name: Checkout only the action path         uses: actions/checkout@v4         with:           sparse-checkout-paths: |             .github/workflows/my-composite-action # Adjust to your action's path       - name: Use the composite action         uses: ./.github/workflows/my-composite-action # Reference locally         with:           # ... your action inputs 

This approach ensures that only the relevant parts of your repository are fetched, drastically reducing the 'Setup Job' time and making your software development plan more efficient. While this requires a slight adjustment to your workflow, it offers an immediate performance improvement.

Looking Ahead: Product Enhancements

Ultimately, the community's feedback points to a need for GitHub to optimize how $/ handles large monorepos. An ideal solution would involve the platform intelligently fetching only the required action paths without needing to download the entire tree. Such an enhancement would further streamline CI/CD pipelines and contribute significantly to a more robust and responsive software development plan for monorepo users.

This discussion underscores the importance of community feedback in shaping the future of developer tools. By identifying and addressing these performance bottlenecks, we can collectively work towards a more seamless and productive GitHub experience.