Levandor

First devel-merge makes a partner branch inherit devel's full CI pipeline

3 min read

Legacy partner customization branches ran a single CI job. The first devel → customization/<partner> merge after devel’s workflow change swaps in devel’s six-job pipeline, so four jobs run on that branch for the very first time — surfacing years of latent breakage in one PR. This is systemic and will recur on every partner branch that has not yet taken a devel merge.

Budget for this before starting a partner devel-update

The red CI on a first-devel-merge PR is mostly pre-existing partner breakage newly enforced, not breakage your merge introduced. Triage each failure by origin (git log the offending line) before assuming the merge caused it.

The pipeline delta

Workflow blobJobs
Legacy partner branch (e.g. customization/cofidis)ec0a1244lint-and-build
Current develdda79403lint / test / audit / depcheck / sonar / build

Both live at .github/workflows/pull-request.yaml. The merge brings devel’s version onto the partner branch, so test, audit, depcheck and sonar execute against partner code for the first time ever.

Evidence — Cofidis, 2026-07-20

The FKITDEV-9059 merge (vuer_css #3100, vuer_oss #8040) produced 5 distinct failure clusters. Only 2 were merge-introduced; the rest dated back to 2017–2024. Full per-failure inventory with root causes and fix sides is in FKITDEV-9059.

Two structural amplifiers

These are architectural constraints of the repos, not cofidis quirks — they apply to every partner branch.

1. Partners fork core source files in place

There is no override layer for server-side service classes. A partner that needs different behaviour edits the core file directly — e.g. cofidis edits server/service/FlowLiveUpdateService.js in place. The forked file then violates the core unit test, which still asserts the upstream behaviour. See breakage-risks for the per-file fork census.

2. No customization-aware unit-test layer

jest.config-unit.js matches only test/tests/unit/**. There is no per-partner test directory. Consequences:

  • A partner-specific test failure can only be fixed by diverging a shared core test file.
  • That divergence then conflicts on every subsequent devel merge.

This is a recurring tax, not a one-off cost — each partner branch accumulates its own set of divergent core tests that must be re-reconciled on every sync.

For Agents

When picking up the next Devel update ticket for a partner:

  1. Check whether the partner branch still carries the legacy single-job workflow (lint-and-build). If yes, expect the four-job expansion.
  2. Expect the same 5 clusters to be candidates: dead-code require() after a core .js→.ts rename, stale eslint-disable directives, forked-core-file vs core-unit-test mismatches, partner-only .trans.js keys returning undefined, and the request/form-data audit CVE (cve-2025-7783-form-data-via-request).
  3. Classify every failure as merge-introduced vs pre-existing before proposing a fix — the fix side (partner vs core test) depends on it.

Graph View

Backlinks