Problem/Motivation
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/about/core/blog/drupal-cores-gitlab-ci-testing-is...
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!
4) While we don't have tests in the module, we would still benefit from automated code style checks.
Issue fork field_tools-3469906
Show commands
Start 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:
Comments
Comment #2
andrii momotov commentedI assigned the task myself because I plan to fix this issue and make a Merge Request.
Please do not work on this issue.
Comment #4
andrii momotov commentedSet up GitLab CI. Please review MR. Thanks!
Comment #5
joachim commentedDo we actually need this? AFAIK we just enable testing in the project node settings.
Comment #6
grevil commentedTests definied through the "Automated testing" use DrupalCI, which is deprecated. The prefered way to do testing is through the new(ish) gitlab-ci pipeline! https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr...
Tests won't run on the main module page anymore without a .gitlab-ci.yml.
EDIT: Just realised, that this module doesn't have tests, so I agree, that this isn't needed necessarily.
Comment #7
konot commentedAlthough this module currently has no tests, adding a minimal GitLab CI setup is still relevant and aligns with the current Drupal contribution workflow, as DrupalCI is deprecated. The goal is not to enforce tests, but to establish a basic quality gate and future-proof the project.
Running basic checks already revealed concrete issues: PHPCS reports 503 violations, of which 419 can be fixed automatically (per PHPCBF), and PHPStan reports 144 findings. This demonstrates immediate practical value even without tests. If no tests exist, PHPUnit jobs simply won’t run, so there is no added complexity or maintenance overhead.
I can provide and fully integrate the GitLab CI configuration and address the reported issues in separate follow-up tickets. No assistance is required from maintainers - I only need a green light to proceed. @joachim, what do you think?
Comment #8
joachim commentedYup, sounds like a good plan. We can add PHPUnit tests in the future.
For PHPCS some filtering will be required, as it complains about commented-out code (of which I'm sure there is lots) and gaps between comment blocks (which are intentional).
Comment #9
konot commentedI would add & test the GitLab CI for this project with necessary lints coverage. The issues reported by lints would be covered on separate tickets in order to avoid making 1 MR for all-problems-fixing (it seems to be very big).
Thanks, @joachim, for replying.
Comment #10
konot commentedI have finished working with Gitlab CI for the module.
Unfortunetelly, there is an issue with the `composer (previous minor)` lint. However it is not the problem of the module's CI - the pipeline starts wrong Drupal version. It should run the pipeline with Drupal 11.2.10 as specified in gitlab_templates repository, I assume it would be fixed after some time by itself, when the correct hiden variables would be used.
Other errors/warnings should be resolved in appropriate issues. I have started with:
1. PHPCS: ,automatically resolved #3565134; manually resolved #3565138.
2. PHPStan: #3565139
3. CSpell & StyleLint: #3565141
I am looking for the review of proposed solutions; let me know if changes should be done. Thanks!
Comment #12
andrii momotov commentedThe MR has been merged. Thank you for your work.