You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Three coordinated fixes so that running `make check` against a Rails 7+
project actually mirrors what its CI does. Each gap is small on its own;
together they're the difference between "consumer copies the Makefile and
gets a CI-equivalent local check" and "consumer hits three errors in
sequence and gives up." Closes#30.
Gap A — DOCKER_RUN now passes -e BUNDLE_APP_CONFIG=/workspace/.bundle when
HAS_RUBY is detected. The container exports BUNDLE_APP_CONFIG=/usr/local/bundle
by default (so its bundled tools resolve), which silently overrode the
project's .bundle/config (e.g. `BUNDLE_PATH: vendor/bundle`). Now the
project's config wins for Ruby projects. Required moving the LANGUAGES /
HAS_<LANG> filter computation above DOCKER_RUN so the new env flag could
key off HAS_RUBY at make-time.
Gap B — _test Ruby branch detects Rails (config/application.rb + Gemfile)
and runs `bundle exec rails db:test:prepare` before `rspec`. On
DB-unreachable failures the loader emits a structured error event with a
clear hint ("ensure your test database is reachable") rather than letting
200+ specs fail with cryptic errors. Non-Rails Ruby projects continue to
call rspec directly. Postgres-as-consumer-responsibility documented in
STABILITY.md.
Gap C — _lint/_format/_fix/_test/_security wrap rubocop/reek/brakeman/
bundler-audit/rspec with `bundle exec` ONLY when the tool is pinned in
Gemfile.lock. Implemented via a Make function:
RUBY_EXEC_FOR = $(if $(and $(wildcard Gemfile.lock),$(shell grep ...)),bundle exec ,)
Per-tool detection avoids breaking projects with a Gemfile but no
project-pinned rubocop (which would otherwise fail "could not find
rubocop in any of the sources"). Falls back to the container's bundled
tool when the project does not pin it.
Tested:
- tests/smoke-rails.sh: extended with a 4th check that creates a project
.bundle/config with `BUNDLE_PATH: vendor/bundle` and verifies the
container's `bundle config get path` resolves to it. All 4 checks pass.
- make _check on dev-toolchain itself: pass (no-op for non-Ruby self-check).
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
echo'{"level":"error","msg":"db:test:prepare failed — ensure your test database is reachable (e.g. start postgres before make test)","language":"ruby"}'>&2;\
Copy file name to clipboardExpand all lines: STABILITY.md
+7Lines changed: 7 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,6 +32,13 @@ DevRail has reached **v1.0** across all repositories. The core standards, toolch
32
32
|**Pre-commit hooks**| Stable | Conventional commit hook and per-language hooks configured in template repos. |
33
33
|**Documentation site**| Stable |[devrail.dev](https://devrail.dev) is live with full standards coverage. |
34
34
35
+
## Consumer responsibilities
36
+
37
+
These are services/data the dev-toolchain container does **not** provide; consumers must provide them when relevant:
38
+
39
+
-**Database service** (Postgres, MySQL, etc.) — required for Rails projects whose specs touch the test database. The container runs `bundle exec rails db:test:prepare` before `rspec` (when `config/application.rb` + `Gemfile` are present), which needs a reachable database. Typical local pattern: `docker-compose up -d postgres` before `make test`. Typical CI pattern: a `services:` block.
40
+
-**Project bundle install** — the container ships its own gems for `rubocop`/`reek`/etc. as defaults, but for Gemfile-pinned versions it expects the project's bundle to already be installed (`bundle install`) so `bundle exec <tool>` can find them.
41
+
35
42
## Versioning
36
43
37
44
All DevRail repos follow [Semantic Versioning](https://semver.org/). The container image uses a floating major tag (`:v1`) that always points to the latest `v1.x.x` release. Pin to a specific tag (e.g., `:v1.4.0`) if you need exact reproducibility.
0 commit comments