perf: skip prod Docker steps on PRs, use larger runner

[buger]

Summary

Built on top of #8029 to test goreleaser performance optimizations before rolling them out via gromit.

Commit 1: skip prod Docker steps, larger runner

• Larger runner: vars.BUILD_RUNNER || vars.DEFAULT_RUNNER — set BUILD_RUNNER=warp-8x-x64 in repo variables to use 8 vCPUs for goreleaser (currently 4)
• Skip prod Docker steps on PRs: tag metadata, prod build-push, and cache export for all 3 variants (ee, fips, std) are now completely skipped on non-tag builds
• Remove redundant cache-to: prod steps no longer export GHA cache (CI steps already do)

Commit 2: skip fips/std CI Docker pushes on PRs, amd64-only for ee

• Skip fips and std Docker metadata + CI push steps on PRs since no downstream PR gate job consumes those ECR images
• Build ee Docker image as amd64-only on PRs since downstream tests only run on amd64
• Full multi-arch builds still run on branch pushes and tag pushes

Expected savings

Change	Estimated savings
Skip 3 prod Docker steps (build + SBOM + provenance + cache export)	~9 min
Remove 3 redundant cache exports	~4-8 min
Skip fips + std CI Docker pushes on PRs	~6-10 min
amd64-only ee CI image on PRs (skip arm64 + s390x)	~4-6 min
Larger runner (if BUILD_RUNNER set)	~10-15 min

CI/ECR ee image still builds on every PR (amd64-only) — fips and std CI images are skipped on PRs entirely. All images build fully on branch pushes and tag pushes.

Test plan

