thecore_generators 3.11.0 → 3.13.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 753f6373a24773431ad2987bd84b7d8609f4a9bedb32dff5a59264bc37c68081
-  data.tar.gz: bc6e8b3d5657bc82bebc1c1913a591e1b7bcb7545f8620d7b4b92704e4735558
+  metadata.gz: 82aaaedd48f043efdbc3f73c96a2dd28a59de2dede02d9be51c457a5ac2a8728
+  data.tar.gz: 6a9e1221628db11797320a882387bf0843cedea3861d3c338619271aa73d8c53
 SHA512:
-  metadata.gz: f5f315cbe3496bca9a6f8ac33c1af880aba847704d1bda5f313dbfecae44cae8e2d66e6548a3e1eabd473921ec36bfddd0f96fae2dc7f509386a3f31059a53f3
-  data.tar.gz: 435300740a43124c459e8688e3a3957693b0fd435e664ee07f52b824b30260d90b4a5d4c70e669157df65a5c1c52acd5a056c69fcf2af1d2ec6e59edf8e9030e
+  metadata.gz: a4781db70ca0658359f4ba768d34a9bce1433aadd1c87565b07a360dc4b57da7c1de98f4366b0b6a0dbaa3f753407433474259d8bcf086cd56366850a813b541
+  data.tar.gz: 0cbc37cc33e26a67f19d1c0a5dddd87595601c964eb5f2d6468ec839075ab8639082a82eb9e40691eaf5cc6496949519d1ba4aee62222e56e7125d5a0026c3bb

data/README.md

