Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.With #2268449: Run contrib module branch tests against both dev and latest stable core branches we now have custom tests for testing against a non-default core branch, like 8.0.x instead of 8.1.x, and for future one-off tests.
There should be a UI to add these recurring, while limiting each project to a reasonable number of tests. Testing spins up AWS boxes as-needed, each one has a small cost. We need to strike the right balance between flexibility and controlled costs.
| Comment | File | Size | Author |
|---|
Comments
Comment #2
drummThis issue will replace the table on projects’ automated testing pages with a larger list UI with more room for options to spread out and be explained. For each branch, we will limit “Issues & on commit” testing to a single environment.
Comment #3
catchOne point from #2680037: [policy, no patch] Figure out core branch testing needs for contrib modules. We should enforce a minimum version - so that when 8.0.0 support is dropped, any project still configured with it moves to 8.1.0 automatically.
Not sure we'll actually want to mark the 8.0.0 branch unsupported in the project UI though, or not quickly anyway, which would be the easiest way to automate something like that.
Comment #5
drummSo far I've gutted the edit UI from the projects’ automated testing tab. An example of the new UI is:
Now I need to build out the individual add/edit UI.
Comment #6
drummIn going over this with mixologic, we saw some potential in making use of core release labels somehow. One or two words for the targets at https://www.drupal.org/core/release-cycle-overview.
Something like “current development branch” could mean 8.1.x today, and 8.2.x when that opens up. Good labels for the others seem harder to come up with, especially when the beta/rc phase has one more possibility.
(There was some talk of doing something like this for core issues, so open issues don’t have to chase 8.x.x.)
Comment #7
catchI can't find the other discussion at the moment, but the proposal there was something like 8.x-PATCH and 8.x-MINOR.
That works exactly until you hit the current point where there are three branches. 8.2.x is already open and it'd be 8.x-NEXT-MINOR or something at the moment.
Running on the next minor before the current stable branch is done, at least for contrib tests, is the least important part of this though - there's hardly any divergence between 8.1.x and 8.2.x at the moment.
Don't think there's an actual issue for the labels, so opened one at #2691883: [policy, no patch] Branch labels for core.
Comment #9
drummI expanded the Add [custom] branch test UI to have a Schedule option and default core:
Until #2691883: [policy, no patch] Branch labels for core is further along, I think I'll stick to only putting in a “default” for core, and no additional labels. The schedule options now have more screen real estate to be explained.
And I've organized the environment options, similar to recent changes to the issue test UI:
Comment #14
drummI'll be deploying this shortly.