Drift detection consolidate-jobs ignores --filter when multiple caller jobs share a workflow run

[javier-ruiz-voxsmart]

Summary

When using per-account caller jobs in pipelines-drift-detection.yml (to stay under the 256 job limit), the consolidate-jobs CLI command downloads all drift-detection-unit-* artifacts from the workflow run, ignoring the --filter flag. This causes each account's consolidation to include drift results from all other accounts.

Reproduction

Caller workflow with per-account jobs:

jobs:
  GruntworkPipelinesVsmtDev:
    uses: .../pipelines-drift-detection.yml@v4
    with:
      pipelines_drift_detection_filter: "vsmt-dev/**"
      pipelines_drift_detection_branch: drift-detection-vsmt-dev

  GruntworkPipelinesVsmtPrd:
    uses: .../pipelines-drift-detection.yml@v4
    with:
      pipelines_drift_detection_filter: "vsmt-prd/**"
      pipelines_drift_detection_branch: drift-detection-vsmt-prd

  GruntworkPipelinesVsmtStg:
    uses: .../pipelines-drift-detection.yml@v4
    with:
      pipelines_drift_detection_filter: "vsmt-stg/**"
      pipelines_drift_detection_branch: drift-detection-vsmt-stg

Observed behavior

The Consolidate Jobs step for VsmtPrd reports vsmt-dev units in its output:

# VsmtPrd / Consolidate Jobs
pipelines_drift_detection_filter: vsmt-prd/**
"drifted_unit_count": 33,
"failed_unit_count": 61,
"units": {
    "vsmt-dev/_global/access-control-apply-role": { ... }   <-- WRONG: vsmt-dev unit in vsmt-prd consolidation
    "vsmt-dev/_global/access-control-plan-role": { ... }
    ...

Compare with VsmtDev which reports 26 drifted / 32 failed and VsmtStg which reports 26 drifted / 29 failed — while VsmtPrd reports 33/61 (the aggregate).

Root cause

GitHub Actions artifacts are scoped to the workflow run, not to individual caller jobs. All three callers upload artifacts named drift-detection-unit-{id} to the same namespace. The consolidate-jobs CLI downloads all artifacts matching drift-detection-unit-* via the GitHub API and doesn't filter them by the --filter value.

Why per-account jobs are needed

A single-job pattern would exceed the 256 job limit per workflow. Our repo has 329+ units across 3 accounts (84 dev + 91 stg + 154 prd), and this will grow as more accounts are enabled.

Suggested fixes

1. Namespace artifact names — Prefix artifacts with the filter or branch name (e.g., drift-detection-vsmt-dev-unit-{id}) so each caller's artifacts are isolated
2. Fix consolidate-jobs filtering — Have the CLI actually apply the --filter flag when selecting which downloaded artifacts to process
3. Document the limitation — If per-account caller jobs are not supported, document that the single-job pattern is required and recommend splitting into separate scheduled workflows to work around the 256 job limit

Environment

• pipelines CLI: v0.54.1
• pipelines-actions: v4.10.0
• pipelines-workflows: v4 (fae9d97)