Therefor I’d like to also deprecate Ruby 2.5 support in Foreman altogether, and remove it in 3.4.
This would mean less time spent in CI (at least as long we don’t add Ruby 3.0 in the future), and fewer obscure Ruby bugs (like https://bugs.ruby-lang.org/issues/14373).
The only downside that I could see is that this would mean we’d need to bump the “start” version of our upgrade tests. They currently start at Foreman 1.21 with Ruby 2.5, but I am not sure that version supports 2.7 too. Foreman 2.5 certainly does, as that’s the version we switched to 2.7 by default on EL7 and introduced Ubuntu 20.04 Focal.
I have opened a PR against the 3.3 release notes to express this:
I was looking at turning the Foreman PR jobs into Jenkins pipelines when I remembered this thread and went back to read it as I want to convert only what is necessary. That got me to the question of: what does the test_develop_pr_upgrade job actually do and does it still provide value enough to convert it?
The text comment in the job says:
“# The idea is to test that older DB migrations don’t break when models are changed.”
I got to wondering if this is really a problem anymore and if this job would truly catch all instances of this compared to our actual upgrade pipelines. I am not aware of any other code base running such a test on PRs.
The goal of the upgrade job is to test the DB data migrations. The problem with this job is that it actually has very little data (just what db:seed creates) so it has limited coverage.
In the past we’ve bumped the lower version bound we upgrade from, but another solution may be to have some stored database dumps with non-trivial data and migrate those. That would be more likely to show issues.
The test_develop_pr_upgrade job has been dropped from PRs. For any existing PRs, if they are rebased this job will not show up as ran. If the job has a failing upgrade test, running [test upgrade] will not trigger anything and for all intents and purposes any failures of the upgrade job can be ignored.
