Replace dead Travis config with GitHub Actions - #2
Conversation
This repo has never run tests. The only CI config was a .travis.yml pinning Ruby
2.2.3 and bundler 1.10.6, and it was dead three times over: Travis was never
connected to this fork (created 2026-08-20; a fork does not inherit the
upstream's CI integration), travis-ci.org shut down in 2021, and Ruby 2.2.3 is
long EOL. The PR that prompted this had zero check runs and zero registered
workflows.
The consequence was not theoretical. The suite could not even load -- `extend
Forwardable` with nothing requiring forwardable -- and once that was fixed, 14 of
73 examples failed. Nobody could have known.
Adds a workflow that runs rspec on two rubies:
2.7 (ubuntu-22.04) -- what DeployHQ runs today. Gates.
3.4 (ubuntu-24.04) -- where the app is heading. Advisory via
continue-on-error, so a failure there cannot block a fix for the Ruby
actually in production. Promote to required once consumers have moved.
ubuntu-22.04 is required for 2.7 specifically: setup-ruby ships no 2.7 build for
ubuntu-24.04.
Two details the workflow has to get right:
- The suite is NOT hermetic. spec_helper purges real queues through Bunny, so a
RabbitMQ service container has to be healthy before any example runs.
- The broker user is deliberately NOT `guest`. RabbitMQ restricts guest to
loopback, and a service container is reached over the docker bridge, so guest
authentication is refused. The workflow provisions a `leveret` user instead.
That last point needs spec_helper to be configurable, so it now reads
LEVERET_AMQP_URL and falls back to the same amqp://guest:guest@localhost:5672
developers already use. Local runs are unchanged; verified both paths.
bundler-cache is off on purpose: this gem ships no Gemfile.lock, so there is no
stable key to cache against, and the dependency set is small.
Verified locally on 2.7.8 with and without LEVERET_AMQP_URL set: 73 examples,
0 failures both ways.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Essentials Run ID: 📒 Files selected for processing (1)
Included review availability: 1 review is currently available. Your included PR review attempts over the past 7 days set your current allowance at 4 reviews per hour. WalkthroughThe pull request replaces Travis CI with GitHub Actions for Ruby 2.7 and Ruby 3.4. The workflow provisions RabbitMQ and runs RSpec. The spec helper adds ChangesCI and RSpec Environment Update
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Other Merge Risk: ⚪ Minimal · up to No confirmed merge-blocking behavior is present in the available change evidence. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Git: CodeRabbit could not clone the repository, so clone-backed analysis was skipped and this review may be incomplete. Verify repository clone access, such as SSH credentials, before requesting another full review. If clone access is intentionally unavailable, use Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
The 2.7 job failed at Install dependencies, before a single spec ran:
The last version of bundler (>= 0) to support your Ruby & RubyGems was 2.4.22
bundler requires Ruby version >= 3.2.0. The current ruby version is 2.7.8.225
`gem install bundler` with no constraint resolves to the newest release, which
now requires Ruby >= 3.2. On 2.7 it cannot install at all.
Pin it per Ruby through setup-ruby's own `bundler` input rather than a bare
`gem install`, so the version is fixed by the matrix instead of resolved at run
time: 2.4.22 on 2.7, latest on 3.4. That 2.4.22 is the same pin the consuming
app documents as the last line supporting Ruby 2.7 -- and specifically not
1.17.3, which has a default-gem activation bug that has caused production deploy
outages there.
Also prints `bundle --version` before installing, so the next failure of this
shape is one line of log rather than an inference.
The 3.4 job already passed on the previous run -- 73 examples, 0 failures against
the RabbitMQ service container -- so the service, the non-guest broker user and
LEVERET_AMQP_URL are all confirmed working. Only bundler was wrong.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This repo has never run tests
The only CI config was a
.travis.ymlpinning Ruby 2.2.3 and bundler 1.10.6. It was dead three times over:2026-08-20; a fork does not inherit the upstream's CI integration, and nobody enabled it here.Measured on #1's head:
The consequence was not theoretical. The suite could not even load (
extend Forwardablewith nothing requiringforwardable), and once that was fixed, 14 of 73 examples failed. Nobody could have known.The workflow
continue-on-error3.4 reports without blocking, so a failure there can never block a fix for the Ruby actually in production. It exists to de-risk the in-flight 3.4.9 upgrade; promote it to required once consumers have moved.
ubuntu-22.04is required for 2.7 specifically —setup-rubyships no 2.7 build for ubuntu-24.04.Two details the workflow has to get right
The suite is not hermetic.
spec_helperpurges real queues through Bunny, so a RabbitMQ service container must be healthy before any example runs. Hence the service block and itsrabbitmq-diagnostics -q pinghealth check.The broker user is deliberately not
guest. RabbitMQ restrictsguestto loopback, and a service container is reached over the docker bridge — soguestauthentication is refused. This is the classic way a RabbitMQ-backed Actions workflow fails on first run. The workflow provisions aleveretuser instead.bundler-cacheis off on purpose: this gem ships noGemfile.lock(see #1), so there is no stable key to cache against, and the dependency set is three gems.Scope note — two changes beyond "add a workflow"
Flagging rather than burying:
require 'ostruct'inspec_helper. Three spec files build doubles withOpenStruct;ostructis no longer loaded implicitly, so every example in those files errored before running. This is all 14 of the failures above — one line fixes them. Adding CI that is red on arrival would be worse than no CI, so this belongs here.spec_helpernow readsLEVERET_AMQP_URL, falling back to the sameamqp://guest:guest@localhost:5672developers already use. Required by the non-guestbroker user above. Local runs are unchanged.Testing
Verified locally on 2.7.8, both with and without
LEVERET_AMQP_URLset:I could not verify 3.4 locally — rvm's 3.4.9 gemset has a bundler shim pinned to 2.1.4, which is itself broken on Ruby 3.4 (
uninitialized constant DidYouMean::SPELL_CHECKERS). That is a local environment problem, not the gem's, and it is exactly why 3.4 is advisory here rather than gating: the first honest 3.4 signal will come from this workflow's own first run.🤖 Generated with Claude Code
Summary by CodeRabbit