Switch to Gitlab CI

Thanks for starting this.

FWIW, this also (only) runs against 10.1, so it's not surprising this is passing (it's great that it does out of the box though).

Based on the docs and so on, I don't quite get yet how you'd then set up something similar to https://www.drupal.org/node/17345/qa → . I don't need all the variations, but what I think would be nice is a weekly run on PHP 8.2 and PostgreSQL additionally to the default. I guess that's where scheduling and custom variables come into play.

I also don't see yet how I'd manually add a pipeline with different variables. Something like that is useful when you add look into test fails/compatibility issues with a new core minor or major version for example, or want to verify that a MR that changes database querie still works against PostgreSQL.

As mentioned in the other issue. I'm OK with dropping D9, but I guess we could try to set up another scheduled run for that for now.

Thanks for your work on this @xurizaemon.

#5 seems reasonable to me - moving to "needs work" for that.

Happy to follow up on that, probably over the next couple of days (weekend my time).

Based on the docs and so on, I don't quite get yet how you'd then set up something similar to https://www.drupal.org/node/17345/qa → . I don't need all the variations, but what I think would be nice is a weekly run on PHP 8.2 and PostgreSQL additionally to the default. I guess that's where scheduling and custom variables come into play.

Great, let's do that!

1. Visit https://git.drupalcode.org/project/pathauto/-/pipeline_schedules once this MR is landed
2. Click "New schedule"
3. Set the schedule to "Every week" (or use crontab format - but I think Gitlab may be helpful here with its timing recommendation ... IDK)
4. Refer to https://git.drupalcode.org/project/gitlab_templates/-/blob/1.0.x/include... for variable definitions and names for the following
5. Set a variable named _TARGET_PHP to $CORE_PHP_MAX (or literal 8.2 if you prefer to specify).
6. Press save, and then click the ▶️ start button on that schedule to fire a test run
7. A pipeline will start; you can click into that pipeline and inspect the version of PHP from the "composer" job; it appears at the top of the output, eg Using Kubernetes executor with image drupalci/php-8.2-apache:production ... on line 7 shows we're using PHP 8.2 here (ref example pipeline, job)

Repeat changing step 5 to use _TARGET_DB_TYPE = $POSTGRESQL for a weekly Postgres test run. To confirm which DB service starts, we'll inspect the "phpunit" job and check which image is pulled for the DB service at job start.

Well ... that second part ought to work. What actually happened was that the phpunit job failed to pull the images for Postgres (and MySQL when I tried that). I expect this approach to be valid and I think that failure will have been a temporary glitch on our Gitlab CI.

I wish you better luck when you try it :)

Thanks for all that exploration and research!

Thanks @greggles!

I've removed from #8 the notes on trying to get this set up for a Postgres run as well. I didn't yet find a working solution for that. Here's what I tried:

Scheduled pipeline for testing with Postgres

For a weekly Postgres test run, repeat instructions from #8 above, changing step 5 to assign two variables below.

1. _TARGET_DB_TYPE = $POSTGRESQL
2. _TARGET_DB_VERSION = 14.1

To confirm which DB service starts, we'll then inspect the "phpunit" job and check which image is pulled for the DB service at job start.

At first I thought it should be possible to use a variable such as $CORE_PGSQL_MAX for _TARGET_DB_VERSION, but those values weren't matching the images over on Docker Hub (eg 14.1 to use drupalci/pgsql-14.1). There may be a better way to configure this for "test on the latest available postgres", but this worked for me.

I also ran into some issues pulling Docker images, which was I think in part rate limiting of image pulls from Docker hub ((thread in Slack #gitlab) as well as me coming up with incorrect image names on some tries :)

Example pipelines

I tested this on AdvancedForm module (something with few tests I had sufficient access to experiment with). Here are example pipelines for that project on Postgres 14.1 (_TARGET_DB_TYPE=$POSTGRESQL, _TARGET_DB_VERSION=14.1), MySQL 8 (_TARGET_DB_TYPE=$MYSQL_PERCONA_MARIADB, _TARGET_DB_VERSION=8), and PHP 8.2 (_TARGET_PHP=$CORE_PHP_MAX).

Correction to above: I *did* get that configuration working.

Needs review now :)

Merged. Will let it run a bit side by side to see how it's behaving but start to switch over scheduled configurations and so on.

Thanks!

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