Problem/Motivation

Current CI runs for this project take 40+ minutes, even with jobs running in parallel. Due to this and the frequency of commits, the CI usage for this project is higher than usual.

While it includes the default templates, this project also invalidate all the jobs there and create new ones, which is totally fine.

However, all the jobs run, all the time, on every commit to the main branch and on every commit on MRs, regardless of the files changed.

The default templates have rules for whether to run a job or not based on the type of files being changed. For example, if only CSS files were changed, it doesn't make sense to run PHPCS nor PHPStan.

Steps to reproduce

https://git.drupalcode.org/project/varbase_project/-/pipelines/897916

Proposed resolution

- Avoid running certain jobs on MRs.
- Avoid running certain jobs if relevant files for them were not changed at all.


Action items:

  • 0- Manage with a .gitlab-ci-local.yml local runner (✅ Done that)
  • 1- The AI Agents seems to slip and keep posting jobs to the GitLab CI (not the local gitlab-ci runner) (✅ Done that)
    Adding a rule:
    # Use the local gitlab-ci-local runner .. and only commit ones when   
      all stages and all jobs passes with green to gitlab-ci in drupal      
      Update all local AI Agents which work with Drupal.org and                
      git.drupalcode.org 
    
  • 2- Make use of GitHub Actions to save on the load of GitLab Runners in git.drupalcode.org
  • 3- Manage to push for the full test on pre-releases, releases, post-release (Back to DEV)

Remaining tasks

  • ✅ File an issue about this project
  • ❌ Addition/Change/Update/Fix to this project
  • ❌ Testing to ensure no regression
  • ➖ Automated unit/functional testing coverage
  • ➖ Developer Documentation support on feature change/addition
  • ➖ User Guide Documentation support on feature change/addition
  • ➖ UX/UI designer responsibilities
  • ➖ Accessibility and Readability
  • ❌ Code review from 1 Varbase core team member
  • ❌ Full testing and approval
  • ❌ Credit contributors
  • ❌ Review with the product owner
  • ❌ Update Release Notes
  • ❌ Release

User interface changes

  • N/A

API changes

  • N/A

Data model changes

  • N/A

Release notes snippet

  • N/A

Comments

fjgarlin created an issue. See original summary.

rajab natshah’s picture

Thanks, Fran, for the notice.

Noted, your instructions are legitimate.

We recently switched from CircleCI to GitLab CI (still we need a lot to learn).

For sure, following your notes and tips.

- Avoid running certain jobs on MRs.
- Avoid running certain jobs if relevant files for them were not changed at all.

  • 0- Manage with a .gitlab-ci-local.yml local runner (✅ Done that)
  • 1- The AI Agents seems to slip and keep posting jobs to the GitLab CI (not the local gitlab-ci runner) (✅ Done that)
    Adding a rule:
    # Use the local gitlab-ci-local runner .. and only commit ones when   
      all stages and all jobs passes with green to gitlab-ci in drupal      
      Update all local AI Agents which work with Drupal.org and                
      git.drupalcode.org 
    
  • 2- Make use of GitHub Actions to save on the load of GitLab Runners in git.drupalcode.org
  • 3- Manage to push for the full test on pre-releases, releases, post-release (Back to DEV)
rajab natshah’s picture

Assigned: Unassigned » josebc
Status: Active » Needs review
rajab natshah’s picture

Assigned: josebc » omar alahmed
rajab natshah’s picture

rajab natshah’s picture

Assigned: mohammed j. razem » rajab natshah
Status: Needs review » Active

Back to taking active actions on this

rajab natshah’s picture

Issue summary: View changes
rajab natshah’s picture

Issue summary: View changes
rajab natshah’s picture

Issue summary: View changes
rajab natshah’s picture

## CI green-gate before pushing to git.drupalcode.org (added 2026-07-23)

Before committing to an issue-fork branch (GitLab Commits API) or pushing anything to git.drupalcode.org, run the project's full pipeline locally with **`gitlab-ci-local`** (`~/.local/bin/gitlab-ci-local`) and only push once **every stage and every job passes green**. A failing, errored, or masked job blocks the push — fix it first; never push a red pipeline. Keep every job `allow_failure: false`; never mask a command with `|| true`. Source of truth: `RULES.md`.
rajab natshah’s picture

Issue summary: View changes
rajab natshah’s picture

Issue summary: View changes
rajab natshah’s picture

Consulted with Jose on

- Avoid running certain jobs on MRs.
- Avoid running certain jobs if relevant files for them were not changed at all.

Following up to have better relevant tests.

rajab natshah’s picture

Issue summary: View changes