Since Jun 2023, Drupal.org enabled GitLab CI for testing purposes. GitLab CI is now preferred over DrupalCI for testing.
This issue is to track progress towards getting a .gitlab-ci.yml file so that we can migrate away from the deprecated DrupalCI to GitLab CI.
GitLab CI documentation: https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr...
Benefits:
1) Testing is about five times faster
@see: https://www.drupal.org/about/core/blog/drupal-cores-gitlab-ci-testing-is...
2) Ability to configure tests in a more obvious and flexible way.
3) Great UI!
No API changes.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
bohartMerge request !67 is adding
.gitlab-ci.ymlconfiguration file to have the same tests as their are now with DrupalCI here:https://www.drupal.org/node/3228223/qa
Comment #4
adamps commentedThanks.
Is there an article that explains the implications for maintainers/developers? What about issues that use a patch not a MR?
D9 has just 2 weeks left supported so maybe not worth adding??
Comment #5
dpi@AdamPS implications are it wont be available any more. So we have to update anyway.
Theres this linked off from the Automated testing tab on the project page: https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr...
To get started all you need to do is create a .gitlab-ci.yml file with this https://git.drupalcode.org/project/gitlab_templates/-/blob/1.0.x/gitlab-...
Thats the bare minimum.
Theres plenty of other use case examples off the above doc page.
Patches are not supported at all (see docs above). My understanding is as soon as Drupal CI is disabled (soon?) patches wont have any CI support.
Comment #6
dpiI'm not really sure if the contents of the attached MR are right: I have not verified the choices between default template and the customizations proposed. If you want a safe choice go with the default template from Gitlab templates project linked above.
Comment #7
bohartHere we're:
1) Patches.
Patches way is not supported at all with Gitlab CI.
Patches way will not be supported by drupal-org in the feasible future.
2) Implications.
There are no known implications for maintainers/developers.
This is a new way of running the same tests. Just quicker and has a nice UI.
3) Here is an example of how it looks like (another module with the same configuration as committed to MR) for another module:
https://git.drupalcode.org/project/reroute_email/-/pipelines/25947
4) Drupal 9.
a) The current MR fully replicates the same tests for GitlabCI as they are configured with DrupalCI for this module right now:
https://www.drupal.org/node/3228223/qa
b) My bet is better to switch to the totally same configuration first.
Then, we can remove Drupal 9 tests run at any moment later.
c) On another note, the currently available releases are marked `Works with Drupal: ^9.4 || ^10`.
I assume we should either add Drupal 9 tests (as the module release is supposed to support it) or remove Drupal 9 compatibility of the module (so we can safely remove Drupal 9 tests).
To summarize / my suggestion is:
Step 1 (now, this issue): replicate the current tests on GitlabCI from DrupalCI in exactly the same configuration (MR does this).
Step 2 (future): once we have a release of the module that is marked as not supported D9 (only D10), we will remove Drupal 9 tests run from GitlabCI.
Hope this clears all the topics above!
Comment #8
adamps commentedOK, thanks, I'm convinced we need to make this change. However maintaining this module is currently quite busy for me, so I'm keen to reduce work where possible. I don't really want to come back in 2 weeks and have to change this again. For all my modules I will switch to GitLab and remove D9 testing at the same time.
I don't plan to remove D9 from the info yml. If people want to continue using D9 when it's not supported then that's up to them. However I'm don't plan to test with an unsupported Drupal release.
So please remove D9 from this commit, and I'll remove D10 from DrupalCI. Then in 2 weeks I'll remove D9 from DrupalCI too.
Comment #9
bohartSounds reasonable, MR updated accordingly.
The pipeline has some warnings about PHPS, but all of them will be fixed at #3394193: Fix all PHPCS warnings and notices.
Thanks!
Comment #10
adamps commentedI'm confused - the D10 part has gone too. How will the PHP and Core versions be chosen?
Comment #11
bohartThe drupal10 has not gone.
The last pipeline run: https://git.drupalcode.org/issue/symfony_mailer-3393405/-/pipelines/31167
The job is called "phpunit": https://git.drupalcode.org/issue/symfony_mailer-3393405/-/jobs/176520
And here are its results: https://git.drupalcode.org/issue/symfony_mailer-3393405/-/pipelines/3116...
It runs the latest Drupal 10 core version + PHP8.
If no special params are specified (as it was previously to run two tests with different setups), the params to run phpunit are taken from a pre-defined template.
As the documentation recommends it:
https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr...
Hope that clarifies a thing!
Comment #12
adamps commentedGreat thanks for explaining