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

Command icon 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

xurizaemon created an issue. See original summary.

xurizaemon’s picture

Status: Active » Needs review
xurizaemon’s picture

Issue summary: View changes
berdir’s picture

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.

greggles’s picture

Status: Needs review » Needs work

Thanks for your work on this @xurizaemon.

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

xurizaemon’s picture

Assigned: Unassigned » xurizaemon

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

xurizaemon’s picture

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)
greggles’s picture

Thanks for all that exploration and research!

xurizaemon’s picture

Thanks @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.

  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). 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).

xurizaemon’s picture

Status: Needs work » Needs review

Correction to above: I *did* get that configuration working. Laptop battery had me hit save without reviewing my comment.

Needs review now :)

berdir’s picture

Status: Needs review » Fixed

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.

xurizaemon’s picture

Assigned: xurizaemon » Unassigned

Thanks!

Status: Fixed » Closed (fixed)

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