Adopt GitlabCi

MR32 is my normal base template I'm using on various projects including s3fs, vault, and rabbitmq.

It uses the base drupal/gitlab_templates code, and expands it to run phpstan L9 for static code analysis and modifies the PHPCS stage to generate code coverage reporting in GitLab so that we can start ensuring new commits are actually tested.

I'll just leave these links here as a reference.

This is now my basic personal template for CI. Also with PHPStan and matrixes for multiple core/php.

I think the MR for this issue could be simplified a little. Particularly the PHPStan step. I do realize pcov adds complexity

• https://git.drupalcode.org/project/symfony_messenger/-/blob/1.0.x/.gitla...
• https://git.drupalcode.org/project/symfony_messenger/-/blob/1.0.x/.drupa...
• And the various metadata files composer.json deps / phpcs.xml / phpstan.neon

Would be good to get at least something basic committed, even if its the default template.

Thanks @dpi, I will give your templates a look. I haven't worked much with Matrix at this point, a lot of my project goals have been just to getting the basic in and work from there to match DrupalCi. Ideally I do want a min/max template design to be implemented instead of catching these faults on a 'weekly' scan as is currently done with DrupalCi for most modules.

"Particularly the PHPStan step"
Indeed, I wish PHPstan supported multiple loggers at once, it would make the setup more clear. Currently I have it outputting human readable to the logs (this matches the rest of the current gitlab_templates design), JUnit for failed tests reporting, and GitLab for code quality reporting so it can be viewed inline in MR's. This does add some bulk.

After that I do have a somewhat optional (though I find its very helpful) baseline generator job that can be used (with the local Gitlab runner) to generate a new baseline that will match the CI runs, though we certainly can take it out if we think its not useful.

Would be good to get at least something basic committed, even if its the default template.

Agreed, and we can technically commit even w/o a maintainer setting up the scheduled scans, though I would really like to have those configured as well so we can reduce the risk of chasing a mainline failure in MR's.

I was hoping to wait a while and have more code under my name in TFA to show for myself, however it might be reaching a point where I need to formally request a higher maintainer status. To my knowledge I am the only maintainer now that is actively working the D8+ branches.

Ideally I do want a min/max template design

This may be possible if you reuse the variables from the variables yaml in the matrix. there is a min/max in there. If it doesnt work somehow you could send a MR to this project to get vars set up so you can consume them.

Indeed, I wish PHPstan supported multiple loggers at once

Absolutely. For my templates I just used `tee` to output the log and pipe to gitlab code quality reports simultaneously. I think common strategy is to just run phpstan twice. The second run should reuse the disk cache so its not quite a hit to timing.

Somewhat related, my template also outputs codesniffer in code quality tab, if there are errors.

baseline generator job that can be used

Yeah this might be overkill but I'm keen to see if it could be useful as perhaps a further enhancement. I dont really have problems regenning these baselines locally. And of course if you're adding any kind of baseline you're going to run into different reported errors, and different error messages depending on PHP major/minor version. Sometimes I've considered running phpstan only on the latest PHP platform matrix, and ignoring it with env vars in gitlab `if`, if the problem becomes annoying. Though I find just fixing the problem is quicker.

This may be possible if you reuse the variables

then i recall this... https://git.drupalcode.org/project/symfony_messenger/-/blob/1.0.x/.gitla...

Thanks @dpi.

I think I'm going to merge this template as is (since it is one I'm familiar with) and can look at improving later, possibly after #3389921: New templates for contrib: mirror as much as possible all the GitlabCI jobs from core → since it may need an overhaul at that time.

I would have committed this sooner if I had realized I had the ability to schedule runs.

Doing a rebase it looks like for the PHPStan step we have 1 error that can't be basedline on 2.x and 2 that can not be baseline on 8.x-1.x branch. Both have that TfaTrustedBrowser::validateForm() is missing a return (it isn't actually called anywhere as far as I can tell) and 8.x-1.x catches one of our files that is intentionally used for older Drupal core versions. Since these will not fail the pipeline I rather defer both of these to followups so that we can start benefiting from GitlabCi.

Sometimes I've considered running PHPStan only on the latest PHP platform matrix, and ignoring it with env vars in gitlab

I'll admit sometimes I think this would be a good method, and other times I find myself making a simple mistake because of API differences and PHPStan would catch them if executed and I see it having merit even on non-current versions. I haven't found what I would call a perfect balance for PHPStan yet, however in time with use hopefully the reasonable solutions will become more apparent.

one I'm familiar with)

I find this is perfectly reasonable rationale when dealing with all this.

Thanks!

Merged to dev for 8.x-1.x and 2.x, set weekly test schedule on Gitlab, and disabled the on-commit DrupalCi testing.

We are now running on GitlabCi!

Automatically closed - issue fixed for 2 weeks with no activity.