[build] only build debug artifacts when releasing

[titusfortner]

🔗 Related Issues

Altnerative to #17590

First, we should verify what we are using these for in the first place, but I don't think we need to build the artifacts if we aren't going to save them to the artifacts repo.

💥 What does this PR do?

Gates the Rust debug binary builds (Windows, Linux, macOS) in ci-rust.yml behind the same condition as the release job, so they only run on trunk pushes with rust changes, or when inputs.release is true

[qodo-code-review]

Review Summary by Qodo

Gate Rust debug builds to release conditions only

✨ Enhancement

Walkthroughs

Description

• Gate debug artifact builds behind release conditions
• Prevent unnecessary CI runs on PRs and forks
• Align debug jobs with release job requirements
• Reduce wasted CI minutes on discarded artifacts

Diagram

flowchart LR
  A["Debug Build Jobs<br/>windows-debug<br/>linux-debug<br/>macos-debug"] -->|"Updated if condition"| B["Stricter Gate:<br/>not schedule AND<br/>not fork AND<br/>trunk or release"]
  B -->|"Result"| C["Only run on:<br/>trunk pushes or<br/>manual release"]

Loading

File Changes

1. .github/workflows/ci-rust.yml ⚙️ Configuration changes +3/-3

Gate all debug build jobs to release conditions

• Updated if: condition for windows-debug job to gate behind release requirements
• Updated if: condition for linux-debug job to gate behind release requirements
• Updated if: condition for macos-debug job to gate behind release requirements
• All three debug jobs now share identical condition: exclude schedules, forks, and only run on
 trunk or manual release

.github/workflows/ci-rust.yml

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0)

1. Duplicated release condition 🐞 Bug ⚙ Maintainability

Description

The same long if: expression is now duplicated across the three debug jobs (and also exists on
release), which increases the chance of future edits updating one job gate but not the others and
causing inconsistent CI behavior. Centralizing the condition would reduce drift risk while
preserving the current logic.

Code

.github/workflows/ci-rust.yml[80]

Evidence

The workflow contains the same long gating expression repeated across multiple jobs, so any future
change would need to be made in several places to avoid divergence.

.github/workflows/ci-rust.yml[76-81]
.github/workflows/ci-rust.yml[135-140]
.github/workflows/ci-rust.yml[198-203]
.github/workflows/ci-rust.yml[233-238]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow duplicates a complex release gating expression in multiple jobs. This makes it easy for future changes to accidentally update only one instance (e.g., update `release` but forget a debug job), leading to inconsistent job execution.

### Issue Context
The identical expression appears on:
- `windows-debug`
- `linux-debug`
- `macos-debug`
- `release`

A simple way to keep these in sync is to define the expression once using a YAML anchor (or another shared mechanism) and reference it from each job.

### Fix Focus Areas
- .github/workflows/ci-rust.yml[19-25]
- .github/workflows/ci-rust.yml[76-83]
- .github/workflows/ci-rust.yml[135-141]
- .github/workflows/ci-rust.yml[198-203]
- .github/workflows/ci-rust.yml[233-238]

### Suggested change (example)
Add a shared anchor once (placement can be near the top-level keys):
```yml
x-release-if: &release_if >-
 github.event_name != 'schedule' &&
 github.event.repository.fork == false &&
 (github.ref == 'refs/heads/trunk' || inputs.release)
```
Then replace each duplicated job condition with:
```yml
if: *release_if
```
(Optionally apply the same to the `release` job too, so all 4 jobs reference the same condition.)

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---