opencode-ruby-upgrader 0.1.7 → 0.1.8

package/README.md

@@ -117,7 +117,7 @@ The agent defaults unknown shell commands to an OpenCode confirmation prompt. Gi
 
 New reports require `record-executed-iteration --validation <id>` or `record-executed-rails-iteration --validation <test-id>`; asserted results cannot be recorded or committed. The accepted IDs map to fixed no-shell commands: `bundle-rspec`, `bundle-rails-test`, `bundle-rake-test`, `bin-rails-test`, and, for Rails bridges, `rails-app-update`. When the target Ruby is unavailable on your host, the agent runs `prepare-target-runtime --ruby <x.y.z>` after selecting the exact target patch release. One confirmation provisions labeled per-run Ruby and isolated database Docker resources, installs Node, installs Bundler 2.4.22, runs `bundle install`, and, for Rails, creates the isolated test database.
 
-The isolated test database is PostgreSQL by default. If the project declares MySQL through `mysql2` (the gem or the adapter in `config/database.yml`) and not PostgreSQL, the runtime is prepared with an isolated MySQL 8.4 server instead. The engine is detected from `Gemfile`, `Gemfile.lock`, and `config/database.yml`; the legacy `mysql` and `trilogy` gems are not recognized, and a project that declares both engines stops preparation and asks you to choose:
+The isolated test database is PostgreSQL by default. If the project declares MySQL through `mysql2` and not PostgreSQL, the runtime is prepared with an isolated MySQL 8.4 server instead. Detection reads declarations rather than incidental words: an `adapter:` line in `config/database.yml`, a `gem "mysql2"` / `gem "pg"` line, a resolved spec in `Gemfile.lock`, or a driver URL. `config/database.yml` wins over gem declarations, because a gem line only says a driver is *available* while the YAML says what the app connects to — so a PostgreSQL project that keeps `gem "mysql2"` for an unrelated import tool still resolves to PostgreSQL. The legacy `mysql` and `trilogy` gems are not recognized, and a project that declares both engines stops preparation and asks you to choose:
 
 ```bash
 opencode-ruby-upgrader prepare-target-runtime --ruby <x.y.z> --database mysql

package/RELEASE_CHECKLIST.md

@@ -5,7 +5,7 @@ Complete every item before pushing a `v*` tag. The protected `npm-release` envir
 ## Before every release
 
 - [ ] Bump the version and update [RELEASE_NOTES.md](RELEASE_NOTES.md): scope, supported adapters, known limitations, rollback.
-- [ ] For every newly supported adapter — including a database engine — record real container evidence, not only mocked tests. `npm run test:docker:mysql` provisions a real `mysql:8.4`, connects from the app through its own `mysql2` driver, and checks the receipt. Do not ship a new adapter on unit tests alone. The `mysql-runtime` CI job runs it on every pull request and `release.yml` runs it again before `npm publish`, so this is enforced rather than advisory.
+- [ ] For every newly supported adapter — including a database engine — record real container evidence, not only mocked tests. `npm run test:docker` provisions a real `mysql:8.4` **and** a real `postgres:16-alpine`, connects from each app through its own driver, and checks the receipt. Do not ship a new adapter on unit tests alone. The `adapter-runtime` CI job runs both engines on every pull request and `release.yml` runs them again before `npm publish`, so this is enforced rather than advisory. Prove it for every adapter you ship, not just the one you changed: the adapter that has no container evidence is the one that surprises you.
 - [ ] Review new or changed CLI options in `opencode-ruby-upgrader <command> --help`; users should not have to read the source to find a documented flag.
 - [ ] Reconcile README, `agents/ruby-upgrade.md`, and release notes with the shipped behavior: defaults, detection and ambiguity behavior, resource lifecycle, and what is persisted.
 - [ ] Repoint the README's tag-pinned links to the new version tag: `E2E_EVIDENCE.md`, `PRIVACY.md`, `SECURITY.md`, `docs/rails-bridge.md`, and both screenshot URLs. They are pinned to a tag so the registry page always shows the docs of the installed version rather than whatever `main` currently says; leaving them on the previous tag makes the published page drift behind the release.

package/RELEASE_NOTES.md

@@ -1,5 +1,30 @@
 # opencode-ruby-upgrader — release notes
 
+## v0.1.8 — real-adapter detection and PostgreSQL container evidence
+
+v0.1.7 shipped database detection that had only ever been tested against hand-written fixtures. Running it against real Rails applications found three wrong answers, one of them silent. This release fixes detection and closes the container-evidence gap for the default adapter.
+
+**Scope**
+
+- Detection now matches declarations rather than tokens. Previously `mysql2` matched anywhere in `Gemfile`, `Gemfile.lock`, or `config/database.yml`, while PostgreSQL required an `adapter:` line. That asymmetry meant only a false *MySQL* answer was possible, and it happened: rails/rails ships `activerecord/test/config.example.yml` with `mysql2:` and `postgresql:` as YAML keys naming a profile under `connections:`, and every adapter actually selected is `sqlite3`. The old rule read the `mysql2:` key and silently reported MySQL. A key that names a profile is not a declaration, so it no longer counts.
+- `config/database.yml` now takes precedence over gem declarations. A `gem` line only says a driver is *available*; the YAML says what the app connects to. Discourse is PostgreSQL throughout its `config/database.yml` while carrying `gem "mysql2"` behind an import-mode conditional — previously reported as ambiguous, forcing an explicit flag on an unambiguous project. Redmine's `database.yml.example` selects `mysql2` for every environment with `postgresql` commented out, while its `Gemfile` conditionally declares both engines; it now resolves to MySQL rather than refusing to answer.
+- `Gemfile.lock` is read as a declaration source in its resolved-spec form (`    mysql2 (0.5.6)`, `    pg (1.6.2)`), so a project with a generated or templated `Gemfile` still resolves correctly.
+- Genuinely multi-engine projects still stop and ask. Spree declares both drivers and no `config/database.yml`, and continues to require an explicit choice.
+
+**Evidence**
+
+`npm run test:docker` now proves **both** adapters against real containers: a real `mysql:8.4` and a real `postgres:16-alpine`, each connected from a throwaway Rails app through its own driver, each asserting a passing RSpec receipt, a secret-free persisted manifest, and its own teardown. Detection is deliberately left to run rather than passed `--database`, so a leg that only worked because it was told the answer could not pass. The CI job is now `adapter-runtime` and `release.yml` runs both engines before publishing.
+
+The smoke fixture is now a real Rails application rather than a bare `Gemfile`. That is not cosmetic: PostgreSQL's adapter creates its test database through the app's own `rake db:create`, so it requires a bootable app, while MySQL's creates it server-side and would accept a `Gemfile` alone. The MySQL leg had therefore been passing against a fixture that could never have exercised the PostgreSQL path. The fixture also pins `host: localhost` with a nonexistent user, so a passing run proves `DATABASE_URL` overrides the project's own configuration rather than accidentally agreeing with it.
+
+Detection regressions from real projects are unit-tested from the actual file shapes: the rails/rails profile keys, the Discourse import-mode gem, the Redmine commented-out adapter, the Spree ambiguity, and both `Gemfile.lock` forms.
+
+**Known limitations**
+
+- Prepared containers, networks, and images are not torn down when a run completes or is paused. They persist for reproducibility and are removed manually; the names are recorded in `.ruby-upgrades/runtime.json`. Still no `dispose-target-runtime` command — cleanup remains documented rather than automated, and is the most requested follow-up.
+- Detection is static text matching. A dynamically computed adapter, or a project whose test environment differs from its other environments, may need an explicit `--database`.
+- `--database mysql2://` URLs are emitted for MySQL and `postgresql://` for PostgreSQL; a project relying on driver-specific `database.yml` keys beyond adapter, host, user, and password is not modelled.
+
 ## v0.1.7 — isolated MySQL runtime
 
 The isolated validation runtime can now prepare MySQL as well as PostgreSQL.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-ruby-upgrader",
