The result jobs in macOS workflows only check if other jobs failed
(just runs `exit 1`). They don't need macOS runners. Using
ubuntu-latest instead frees up macOS runner slots and starts faster
due to shorter queue times.
microsoft/vcpkg bumped `scripts/vcpkg-tools.json` to schema version 2,
which the vcpkg.exe bundled in the runner images cannot parse, so every
Windows job started failing at `vcpkg install` right after the `git pull`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(cherry picked from commit f275e95ff23f1a299b2a72fc47758de539db8dde)
The full macOS fan-out (10 jobs, about 117 runner-minutes) repeats
test tasks that macos.yml already runs from the git tree on every
event; what is tarball-specific is only that the packaged tarball
configures, builds and installs. Run a single check on macos-26 for
pull requests and pushes, and keep the full matrix for
workflow_dispatch, which is how the nightly schedule and release
verification invoke it. Only macOS is trimmed: its org-wide
concurrency pool of 50 runners saturates during peak hours and has
been delaying release jobs, while Linux and Windows share a pool with
headroom.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
(cherry picked from commit df977545f07404ac6b49b6992a4ab78c2f2b0f9a)
The cache step hardcoded snapshot-*, which no longer matches when this
reusable workflow is called with a release archname such as
ruby-3.4.0-rc1 from ruby/actions, turning cache save and restore into
a no-op.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
(cherry picked from commit 674e93935c846f129329e78c4270015ed1805e80)
OPENSSL_MODULES moves into the setup env step where the triplet is
available as an environment variable.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
(cherry picked from commit 39a61bc1ef3407b0eb761307946a4b9af0ac477c)
Compose VCPKG_BINARY_SOURCES from FEED_URL in the setup step so the
feed URL is defined in one place, and use github.repository_owner so
forks running these workflows use their own GitHub Packages feed
instead of failing to authenticate against the ruby feed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
(cherry picked from commit 0574c02a6ce5cbfe18836b92363882a5cee1fa9e)
A called workflow may only keep or reduce the permissions of the caller
job. On fork pull requests the caller token is capped to read-only, so
declaring packages: write here is an elevation request and the job
fails at startup. Inherit the caller's permissions instead.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
(cherry picked from commit 19b32cc45c44fa4689d5c5ac95f0832326d3c1b6)
vcpkg-tool removed the x-gha provider, and the actions/cache strategy
was wasteful: windows.yml rebuilt every port on each baseline bump, and
tarball-windows.yml keyed its cache on github.sha, saving a new ~22MB
entry per run and pinning the repository at the 10GB cache quota. A
NuGet feed on GitHub Packages caches binaries per port keyed by vcpkg's
ABI hash and is shared across branches and workflows. tarball-windows
now installs from the manifest included in the snapshot so it reuses
the packages built by windows.yml.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
(cherry picked from commit debd913e7e5425249b974ba4cf714aa21b8ce5fe)
- Add ruby-devel to the Cygwin package list so native extensions can build
- Install the fiddle gem explicitly via Cygwin bash before configuring
(cherry picked from commit fd34f67b18c79a3db7452924389c777371a474c8)
Backport the macos.yml matrix change from 5c762e786bb so this branch
also exercises macos-15-intel (and makes macos-26 the default runner).
Other workflows touched by the original commit are out of scope.
The macos-15 runner image ships a pre-installed Ruby under /usr/local
whose default-gem directory shares the 3.3.0 ABI path with the snapshot
build. With the default prefix, RDoc generation scans that directory and
dies on a stale bundler default-gem stub left by the runner's RubyGems
self-update. Build, install and verify under an isolated prefix instead.
(cherry picked from commit dc24122d900c32a14db56a4f1def4f79027a24ee)
Dir.each_child yields entry names, so stat/digest/children ran against
the working directory instead of HOME. Join dir and name first.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
(cherry picked from commit 76be52bd01a1c774c2337b7fb18f93761a6691d9)
Make macos-26 the default runner for the tarball build verification and
keep macos-15, macos-15-intel, and macos-14 as regression coverage.
(cherry picked from commit 5c762e786bb14ec46a15e1073e1d806fa9a39a1c)
Replace secrets: inherit with explicit Slack webhook secrets, which are
the only secrets the ubuntu/macos/windows builds use. tarball-non-development
uses no secrets, so drop inherit there entirely.
(cherry picked from commit daea48078cd029b16ef5a4a31fe7fedf72bb00f0)
The subsequent git steps only fetch from the public origin and operate
on local branches, so the token does not need to be persisted.
(cherry picked from commit f00e912db0d175ffe61d7195f40c10838be1c826)
These reusable workflows only check out, download artifacts, build, and
test, so contents: read is sufficient.
(cherry picked from commit 28c8bef6d78f4fc50e7e14afd5dd7c121e2639e6)
Backport of ruby/ruby#17063 to ruby_4_0. All four reusables and the
make-snapshot composite are now blob-identical to master, including
tarball-windows since ruby_4_0 already runs the modern windows-2022 +
windows-2025-vs2026 matrix. tarball-test no longer passes
allow-failures, remove-gnupg, notify-ruby-sha, or branch-label because
the reusables no longer accept them. notify-release-channel is wired
through to all three per-OS calls so the schedule dispatcher can keep
routing failures to two Slack channels. The tarball job now invokes
ruby/ruby/.github/actions/make-snapshot@master so future composite
fixes don't need re-cherry-picking.
zizmor flags `cd "${{ inputs.archname }}/"` inside `run:` blocks as
code injection via template expansion: GitHub Actions substitutes the
input value into the shell script verbatim, so a caller passing shell
metacharacters could execute arbitrary code.
Hoist `ARCHNAME: ${{ inputs.archname }}` to the job-level `env:` block
and reference it as `$ARCHNAME` in shell, matching the pattern already
used by tarball-windows.yml (see 942f45b2af).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The per-OS tarball-test workflows currently hard-code `cd snapshot-*/`
to enter the extracted tarball directory, which prevents callers from
producing tarballs under any other prefix (for example `ruby-3.4.0-rc1`
emitted by `tool/make-snapshot` when given a version argument).
Replace the glob with `cd "${{ inputs.archname }}/"`. Existing snapshot
callers still pass `snapshot-<branch>` so behavior is unchanged for
this repository, but ruby/actions can now reuse the same workflows
from `draft-release.yml` with `ruby-<version>` archnames.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ruby_4_0 only builds with vssetup.cmd against windows-2022 and
windows-2025-vs2026, so the mode input and the legacy branch are
dead code on this branch. Drop the input, hardcode the modern
matrix and setup-env step, and stop passing mode: modern from
tarball-test.yml.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
GitHub Actions schedule triggers only fire on the default branch, so
the daily cron in tarball-test.yml never ran on ruby_4_0. Switch the
trigger to workflow_dispatch so master's tarball-test-schedule.yml
can dispatch it via gh workflow run --ref ruby_4_0.
https://github.com/ruby/ruby/commit/9e92537490
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Port the daily snapshot tarball pipeline from ruby/actions into
ruby/ruby so the tarball build and per-OS tests run on every push and
pull request. The make-snapshot composite action gains a srcdir input so
the same logic can either clone ruby/ruby (daily upload from ruby/actions)
or operate on the working tree (this workflow).
ruby_4_0 mirrors master and only flips env.BRANCH in tarball-test.yml;
archname / branch-label / Materialize all derive from it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
