chore: macos-15-intel runner on ci #31419
Conversation
WalkthroughUpdated macOS CI runners from Estimated code review effortMedium | ~10–20 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)
Tip 📝 Customizable high-level summaries are now available in beta!You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
Example instruction:
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/ci.generate.ts(1 hunks).github/workflows/ci.yml(2 hunks)Cargo.toml(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-24T16:19:37.808Z
Learnt from: CR
Repo: denoland/deno PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:19:37.808Z
Learning: Use `cargo update` to update Cargo dependencies to latest compatible versions
Applied to files:
Cargo.toml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build libs
🔇 Additional comments (2)
.github/workflows/ci.yml (1)
63-63: LGTM - generated file changes are consistent.The macOS runner updates from macos-13 to macos-15-intel are correctly applied across the build and lint matrices, consistent with the source changes in ci.generate.ts.
Also applies to: 68-68, 765-765
.github/workflows/ci.generate.ts (1)
15-15: Themacos-15-intelrunner label is valid and officially available on GitHub Actions.Verification confirms that
macos-15-intelis a documented, supported runner label provided by GitHub for macOS 15 with Intel (x86_64) architecture. No CI failures will occur due to runner unavailability. The code is correct as written.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/ci.generate.ts(2 hunks).github/workflows/ci.yml(3 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)
- GitHub Check: test debug linux-x86_64
- GitHub Check: test release linux-x86_64
- GitHub Check: test release linux-aarch64
- GitHub Check: test debug linux-aarch64
- GitHub Check: test debug windows-x86_64
- GitHub Check: test debug macos-aarch64
- GitHub Check: test debug macos-x86_64
- GitHub Check: lint debug windows-x86_64
- GitHub Check: lint debug macos-x86_64
- GitHub Check: lint debug linux-x86_64
- GitHub Check: build libs
🔇 Additional comments (3)
.github/workflows/ci.yml (2)
63-63: macOS runner label updates look good.The updates from
macos-13tomacos-15-intelare applied consistently across the build and lint job matrices for macOS x86_64. The conditional logic on line 68 (PR-based fallback to ubuntu-24.04) is preserved correctly.Also applies to: 68-68, 771-771
396-401: The tmate action version is current and maintained.The
mxschmitt/action-tmate@v3action uses the latest v3 release (v3.23, released October 23, 2025). This major version pinning follows semantic versioning best practices and is the recommended usage pattern in the action's documentation. No concerns with the version specification..github/workflows/ci.generate.ts (1)
15-15: macOS x86 runner label update looks goodUsing
macos-15-intelvia themacosX86Runnerconstant cleanly propagates to all macOS x86 matrix entries; no further changes needed here.
.github/workflows/ci.generate.ts
Outdated
| { | ||
| name: "Setup tmate session", | ||
| if: [ | ||
| "(matrix.job == 'test' || matrix.job == 'bench') &&", | ||
| "matrix.profile == 'debug' && (matrix.os == 'macos' ||", | ||
| "github.repository == 'denoland/deno')", | ||
| ].join("\n"), | ||
| uses: "mxschmitt/action-tmate@v3", | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, check the exact content at lines 697-705
sed -n '690,710p' .github/workflows/ci.generate.tsRepository: denoland/deno
Length of output: 170
🏁 Script executed:
#!/bin/bash
# Check the file at the specified lines
sed -n '690,720p' .github/workflows/ci.generate.tsRepository: denoland/deno
Length of output: 170
🌐 Web query:
mxschmitt/action-tmate v3 interactive session blocking behavior
💡 Result:
Summary: By default mxschmitt/action-tmate@v3 starts a tmate session and blocks the job — it waits (pauses) until the tmate session is finished (typically when the connected user exits). If you want the job to continue immediately, use detached: true; detached mode starts the session, prints connection info, continues the next steps, and then waits at the end of the job for the session to exit (and will auto-terminate after 10 minutes if nobody connects). [1][2]
Sources:
- README (mxschmitt/action-tmate v3). [1]
- Documentation site (action-tmate). [2]
🌐 Web query:
deno ci workflow debug tmate session best practices
💡 Result:
Here are concise best practices for using tmate to debug Deno CI workflows (securely and effectively):
-
Make debugging opt‑in (manual or on failure)
- Enable tmate only for workflow_dispatch with a debug input or run it when a job fails (if: failure()). (github.com)
-
Prefer detached / short sessions and explicit timeouts
- Use detached mode or set timeout-minutes so sessions don’t keep runners alive indefinitely. (github.com)
-
Minimize privileges and secrets exposure
- Don’t expose secrets to PRs or forked runs; scope GITHUB_TOKEN permissions and avoid running tmate for untrusted events. Revoke/rotate tokens after debugging. (github.blog)
-
Limit who can access the session
- Restrict session access to repository actors or trusted teams; prefer actions that support “limit-access-to-actor” or equivalent. Use audit logs to track access. (github.com)
-
Use ephemeral keys / ephemeral sessions
- Prefer ephemeral SSH keys or web‑based tmate connections that expire automatically. Configure automatic shutdown if no one connects. (mxschmitt.github.io)
-
Keep sensitive operations out of debug sessions
- Don’t run deploys, secret dumps, or production‑affecting commands inside tmate sessions. Treat the runner as ephemeral and untrusted. (github.blog)
-
Combine with Deno’s local debugging options
- For application debugging prefer Deno flags (--inspect, --inspect-wait, --inspect-brk) and IDE tools; use tmate for runner/system-level investigation only. (docs.deno.com)
-
Repro and artifact hygiene
- Save logs, test artifacts, and failing input so you can reproduce fixes without re‑opening sessions. Clean workspace before finishing. (mxschmitt.github.io)
-
Use a narrow scope and ephemeral runners when possible
- If you use self‑hosted runners, be extra cautious: isolate runner, wipe state after debug, or prefer GitHub-hosted runners for temporary sessions. (docs.github.com)
-
Automate safe defaults in workflow templates
- Provide a standard debug step (conditional, timeboxed, least‑privilege) in your reusable workflow so teams follow the same secure pattern. (github.com)
If you want, I can:
- Generate a ready-to-use GitHub Actions snippet for Deno that integrates tmate with timeouts, manual enable, and least-privilege settings.
- Or produce a checklist for post-debug cleanup (token rotation, runner wipe).
Citations:
- 1: https://github.com/mxschmitt/action-tmate?utm_source=openai
- 2: https://github.com/mxschmitt/action-tmate?utm_source=openai
- 3: https://github.blog/security/supply-chain-security/four-tips-to-keep-your-github-actions-workflows-secure/?utm_source=openai
- 4: https://github.com/lhotari/action-upterm?utm_source=openai
- 5: https://mxschmitt.github.io/action-tmate/?utm_source=openai
- 6: https://github.blog/security/supply-chain-security/four-tips-to-keep-your-github-actions-workflows-secure/?utm_source=openai
- 7: https://docs.deno.com/runtime/fundamentals/debugging/?utm_source=openai
- 8: https://mxschmitt.github.io/action-tmate/?utm_source=openai
- 9: https://docs.github.com/en/actions/how-tos/security-for-github-actions?utm_source=openai
- 10: https://github.com/mxschmitt/action-tmate?utm_source=openai
Re-enabled tmate step will run on every eligible debug test/bench job and block CI indefinitely
The mxschmitt/action-tmate@v3 action blocks by default until the tmate session is manually terminated. Configuring it to run on every debug test/bench job (all matrix.job == 'test' || 'bench' with matrix.profile == 'debug' on macOS or the denoland/deno repository) will halt routine CI runs unless someone actively connects to the session.
According to GitHub Actions security best practices, tmate sessions should be opt-in only—either triggered manually via workflow_dispatch with a debug input or enabled conditionally on failure (if: failure()). If this is intentional for ad-hoc debugging, consider gating behind a workflow input or label, or use detached mode with an explicit timeout to prevent indefinite blocking.
🤖 Prompt for AI Agents
.github/workflows/ci.generate.ts around lines 697 to 705: the tmate step as
written will start an interactive session that blocks the job indefinitely for
every debug test/bench matrix entry; change it so tmate is opt-in or nonblocking
by gating the step behind a workflow input (e.g., only run when a debug input is
set) or run it only on failure (if: failure()), or configure the action in
detached mode with an explicit timeout so it cannot block CI indefinitely.
littledivy
force-pushed
the
macos-intel-15-ci
branch
from
0954696 to
3604f6d
Compare
1 participant
This includes fixes from denoland/sui@e229ef1