• Verify goreleaser job completes successfully on this PR
• Compare goreleaser duration vs Merging to release-5.12.1: [TT-16890] critical regression validate request middleware d (#7972) #8029 (expect ~15-20 min shorter)
• Verify CI/ECR ee image is still pushed (check downstream test jobs)
• Verify fips/std CI images are NOT pushed on PR (expected, no downstream consumers)
• Verify prod steps and full multi-arch builds still run on tags (conditional logic)

Gromit template PR: TykTechnologies/gromit#453

🤖 Generated with Claude Code

[github-actions]

API Changes

no api changes detected

[probelabs]

This PR optimizes the release.yml GitHub Actions workflow to significantly reduce build times for pull requests.

Files Changed Analysis

• .github/workflows/release.yml: The only file changed. The modifications focus on adding conditional logic to skip production-specific steps during PR builds, updating the runner configuration, and optimizing Docker build parameters. The number of additions and deletions is equal, reflecting the modification of existing workflow steps rather than the addition of new ones.

Architecture & Impact Assessment

• What this PR accomplishes:

  • Accelerates the CI feedback loop for developers by skipping time-consuming Docker image publishing steps that are only necessary for official releases.
  • Introduces the ability to use a more powerful, configurable runner for build jobs, further reducing execution time.
  • Optimizes the Docker build process for PRs by building for a single platform (linux/amd64) and removing redundant cache export operations.

• Key technical changes introduced:

  • The runs-on directive now uses vars.BUILD_RUNNER || vars.DEFAULT_RUNNER, allowing the build runner to be scaled via repository variables.
  • Production Docker metadata generation and image push steps for all variants (ee, fips, std) are now conditionally executed only for tag pushes (if: startsWith(github.ref, 'refs/tags')).
  • The platforms for the initial CI Docker build is conditionally limited to linux/amd64 on pull requests to speed up cross-compilation.
  • The cache-to directive is removed from production push steps to eliminate redundant cache writes.
  • Note: The conditions for pushing fips and std CI images have been modified to not run on pull requests (github.event_name != 'pull_request'). This appears to contradict the PR description's claim that all CI/ECR images are still built. This should be verified during review.

• Affected system components:

  • The primary impact is on the CI/CD pipeline's performance and efficiency. There are no changes to the application's source code or runtime behavior.

• Workflow Visualization:

graph TD
subgraph release_workflow ["Release Workflow"]
A[Start Job] --> B{Is event a tag push?}
B --|No (PR)|--> C[Build for amd64 only]
C --> D[Push EE CI Image]
D --> E[Skip Prod Image Steps]
E --> F[Finish]
B --|Yes (Tag)|--> G[Build for all platforms]
G --> H[Push EE/FIPS/STD CI Images]
H --> I[Generate Metadata & Push Prod Images]
I --> F
end

## Scope Discovery & Context Expansion
- The changes are localized to the `release.yml` workflow but improve a critical part of the development lifecycle by optimizing for the most common event (pull request updates).
- This PR establishes a clear separation between CI builds (for validation) and release builds (for publication), which is a CI/CD best practice.
- The use of `vars.BUILD_RUNNER` points to an operational strategy of managing CI infrastructure resources through GitHub variables, allowing for performance tuning without code changes.
- A key area for review is to confirm whether downstream jobs depend on the `fips` and `std` CI images being available on every PR, as the current changes will prevent them from being pushed.


<details>
  <summary>Metadata</summary>

  - Review Effort: 2 / 5
  - Primary Label: chore


</details>
<!-- visor:section-end id="overview" -->

<!-- visor:thread-end key="TykTechnologies/tyk#8057@3953c51" -->

---

*Powered by [Visor](https://probelabs.com/visor) from [Probelabs](https://probelabs.com)*

*Last updated: 2026-04-16T20:23:49.979Z | Triggered by: pr_updated | Commit: 3953c51*

💡 **TIP:** You can chat with Visor using `/visor ask <your question>`
<!-- /visor-comment-id:visor-thread-overview-TykTechnologies/tyk#8057 -->

[probelabs]

✅ Security Check Passed

No security issues found – changes LGTM.

✅ Performance Check Passed

No performance issues found – changes LGTM.

✅ Security Check Passed

No security issues found – changes LGTM.

\n\n \n\n

✅ Performance Check Passed

No performance issues found – changes LGTM.

\n\n

Quality Issues (2)

Severity	Location	Issue
🔴 Critical	.github/workflows/release.yml:167	The expression used to conditionally set the `platforms` value is incorrect. The logical operators `&&` and `||` in GitHub Actions expressions return boolean values (`true` or `false`), not one of the operands. This expression will always evaluate to `true`, which is an invalid value for the `platforms` input and will cause the workflow step to fail. 💡 Suggestion Use the `if()` function to correctly select the platform string based on the event type. 🔧 Suggested Fix platforms: ${{ if(github.event_name == 'pull_request', 'linux/amd64', 'linux/amd64,linux/arm64,linux/s390x') }}
🟠 Error	.github/workflows/release.yml:215-305	The condition `github.event_name != 'pull_request'` was added to the steps that push `fips` and `std` CI images (lines 215, 226, 290, 305). This prevents these images from being built and pushed on pull requests, which contradicts the PR description's statement: "CI/ECR images still build on every PR as before". This change could break downstream test jobs that rely on these images being available for PRs. 💡 Suggestion To align with the stated intent in the PR description, remove the `&& github.event_name != 'pull_request'` condition from the `if` clauses for the `fips` and `std` CI image push steps.

---

Powered by Visor from Probelabs

Last updated: 2026-04-16T20:23:47.605Z | Triggered by: pr_updated | Commit: 3953c51

💡 TIP: You can chat with Visor using /visor ask <your question>

[github-actions]

🚨 Jira Linter Failed

Commit: daced74
Failed at: 2026-04-16 20:58:44 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details

failed to validate branch and PR title rules: neither branch name 'perf/goreleaser-optimization' nor PR title 'perf: skip prod Docker steps on PRs, use larger runner' contains a valid Jira ticket ID (e.g., ABC-123)

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

---

This comment will be automatically deleted once the linter passes.

[buger]

Closing: test PR, served its purpose. Optimizations captured in gromit#453.