[gitlab] Return early from scheduled gitlab jobs when there haven't been any recent commits

Created on 28 October 2023, 8 months ago
Updated 30 October 2023, 8 months ago

Problem/Motivation

Core has several scheduled pipelines, these run core tests against various PHP and Database versions. While parallel jobs allow each pipeline to finish in around 10 minutes, if you line the jobs up end to end, they'd take up to an hour or more (7 functional tests * five minutes each + all the other tests types + all the linting jobs etc.). If you then multiply that by two to four active Drupal core branches, and up to 10 environment combinations, that is somewhere between 20 hours and 40 hours of computing time every 24 hours.

Given we usually have more than one commit per day, it's better to have these scheduled jobs than to run every single environment on commit, however if there's no commits in a day, it's a complete waste to run the tests against the same commit hash as it was the previous day.

I don't know how many days per year pass without a core commit, my guess would be ~50 given the wide timezone spread of core committers. However, if we can make this work for core, we can also make it work for scheduled contrib tests (i.e. where they want to test an unchanged contrib code base against core branches that may or may not have changed). If we can apply it to both, it would save a lot of redundant test runs.

Steps to reproduce

Proposed resolution

There is a feature request for this, but as yet no sign of it being implemented.

Possible workarounds:
1. Can we write the commit hash to an artifact (variable would be better but don't think that's possible), check that against the git hash when we start the job, and bail if it matches?

2. Could we check git log --since "24 hours ago" and bail if it's empty?

3. Another idea would be to simply not run these at weekends when there's few commits, if we break HEAD we'd find out on Monday. Might be good to encourage committers to have a break at the weekend, although I'm right now writing this on Saturday morning.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

📌 Task
Status

Active

Version

11.0 🔥

Component
PHPUnit  →

Last updated about 10 hours ago

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @catch
  • 🇬🇧United Kingdom catch

    One other thing this would do would be to allow us to leave security-only core branches on daily schedule without worrying about the resource consumption too much. Currently on DrupalCI we manually move the security-only branches to on-commit, since they might only get one commit per month, then manually move them to no testing once they're EOL. If we implement this, we can set up a scheduled run for a branch when we open it, and leave it the same until the branch is EOL.

  • 🇬🇧United Kingdom catch
  • 🇨🇦Canada mgifford Ottawa, Ontario

    Thanks @catch

    I do like the idea of not running this on the weekend, but then again, not everyone shares the same idea for a weekend. I don't know enough abut the GitLab interaction to know if there's a way to check for commits.

    Maybe there would be folks from GitLab who might have ideas on their side about how to reduce their server usage.

    Does seem to be the kind of thing that should be part of a good aproach to ESG. https://about.gitlab.com/environmental-social-governance/

  • 🇬🇧United Kingdom catch

    I don't know enough abut the GitLab interaction to know if there's a way to check for commits.

    The gitlab pipeline lets us run arbitrary bash commands and do things dependent on the results. So although we can't stop a pipeline from starting without upstream features from gitlab, I'm sure we can exit early if we check git commit history ourselves, which would still save most of the computing time.

  • 🇺🇸United States moshe weitzman Boston, MA

    We already have arbitrary bash which doesnt even start a pipeline if false. This is keeps noise out of the UI. See https://git.drupalcode.org/project/gitlab_templates/-/blob/1.0.x/include...

Production build 0.69.0 2024