Problem/Motivation

DrupalCi currently comes with a tab on project pages allowing you to define which environments tests will run for on branch commit, and the issue testing default. You can also set frequency to on commit or daily.

We won't have that UI for gitlab. I don't know what the scheduler looks like for triggering pipelines outside of commits, however we also have more direct control over the pipeline YAML

Steps to reproduce

Proposed resolution

https://docs.gitlab.com/ee/ci/jobs/job_control.html allows us to run different things depending on branch name and other conditions, this could include:

1. Automatically triggering jobs for different environment combinations on commits to the 11.x/10.1.x branches, leaving them as manual on MRs.

2. Running a full cspell analysis on branch tests, whereas MRs run it on affected files only. Ideally we'd also trigger a full cspell run on composer changes in case cspell itself gets updated too.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Issue fork drupal-3386680

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:

About issue forks

Comments

catch created an issue. See original summary.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Title: [PP-1] Run some different jobs on gitlab CI branch tests » Run jobs on GitLab CI branch tests

The initial GitLab CI commit only enabled pipelines for MRs, so repurposing this issue to add pipelines on push and also manually via the web UI.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Active » Needs review

Added three extra triggers to the default PHP 8.2/MySQL 8 job:

  • push for branch pushes
  • schedule so we can replicate DrupalCI scheduled pipelines
  • web so maintainers can manually trigger runs if needed

longwave opened merge request !4763

fjgarlin’s picture

fjgarlin commented
Status: Needs review » Reviewed & tested by the community

The MR changes look good to me. It's targeting just the "project" namespace for other manual (web), schedule or push, which makes sense as we don't want/need that in forks.

RTBC.

  • catch committed b917fae1 on 11.x 
    Issue #3386680 by longwave, fjgarlin: Run jobs on GitLab CI branch tests
catch’s picture

catch
he/him
Primary language English
commented
Status: Reviewed & tested by the community » Active

Committed/pushed to 11.x, leaving this open for more branch test fun.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Active » Needs review

CI_MERGE_REQUEST_TARGET_BRANCH_NAME is only set for MRs; CI_COMMIT_BRANCH is only set for branch pushes, so we can concatenate the variables and get the correct value where we need it.

The cspell job tries to look for the set of modified files, which doesn't make sense in a branch run, so we need to figure out what we should do here - a full run of cspell?

  • catch committed 1fa798ac on 11.x 
    Issue #3386680 by longwave, fjgarlin: Run jobs on GitLab CI branch tests

  • catch committed ce444178 on 10.1.x 
    Issue #3386680 by longwave, fjgarlin: Run jobs on GitLab CI branch tests...

  • catch committed 4f4dbbde on 10.1.x 
    Issue #3386680 by longwave, fjgarlin: Run jobs on GitLab CI branch tests...
longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Needs review » Fixed
Parent issue: » #3387107: [meta] GitLab CI feature parity with DrupalCI

Think this can be marked as fixed now and matrix jobs and cspell have their own individual followups.

Status: Fixed » Closed (fixed)

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