Adopt GitLab CI

This is on my wishlist for the next version, tagging as such

Thanks for MR, can you please check my comments.
Do you know why phpunit tests are failled?
Is there an issue to fix it?

I am still working on getting pipelines to go green, so I would say it's a bit premature to start providing feedback already :)

I thought that MR is ready for review, because issue had status "Needs review".

Yeah that was just so the testbot would run, issue is green now will look at your comments and adjust where needed.

Changed MR to target 2.3.x

Okay we now have a phpstan baseline of 52 entries, most of them due to poor typehinting, I find that acceptable. We can work on that later on. Will merge and then try to get the same running for 3.3.x

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

Sorry, I totally missed this since it was only committed to 3.3.x and not backported at all. I opened 📌 Add .gitlab-ci.yml file for automated MR testing Active .

@kristiaanvandeneynde: Mind if I cherry-pick this to earlier branches so that we can have automated testing working on anything we backport, too?

Thanks!
-Derek

It was backported to 2.3.x, which is the new minor version alongside 3.3.x. MRs should be made against the latest branch, which has GitLab CI now.

I'm a bit on the fence about backporting this further because once 3.3.0 and 2.3.0 are out, previous minor versions will no longer receive patch updates. I'm following the core release cycle on that matter. Every commit I make I already have to transliterate to 2.3.x compatible code, I'm not sure if I want to go through the trouble of then also backporting that to 2.2.x/3.2.x etc.

Thanks for your response, and sorry for opening the duplicate issue.

I'm a bit on the fence about backporting this further because once 3.3.0 and 2.3.0 are out, previous minor versions will no longer receive patch updates.

But those releases are not out. There's not even an alpha, much less an RC or a stable. No expectations, hurry, or judgement, only stating the current situation. Meanwhile, the stable release series will continue to have bug fixes. You might even need to do a security release. So it'd be good to have automated test coverage of those branches so you know if they're in a state that could be released whenever necessary or desired.

I'm following the core release cycle on that matter.

Core has exactly this situation. Every change is currently MR'ed against the 11.x branch. If it's a bug fix or non-disruptive task (e.g. test improvements, etc), it gets cherry-pick'ed to the 10.2.x branch since that's the current stable release. We just got to the point where they also branched 10.3.x so 11.x becomes truly 11.x code, and everything (even new features) are cherry-picked to 10.3.x and bug fixes are cherry-picked to 10.2.x.

Meanwhile, right now, Core still has 10.1.x as a supported "previous minor" release series for security coverage. Per https://www.drupal.org/project/drupal →

These are stable, well-tested versions that are actively supported.
Drupal core 10.2.4
Released Mar 06 2024
Actively maintained with new features and backwards-compatible improvements every six months. . Use this version for the best compatibility with future releases.

Drupal core 10.1.8
Released Jan 17 2024
Drupal 10.1.x will receive security coverage until June 2024 when Drupal 10.3.0 is released.

So technically, if you're planning to follow the core release cycle, we should be claiming that Group 3.1.x is still a supported release that could get a security update if needed, in which case we'd want to backport .gitlab-ci.yml at least that far.

Every commit I make I already have to transliterate to 2.3.x compatible code, I'm not sure if I want to go through the trouble of then also backporting that to 2.2.x/3.2.x etc.

I truly appreciate that pain. A few things that could help:

1. I'm only talking about bug fixes and non-disruptive tasks, not every issue.
2. I'm only talking about backporting fixes until the N+1.0 stable release is out (in this case, 3.3.0).
3. I'm willing to help. 😅 That's basically why I'm here as a co-maintainer, to help you with backporting where appropriate. We could make more use of the "to be ported" status and assigning issues to me. Basically, when you're done with the mainline and push the commit, if it doesn't cleanly cherry-pick to the earlier branch, you could assign to me and leave the issue open. I don't promise I'll deal with every one, but I'd be happy to take a look and try to offload some of that trouble and effort. If I don't have time and you don't want to bother, we can always do what we do now and close it as a 3.3.x-only fix. Only "harm" is the issue was open in the queue for another month or whatever. Maybe other people will show up to help in the meanwhile, and the backport MR will be all green and happy when I have a chance to look at it.

So my previous offer still stands: mind if I cherry-pick the .gitlab-ci.yml commit (9e597c473) to at least 3.2.x if not also 3.1.x branches, just to make sure things are still working back there in case we need it? Ditto any follow-up cspell, etc tasks / fixes? I promise to be careful. I just tried it and it's a clean cherry-pick for 3.2.x, but a few conflicts for 3.1.x:

	both modified:   src/Access/GroupPermissionsHashGenerator.php
	both modified:   tests/src/Functional/GroupCreatorWizardTest.php
	deleted by us:   tests/src/Kernel/GroupPermissionsHashGeneratorTest.php

I could open a new MR here for 3.1.x if you'd like.

What do you think?

Thanks again!
-Derek

p.s. Oh yeah, and technically we still call the 8.x-1.6 release supported, so we also "need" the .gitlab-ci.yml file all the way back there, too. 😂 Again, I'm willing to deal with that. Perhaps easier to just open new child issues for these backports at this point.

Okay, so fat chance in hell we're backporting all that to 8.x-1.x :D

You did convince me that, for the time being, we could backport this to 2.2.x and 3.2.x. I wouldn't go as far as backporting to x.1.x as I made no promises similar to core about extended security coverage. I'm still of the opinion that updating to the newest minor should be seamless (no BC breaks) and you therefore should at most be on the previous minor.

3.3.0 is currently in the works and once I've worked my way through https://www.drupal.org/project/issues/search/group?project_issue_followe... → + added the new D10.2 stuff (like Attributes) it will be released.

Oh and please create a new ticket, I don't like re-opening closed tickets.