ci: speed up build

[janishorsts]

🛠️ Benefits, Issues Resolved & DX Impact

• Benefits: Consolidated EarthBuild binary and container image builds into a single upfront job (fast-check-and-build), preventing redundant build steps across matrix jobs in CI.
• Issues Eliminated: Eliminated duplicate compilation in downstream test matrixes (ci-docker-ubuntu, ci-podman-ubuntu, and ci-earthly-next-docker-ubuntu).
• Developer Experience (DX) Impact: Dramatically reduced total CI pipeline execution time, faster PR feedback loops, and added repository naming standards to AGENTS.md clarifying earth and EarthBuild usage.

WARNING: This PR requires the change to "Protect default branch" ruleset.

NOTE: This PR preserves the existing workflow behaviour across all frontends. The goal is not to investigate why specific jobs run for frontend X and not frontend Y.

⚡ Performance Impact

Total time:

• Before: ~24 minutes (3 parallel pipelines compiling standard and next Earth binaries independently, taking ~8 minutes each).
• After: ~11 minutes (1 consolidated compilation phase with shared caching).

Reduces total execution time by 13 minutes.

Before

graph TD
    A[Code Commit / PR] --> B[Fast Check: Lint, Unit, Fuzz]
    B --> C[Docker Pipeline]
    B --> D[Podman Pipeline]
    B --> E[Next Pipeline]
    
    subgraph Docker Pipeline
        C --> C_Build["Build Earth (Docker tag) [~8 min]"]
        C_Build --> C_Tests["Run Docker Test Matrix"]
    end
    subgraph Podman Pipeline
        D --> D_Build["Build Earth (Podman tag) [~8 min]"]
        D_Build --> D_Tests["Run Podman Test Matrix"]
    end
    subgraph Next Pipeline
        E --> E_Build["Build Earth (Next tag) [~8 min]"]
        E_Build --> E_Tests["Run Next Test Matrix"]
    end

Loading

After

graph TD
    A[Code Commit / PR] --> B[Fast Check & Build: Lint, Unit, Fuzz, Compile]
    
    subgraph Fast Check & Build Runner
        B --> B_BuildStd["Build Standard Earth"]
        B --> B_BuildNext["Build Next Earth"]
    end
    B_BuildStd --> C[Docker Pipeline]
    B_BuildStd --> D[Podman Pipeline]
    B_BuildNext --> E[Next Pipeline]
    subgraph Docker Pipeline Runner
        C --> C_Tests["Run Docker Test Matrix"]
    end
    subgraph Podman Pipeline Runner
        D --> D_Tests["Run Podman Test Matrix"]
    end
    subgraph Next Pipeline Runner
        E --> E_Tests["Run Next Test Matrix"]
    end

Loading

[github-actions]

🎉 Are we earthbuild yet?

Great progress! You've reduced "earthly" occurrences by 250 (5.27%)

📈 Overall Progress

Branch	Total Count
main	4748
This PR	4498
Difference	-250 (5.27%)

📁 Changes by file type:

File Type	Change
Go files (.go)	➖ No change
Documentation (.md)	❌ +1
Earthfiles	➖ No change

---

Keep up the great work migrating from Earthly to Earthbuild! 🚀

💡 Tips for finding more occurrences

Run locally to see detailed breakdown:

./.github/scripts/count-earthly.sh

Note that the goal is not to reach 0.
There is anticipated to be at least some occurences of earthly in the source code due to backwards compatibility with config files and language constructs.

[gemini-code-assist]

Code Review

This pull request updates the GitHub Action setup in .github/actions/stage2-setup/action.yml by hardcoding the string 'docker' instead of using the dynamic inputs.BINARY input for both the artifact name and the TAG environment variable. There are no review comments, so we have no feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[janishorsts]

/gemini review

[gemini-code-assist]

Code Review

This pull request replaces the dynamic inputs.BINARY parameter with a hardcoded docker string in both the artifact download name and the image tag suffix within the stage 2 setup action. The reviewer notes that hardcoding docker reduces the action's reusability and flexibility, especially when running podman tests, and suggests using a fallback expression like ${{ inputs.ARTIFACT_SUFFIX || 'docker' }} instead.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[kmannislands]

Is it intentional to serialize tests -> (examples, integrations)?

I think we could reduce wall-clock time further by changing these to depend only on fast-check-and-build and run tests, examples and integrations in parallel,

[janishorsts]

Initially, I had everything in parallel, but multi-step allowed me to visualise what is run for each frontend.

Now all jobs run in parallel.

[kmannislands]

Seems more efficient (less runners used) but wait time to pass doesn't seem to decrease much. Last run on this branch was ~37 mins where the main runs are 37-44 mins over the past few.

I think we could decrease "wait time to green" by running more test steps in parallel

[janishorsts]

Seems more efficient (less runners used) but wait time to pass doesn't seem to decrease much. Last run on this branch was ~37 mins where the main runs are 37-44 mins over the past few.

I think we could decrease "wait time to green" by running more test steps in parallel

@kmannislands, yes, we can run more in parallel. I asked AI to do a performance analysis for successful runs.

🚀 GitHub Actions Performance Analysis (ci.yml)

Base Statement

Baseline Execution Time: Prior to the GitHub Actions workflow optimizations in this PR, successful full runs of the ci.yml workflow averaged 65.19 minutes (median 57.80 minutes / 3,468 seconds) across 173 analyzed baseline runs.

---

Impact Statement

Impact Statement: The workflow refactoring on this branch reduced the median successful CI execution time from 57.80 minutes to 37.97 minutes, achieving a 34.3% reduction in total run duration (~19.8 minutes faster per run). On average across all iterations, total run duration was reduced by 21.29 minutes (32.7% mean speedup).

---

Performance Comparison Breakdown

Metric	Baseline (main / Other Runs)	This PR (ci-speed-up-build)	Improvement
P50 (Median)	57.80 min (3,468s)	37.97 min (2,278s)	⚡ 19.83 min faster (-34.3%)
Mean Duration	65.19 min (3,911s)	43.90 min (2,634s)	⚡ 21.29 min faster (-32.7%)
P99 (Worst Case)	167.31 min (10,039s)	111.85 min (6,711s)	⚡ 55.46 min faster (-33.1%)

Recent Successful PR Runs Benchmark

• Run fix: data race squashed #567: 37.17 min (2,230s)
• Run Settings mismatch on shared buildkitd cancels all in-flight builds #552: 41.87 min (2,512s)
• Run chore(deps): update dependency bazelbuild/bazel to v5.4.1 (main) #547: 37.47 min (2,248s)
• Run fix(deps): update junit-framework monorepo to v6.1.0 (main) #540: 37.97 min (2,278s)
• Run chore(lint): disable deprecated gomodguard #496: 33.12 min (1,987s)