Redmine

Marius BĂLTEANU wrote in #note-6:

With this change, installations that use a database.yml configuration that contains <%= ENV[<name>] %> in any key except adapter will fail.

I prefer to keep to warning instead of delivering this potential breaking change in a patch / maintenance release.

If we really want to fix this warning, we can scan for something like <%= ENV in the entire file instead of looking only on the adapter line.

Marius BĂLTEANU wrote in #note-6:

With this change, installations that use a database.yml configuration that contains <%= ENV[<name>] %> in any key except adapter will fail.

No, such an issue will not occur. This is because the purpose of the code in the Gemfile is solely to retrieve the list of database adapters used in database.yml and install the necessary gems. Database connections are managed by Rails, and the expansion of environment variables for that purpose is also handled by Rails.

For example, the following database.yml works even on the latest trunk:

production: &sqlite
  adapter: sqlite3
  database: db/<%= ENV['DB_FILENAME'] %>

development: *sqlite

$ svn info
Path: .
Working Copy Root Path: /private/tmp/trunk
URL: https://svn.redmine.org/redmine/trunk
Relative URL: ^/trunk
Repository Root: https://svn.redmine.org/redmine
Repository UUID: e93f8b46-1217-0410-a6f0-8f06a7374b81
Revision: 23276
Node Kind: directory
Schedule: normal
Last Changed Author: maeda
Last Changed Rev: 23276
Last Changed Date: 2024-11-15 09:58:56 +0900 (Fri, 15 Nov 2024)

$ rm db/redmine.sqlite3
$ export DB_FILENAME=redmine.sqlite3
$ bin/rake db:migrate RAILS_ENV=production
== 1 Setup: migrating =========================================================
-- create_table("attachments", {:force=>true, :id=>:integer})
   -> 0.0004s
-- create_table("auth_sources", {:force=>true, :id=>:integer})
   -> 0.0002s
-- create_table("custom_fields", {:force=>true, :id=>:integer})
   -> 0.0002s
  .
  .
  .

$ bin/rails c -e production
Loading production environment (Rails 7.2.2)
redmine-app(prod)> User.first
=>
#<User:0x00000001117f5c30
 id: 1,
 login: "admin",
 hashed_password: "[FILTERED]",
  .
  .
  .

r23269 not only fixes the warning but also addresses an issue where Redmine may fail to start.

Using require to load a library in the Gemfile can cause not just warnings but also exceptions, potentially preventing Redmine from starting. For example, in an environment where both psych 5.2.0 and 5.1.2 are available, with psych 5.1.2 specified in Gemfile.lock, the following error may occur during Redmine startup.

r23269 has also resolved this issue.

$ bin/rails c -e production
WARN: Unresolved or ambiguous specs during Gem::Specification.reset:
      stringio (>= 0)
      Available/installed versions of this gem:
      - 3.1.2
      - 3.1.1
      - 3.0.4
WARN: Clearing out unresolved specs. Try 'gem cleanup <gem>'
Please report a bug if this causes problems.
/usr/local/lib/ruby/3.2.0/bundler/runtime.rb:304:in `check_for_activated_spec!': You have already activated psych 5.2.0, but your Gemfile requires psych 5.1.2. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)
    from /usr/local/lib/ruby/3.2.0/bundler/runtime.rb:25:in `block in setup'
    from /usr/local/lib/ruby/3.2.0/bundler/spec_set.rb:165:in `each'
    from /usr/local/lib/ruby/3.2.0/bundler/spec_set.rb:165:in `each'
    from /usr/local/lib/ruby/3.2.0/bundler/runtime.rb:24:in `map'
    from /usr/local/lib/ruby/3.2.0/bundler/runtime.rb:24:in `setup'
    from /usr/local/lib/ruby/3.2.0/bundler.rb:162:in `setup'
    from /usr/local/lib/ruby/3.2.0/bundler/setup.rb:10:in `block in <top (required)>'
    from /usr/local/lib/ruby/3.2.0/bundler/ui/shell.rb:159:in `with_level'
    from /usr/local/lib/ruby/3.2.0/bundler/ui/shell.rb:111:in `silence'
    from /usr/local/lib/ruby/3.2.0/bundler/setup.rb:10:in `<top (required)>'
    from <internal:/usr/local/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:86:in `require'
    from <internal:/usr/local/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:86:in `require'
    from /path/to/redmine/config/boot.rb:6:in `<top (required)>'
    from bin/rails:3:in `require_relative'
    from bin/rails:3:in `<main>'

You're right, sorry for that! It seems that the fail on my local environment was caused by something else. I've rerun some tests now and it looks fine.