Problem/Motivation
Switch to Gitlab CI per docs as recommended by Drupal.org.
Amongst other things, this is hoped to eliminate a test behaviour observed on DrupalCI as documented in #3390330: Failing test in module's existing coverage prevents unrelated patch submissions passing tests, which impedes landing other fixes.
#3390330: Failing test in module's existing coverage prevents unrelated patch submissions passing tests is why we see DrupalCI fail on 9.5 for this MR, while the GitlabCI pipeline passes.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork pathauto-3390491
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 #3
xurizaemonComment #4
xurizaemonComment #5
berdirThanks 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.
Comment #6
gregglesThanks for your work on this @xurizaemon.
#5 seems reasonable to me - moving to "needs work" for that.
Comment #7
xurizaemonHappy to follow up on that, probably over the next couple of days (weekend my time).
Comment #8
xurizaemonGreat, let's do that!
_TARGET_PHPto$CORE_PHP_MAX(or literal 8.2 if you prefer to specify).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)Comment #9
gregglesThanks for all that exploration and research!
Comment #10
xurizaemonThanks @greggles!
I've removed from #8 the notes on trying to get this set up for a Postgres run as well. I did get that working in the end:
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.
_TARGET_DB_TYPE=$POSTGRESQL_TARGET_DB_VERSION=14.1To 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_MAXfor_TARGET_DB_VERSION, but those values weren't matching the images over on Docker Hub (eg14.1to use drupalci/pgsql-14.1). So I switched to static values (eg "14.1") and that worked. There may be a better way to configure this for "test on the latest available postgres", but this worked for me. (Update: Per #3390706: PHP and Database available versions should match the supported versions, I wasn't alone in drawing that expectation.)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 due to the expectation in previous paragraph. :)
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).Comment #11
xurizaemonCorrection to above: I *did* get that configuration working. Laptop battery had me hit save without reviewing my comment.
Needs review now :)
Comment #13
berdirMerged. 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.
Comment #14
xurizaemonThanks!