-  "version": "0.1.7",
+  "version": "0.1.8",
   "description": "A safe, evidence-driven Ruby runtime upgrade agent and local migration dashboard for OpenCode",
   "author": "Priscilla Cournoyer (https://github.com/lilla021)",
   "repository": {
@@ -18,7 +18,9 @@
   },
   "scripts": {
     "test": "node --test tests/*.test.js",
-    "test:docker:mysql": "node tests/docker-mysql-smoke.mjs",
+    "test:docker": "node tests/docker-adapter-smoke.mjs",
+    "test:docker:mysql": "node tests/docker-adapter-smoke.mjs mysql",
+    "test:docker:postgres": "node tests/docker-adapter-smoke.mjs postgres",
     "test:opencode": "node tests/opencode-runtime-smoke.mjs"
   },
   "allowScripts": {

package/src/databases.js

@@ -40,7 +40,11 @@ export const databases = Object.freeze({
     startArgs: () => ["--env", "POSTGRES_HOST_AUTH_METHOD=trust", "--env", `POSTGRES_DB=${DB_NAME}`, "postgres:16-alpine"],
     readyArgs: (container) => ["exec", container, "pg_isready", "-U", "postgres", "-d", DB_NAME],
     // Use the app's own Rails task so framework-specific database setup remains
-    // consistent with the project's PostgreSQL adapter.
+    // consistent with the project's PostgreSQL adapter. DATABASE_URL is already
+    // set on the app container and Rails prefers it over database.yml, so a
+    // project pinning `host: localhost` or a socket-only DSN still resolves to
+    // the isolated container -- no rewriting of the config under test, which
+    // would be a source change to the worktree.
     createArgs: ({ appContainer }) => ["exec", appContainer, "bundle", "exec", "rake", "db:create"],
     databaseUrl: (container) => `postgresql://postgres@${container}:5432/${DB_NAME}`,
     ensureReady: ({ probe }) => readyLoop({ probe, attempts: 30, label: "PostgreSQL" })
@@ -75,18 +79,42 @@ export function resolveDatabase(adapter) {
   return databases[key];
 }
 
+// Declarative forms only. A bare word is not a declaration: real
+// `config/database.yml` files carry YAML keys that merely *name* a profile
+// (rails/rails ships `connections:` with `mysql2:` and `postgresql:` keys and
+// only `adapter: sqlite3` in play), and a Gemfile may carry a driver for an
+// unrelated tool. Matching bare tokens made detection asymmetric -- mysql2
+// matched anywhere while postgres required `adapter:` -- so the bias could only
+// ever produce a false MySQL answer, silently.
+const MYSQL = [/\badapter\s*:\s*mysql2\b/i, /\bgem\s*\(?\s*["']mysql2["']/i, /\bmysql2:\/\//i];
+const POSTGRES = [/\badapter\s*:\s*(?:postgresql|postgres)\b/i, /\bgem\s*\(?\s*["']pg["']/i, /\b(?:postgresql|postgres):\/\//i];
+// Gemfile.lock records resolved specs as `    mysql2 (0.5.6)` / `    pg (1.6.2)`.
+const MYSQL_LOCK = /^[ \t]*mysql2 \(/m;
+const POSTGRES_LOCK = /^[ \t]*pg \(/m;
+
 // Best-effort adapter detection from the project's own declarations. An
 // explicit `--database` always wins; this only fills the gap so the common case
 // needs no flag.
 export function detectDatabase(root = process.cwd()) {
   const read = (file) => { try { return fs.readFileSync(path.join(root, file), "utf8"); } catch { return ""; } };
   const uncommented = (contents) => contents.replace(/#.*$/gm, "");
-  const corpus = [read("Gemfile"), read("Gemfile.lock"), read("config/database.yml")].map(uncommented).join("\n");
-  const mysql = /\bmysql2\b/i.test(corpus) || /adapter:\s*mysql2\b/i.test(corpus);
-  const postgres = /\bpg\b/i.test(corpus) || /adapter:\s*(?:postgresql|postgres)\b/i.test(corpus) || /postgresql:\/\//i.test(corpus);
-  if (mysql && postgres) throw new Error("Both MySQL and PostgreSQL were detected. Specify --database mysql or --database postgres.");
-  if (mysql && !postgres) return "mysql";
-  return "postgres";
+  const declares = (contents, lock) => ({
+    mysql: MYSQL.some((re) => re.test(contents)) || (lock && MYSQL_LOCK.test(contents)),
+    postgres: POSTGRES.some((re) => re.test(contents)) || (lock && POSTGRES_LOCK.test(contents)),
+  });
+  const resolve = ({ mysql, postgres }) => {
+    if (mysql && postgres) throw new Error("Both MySQL and PostgreSQL were detected. Specify --database mysql or --database postgres.");
+    return mysql ? "mysql" : postgres ? "postgres" : null;
+  };
+  // `config/database.yml` is what the app actually connects to; a `gem` line
+  // only says a driver is *available*. Discourse, for instance, is PostgreSQL
+  // (`adapter: postgresql` throughout) but carries `gem "mysql2"` behind an
+  // import-mode conditional. OR-ing both files reported that as ambiguous and
+  // needlessly forced an explicit flag on an unambiguous project.
+  const configured = resolve(declares(uncommented(read("config/database.yml")), false));
+  if (configured) return configured;
+  const gems = resolve(declares(`${uncommented(read("Gemfile"))}\n${uncommented(read("Gemfile.lock"))}`, true));
+  return gems ?? "postgres";
 }
 
 export { DB_NAME, NAME };