Activate GitLab CI

Looks like it gets hung up on the dev dependencies. I'll see if I can reproduce it.

Thanks for opening this issue! I wasn’t aware of this change, good to know.
Your test failure is unfortunately the same that has made issue fork testing impossible in this and several other modules for several years now: #3190024: Problem with test dependencies when testing issue forks → . As you see, unfortunately, there hasn’t really been any progress on this. Just one interesting clue, but nothing that showed us how to proceed.
Would of course be great if this move to GitLab CI could finally resolve this, but apparently it’s at least not automatic.

drunken monkey → closed merge request !81

I thought maybe just committing the .gitlab-ci.yml template file from your MR, Nick, would fix tests on GitLab, but unfortunately they still run into exactly the same problem as Drupal CI. The new MR I created with an attempt to fix this made the error message a bit prettier, but didn’t solve the problem, either.

As the problem is the circular dependency, moving the autocomplete test of the DB backend to the Autocomplete module → seems like it could work? However, to then ensure that changes to the DB backend don’t break its autocomplete functionality, we’d need to run the Autocomplete module’s test pipeline as well each time this module’s pipeline is run. Luckily, this seems possible using the downstream key in .gitlab-ci.yml. This is even explicitly suggested for ecosystem modules like this one → , so might be a good idea either way?

Since testing is still working fine for patches, I still think this has to have another solution, too. But as the d.o team is utterly unresponsive in this matter, the chances seem slim that this will get fixed on their end. And if Drupal CI will be phased out at some point, we will need to get this working before that. A smaller change as the fix would be preferrable, but if all else fails, moving the test case doesn’t seem so bad, either.

Finally, one thing we’ll need to figure out, once this is basically working, is how to get the same coverage for different Core versions, PHP versions and, especially, database systems that we currently have. I think copying our current setup (one pipeline run for every commit, two others weekly) as closely as possible would be ideal in terms of both coverage and resources. Ideally, it would also be possible to run the weekly pipelines manually on some MRs – namely, those that change the DB backend (to make sure it doesn’t break for one of the DBMSs) or deal with deprecated code (to make sure the module still works for all Core versions we support).

Any input would be very welcome!

I think I've fixed this here 📌 (Try to) fix the GitLab CI RTBC , even it's a workaround. Maybe we can close this?

I think this is still open and needs to be addressed:

Finally, one thing we’ll need to figure out, once this is basically working, is how to get the same coverage for different Core versions, PHP versions and, especially, database systems that we currently have. I think copying our current setup (one pipeline run for every commit, two others weekly) as closely as possible would be ideal in terms of both coverage and resources. Ideally, it would also be possible to run the weekly pipelines manually on some MRs – namely, those that change the DB backend (to make sure it doesn’t break for one of the DBMSs) or deal with deprecated code (to make sure the module still works for all Core versions we support).

I think this is still open and needs to be addressed

Yes, but as long as Drupal CI still works I would propose that we’re doing that in a follow-up

drunken monkey → closed merge request !88