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.I'm not sure whether to ask this here or in the DrupalCI issue queue, so sorry if I picked the wrong one.
My question is simply: are module maintainers discouraged from setting automated testing for all available environments to "Issues & on commit"?
I could imagine that, if all module maintainers (with test suites) did this, it would prove a significant burden on the infrastructure. On the other hand, there is nothing pointing this out in the form or the (spartanic) documentation. And, of course, always testing all environments would be handy for the few cases in which this actually catches some problem.
So, it would be great if someone could give a little background on that, and maybe add a short sentence regarding this to the config form.
Comments
Comment #2
drummWe haven't officially encouraged or discouraged this yet. We certainly would appreciate limiting testing to what has the highest impact/usefulness.
Contrib module tests usually run an order of magnitude or two faster than core, so they don't have a relatively huge impact. If they are queued long enough, they can trigger another test runner to be spun up, which is an AWS instance.
So far we've spent some time on Jenkins and the Drupal.org integration to keep costs limited. We haven't needed to restrict contrib projects yet. Keeping this open since we do need to keep this in mind, but don't have any specific needs right now.
Comment #3
drunken monkeyThanks for the reply, very good to know!
Then I guess I'll enable it for one or two other environments (those most different from the standard one) and keep alert for changes in this policy.
Comment #4
MixologicPretty sure this is now limited to only one environment for 'issue testing' with the ability to ad hoc add a test for additional environments as required.