@@ -391,9 +391,12 @@ for the full design and why the two stay separate).
 - **Devcontainer/CI/CLAUDE.md**, fetched from the `thecore` repo's own `samples/` (single source
   of truth, not duplicated here) and written unconditionally, overwriting whatever the bootstrap
   "Setup Devcontainer" step created: `.devcontainer/*` (base image, plugin mounts, `gh`/`glab`
-  CLI config mounts commented out by default), `.gitlab-ci.yml` (build/test/lint/deploy, no
-  customer-specific paths), and `CLAUDE.md` (universal sections only, project-specific sections
-  left as TODO placeholders). The fetch location is one overridable point,
+  CLI config mounts commented out by default), **both** `.gitlab-ci.yml` and
+  `.github/workflows/ci.yml` (build/test/lint/deploy, no customer-specific paths — no hosting-
+  profile prompt, same git-hosting-agnostic reasoning ADR 0006 established for `thecore:atom`'s
+  own dual-CI generation, extended here by ADR 0007/thecore_generators#25), and `CLAUDE.md`
+  (universal sections only, project-specific sections left as TODO placeholders). The fetch
+  location is one overridable point,
   `ENV["THECORE_SAMPLES_SOURCE"]`, defaulting to the raw GitHub URL for `thecore`'s `samples/`
   on `master` (`thecore`'s actual default branch).
 - **The standard installer chain** (`devise:install`, `rails_admin:install`, `active_storage:
@@ -401,8 +404,16 @@ for the full design and why the two stay separate).
   each preceded by the necessary `bundle install`) is genuinely optional, gated behind an
   interactive prompt (`yes?`, wrapped in `after_bundle` so it only ever runs once the gems
   above are actually bundled) — a developer bootstrapping without network access can decline
-  and run these by hand later. There is no non-interactive/unattended flag for this in the
-  current version (tracked as a future improvement, not silently missing).
+  and run these by hand later.
+- **Non-interactive/unattended mode**: set `THECORE_APP_TEMPLATE_NON_INTERACTIVE` (any non-blank
+  value) to bypass the installer-chain prompt above. When set, `THECORE_APP_TEMPLATE_RUN_INSTALLERS`
+  (`"true"` or `"false"`) is required — the template aborts with a clear message if it's missing
+  or unrecognized, rather than guessing. Example:
+  ```bash
+  THECORE_APP_TEMPLATE_NON_INTERACTIVE=1 THECORE_APP_TEMPLATE_RUN_INSTALLERS=true \
+    rails new myapp --database=postgresql --asset-pipeline=sprockets \
+    -m https://raw.githubusercontent.com/gabrieletassoni/thecore_generators/release/3/lib/templates/app_template.rb
+  ```
 
 ## Installation
 
@@ -422,17 +433,20 @@ git-based dependencies — see the Gemfile's comment — purely so
 `test/generators/thecore/model_generator_default_concern_behavior_test.rb` can prove the
 no-concern default actually works at runtime, not just that no file was written.
 
+`test/dummy` runs on PostgreSQL only (never SQLite). Create its test database once, then run
+the suite:
+
 ```bash
 bundle install
+(cd test/dummy && RAILS_ENV=test bin/rails db:create)
 bundle exec rake test
 ```
 
-If your shell has `DATABASE_URL` set to a PostgreSQL URL (e.g. inside the Thecore
-devcontainer), unset it first — it overrides `test/dummy`'s own SQLite3 test config:
-
-```bash
-env -u DATABASE_URL bundle exec rake test
-```
+Connection settings come from `PGHOST`/`PGPORT`/`PGUSER`/`PGPASSWORD` (defaults
+`db`/`5432`/`postgres`/`postgres`). If `DATABASE_URL` is set to a PostgreSQL URL (e.g. inside the
+Thecore devcontainer), `test/dummy/config/boot.rb` keeps its server/credentials but always
+swaps the database name to `thecore_generators_<RAILS_ENV>`, so tests never touch the host
+app's database — no need to unset it.
 
 `bundle exec rake` alone runs the same suite (`test` is the default Rake task).
 

data/lib/generators/thecore/workspace_context.rb

@@ -37,7 +37,7 @@ module Thecore
         atom_name = atom_name.to_s.strip
         return resolve_named_atom(app_root, atom_name) unless atom_name.empty?
 
-        resolve_cwd_atom(cwd)
+        resolve_cwd_atom(cwd, app_root)
       end
 
       # Walks up from `dir` until the immediate parent directory is
@@ -137,9 +137,21 @@ module Thecore
             "(expected a #{atom_name}.gemspec or #{atom_name.tr('-', '_')}.gemspec inside it)."
         end
 
-        def resolve_cwd_atom(cwd)
+        # A cwd-detected ATOM only counts when it belongs to the app being
+        # generated into: it must be `app_root` itself (e.g. an engine's own
+        # bin/rails, whose destination_root is already the ATOM) or live
+        # inside it. For a real `rails generate` the app root is always an
+        # ancestor of cwd, so this never changes the normal outcome — but
+        # when `app_root` itself sits *inside* some `vendor/submodules/<x>/`
+        # tree (an ATOM's own test/dummy app, or a gem checked out as a
+        # submodule of a host app and running its own generator tests with
+        # a tmp destination_root), walking up from cwd would otherwise find
+        # that enclosing <x> and redirect every file *out of* app_root into
+        # it. See thecore_generators' CLAUDE.md, WorkspaceContext.
+        def resolve_cwd_atom(cwd, app_root)
           candidate = atom_root_of(cwd)
           return nil unless candidate
+          return nil unless within_app_root?(candidate, app_root)
 
           unless valid_atom_dir?(candidate)
             raise Thor::Error,
@@ -149,6 +161,13 @@ module Thecore
 
           candidate
         end
+
+        def within_app_root?(candidate, app_root)
+          return true if app_root.to_s.empty?
+
+          root = File.expand_path(app_root.to_s)
+          candidate == root || candidate.start_with?("#{root}/")
+        end
       end
     end
   end

data/lib/templates/app_template.rb

@@ -153,6 +153,10 @@ chmod ".devcontainer/link-host-home.sh", 0o755
 chmod ".devcontainer/check-plugins.sh", 0o755
 
 fetch_thecore_sample(".gitlab-ci.yml", ".gitlab-ci.yml")
+# thecore_generators#25 (ADR 0007): fetched unconditionally, alongside .gitlab-ci.yml above --
+# no hosting-profile prompt, same reasoning ADR 0006 already established for thecore:atom's own
+# dual-CI generation (git hosting is a generic, per-developer choice, not something to ask about).
+fetch_thecore_sample(".github/workflows/ci.yml", ".github/workflows/ci.yml")
 fetch_thecore_sample("CLAUDE.md", "CLAUDE.md")
 
 # --- Standard installer chain ------------------------------------------------
@@ -170,10 +174,44 @@ if options[:asset_pipeline].to_s != "sprockets"
     :yellow
 end
 
-run_setup_now = yes?(
-  "Run `bundle install` and the standard installer generators (devise, rails_admin, " \
-  "active_storage, action_text, action_mailbox, cancan, erd) now? (y/n)"
-)
+# thecore_generators#23: non-interactive mode, triggered ONLY by the explicit env var
+# below -- deliberately NOT auto-detected from tty absence the way `thecore:atom`'s
+# `TtyDetection`-based `effectively_non_interactive?` is (ADR 0006). That precedent
+# works because `AtomGenerator` runs in-process inside its own test, where stubbing
+# `$stdin.tty?`/`$stdout.tty?` (see `association_wiring_test.rb`) is meaningful. This
+# template instead always runs as a genuine separate `rails new` subprocess (its own
+# test seam spawns it via Open3), whose stdin is a pipe -- never a real tty -- even
+# when the test is legitimately simulating interactive use by feeding an answer via
+# `stdin_data`. Auto-triggering on tty absence would misfire on every such simulated-
+# interactive test run; the explicit, deliberate opt-in below avoids that with no loss
+# of real-world safety (an unattended CI run with neither var set still fails loudly
+# below, just one env var short of `thecore:atom`'s own auto-detected equivalent).
+non_interactive = !ENV["THECORE_APP_TEMPLATE_NON_INTERACTIVE"].to_s.strip.empty?
+
+run_setup_now =
+  if non_interactive
+    run_installers_raw = ENV["THECORE_APP_TEMPLATE_RUN_INSTALLERS"]
+    if run_installers_raw.nil? || run_installers_raw.strip.empty?
+      abort(
+        "THECORE_APP_TEMPLATE_NON_INTERACTIVE is set but THECORE_APP_TEMPLATE_RUN_INSTALLERS " \
+        "is not -- set it to \"true\" or \"false\" to say whether the installer chain " \
+        "(devise/rails_admin/active_storage/action_text/action_mailbox/cancan/erd) should run."
+      )
+    end
+    normalized = run_installers_raw.strip.downcase
+    unless %w[true false].include?(normalized)
+      abort(
+        "THECORE_APP_TEMPLATE_RUN_INSTALLERS must be \"true\" or \"false\", got " \
+        "#{run_installers_raw.inspect}."
+      )
+    end
+    normalized == "true"
+  else
+    yes?(
+      "Run `bundle install` and the standard installer generators (devise, rails_admin, " \
+      "active_storage, action_text, action_mailbox, cancan, erd) now? (y/n)"
+    )
+  end
 
 after_bundle do
   next unless run_setup_now

data/lib/thecore_generators/version.rb

@@ -1,3 +1,3 @@
 module ThecoreGenerators
-  VERSION = "3.11.0"
+  VERSION = "3.13.1"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: thecore_generators
 version: !ruby/object:Gem::Version
-  version: 3.11.0
+  version: 3.13.1
 platform: ruby
 authors:
 - Gabriele Tassoni