Skip to content

Conversation

@chadlwilson
Copy link
Contributor

@chadlwilson chadlwilson commented Aug 23, 2025

  • Generated new Rails dummy apps from scratch for all versions we currently test
  • Lifted all of the current initialization tests into the shared examples to run for all Rails
  • Added back the chunked rack monkey-patch test that was there for the earlier rails 4.0 era stubs
  • Added some gitignores to try and make it easier to generate and add new minimal stub Rails applications
  • Added a test that will fail if we forget to add new stub tests that actually boot/initialize Rails for a new version

Looks like

rails 8.0
    it should behave like a rails app
      runtime
        initializes pooling when min/max set
        initializes shared (thread-safe) by default
        initializes shared (thread-safe) whem max runtimes is 1
      initialized
        loaded rack ~> 2.2.0
        booted with a servlet logger
        sets up public_path
        disables rack's chunked support (by default)

Open question

  • the LoggerSilence stuff doesn't work on Rails 5.0/5.2 as it doesn't exist there. Should we just drop testing these EOL versions or keep my small change here that makes it apply only to Rails 6.0 onwards?
    • Decided to drop support for Rails 5.0/5.2 and also not test Rails 6.0 now given it's 27 months past EOL.

…tub-tests

# Conflicts:
#	src/spec/ruby/jruby/rack/integration_spec.rb
@chadlwilson chadlwilson force-pushed the reinstate-rails-stub-tests branch from a379abc to e08d076 Compare August 24, 2025 07:57
@chadlwilson chadlwilson changed the title Reinstate Rails integration test stubs for remaining versions Reinstate Rails integration test stubs for Rails 5.0 -> 7.1 & 8.0 Aug 24, 2025
@chadlwilson chadlwilson requested a review from kares August 24, 2025 08:00
@olleolleolle
Copy link
Member

olleolleolle commented Aug 26, 2025

Should we just drop testing these EOL Rails versions or keep my small change here that makes it apply only to Rails 6.0 onwards?

@chadlwilson My take - drop those Rails versions. Even Rails 6.0 is very EOL.

Source: https://endoflife.date/rails

@chadlwilson
Copy link
Contributor Author

@olleolleolle thanks for the opinion! Yeah, they are very EOL. I kept them earlier partly because Rails' support policy is quite aggressive, partly because this lib itself was dormant for many years and had issues on Rails 6 in some configurations (with java servlet session store) and to make it easier to reinstate these stub tests so the distance would be smaller between the last version that was actively integration tested here (rails 4.0). But that's largely moot now with this PR since it covers at least framework initialization through to Rails 8.

The only thing that is vaguely of concern is that there are probably some jruby-rack features that are not working properly on modern rails/rack and may also benefit from being able to validate they work incrementally over Rails versions. For example, I think forward_to is not working for some reason as I discovered only yesterday (don't use it myself).

Having said that, the Rails 5 tests could live on for the 1.2.x branch for a while since they work fine there.

The logger changes on master right now only actually work on 6.0 onwards. 6.0 has been EOL for 27 months now so seems reasonable to remove. 6.1 has been EOL for 11 months, but given the rails EOL policy is pretty aggressive and there are not many special changes to handle Rails 6.1 vs 7.0 it seems reasonable to keep it for now.
@chadlwilson chadlwilson changed the title Reinstate Rails integration test stubs for Rails 5.0 -> 7.1 & 8.0 Reinstate Rails integration test stubs for Rails 6.1, 7.0, 7.1 & 8.0 Aug 30, 2025
@chadlwilson chadlwilson merged commit 956187e into jruby:master Aug 30, 2025
26 checks passed
@chadlwilson chadlwilson deleted the reinstate-rails-stub-tests branch August 30, 2025 10:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants