run_a4ae1049ad7ab1ef

input

{
  "request": "Triage Jira ticket MZCLD-3822: Extract the rendered-manifest concatenation logic in diff-rendered-charts into a composite action",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3822"
  ],
  "sourceContext": {
    "issue": "MZCLD-3822"
  }
}

summary

MZCLD-3822 is a well-specified backlog tech-debt ticket about deduplicating rendered-manifest concatenation logic that currently exists in two places in .github/workflows/diff-rendered-charts.yml (diff_helm_charts and evaluate_helm_chart_automerge). No comments exist yet and no Confluence runbook is linked. Attempts to pull the two referenced sibling tickets (MZCLD-3821, MZCLD-3077) for cross-context were blocked by run-scope policy, so this triage relies only on the description text of MZCLD-3822 itself.

findings

• Ticket is in Backlog with zero comments — no prior triage discussion exists yet.
• The description is a self-contained design writeup: it identifies the duplicated concatenation logic, explains why the drift caused MZCLD-3821's xargs -r bug to be fixed in only one place, and lays out a real constraint (reusable workflow callers never check out this repo's helper scripts, only artifacts).
• Two concrete options are proposed with tradeoffs already analyzed by the reporter: (A) a new composite action under actions/concat-rendered-manifests/ referenced by both jobs (establishes a new actions/ directory pattern in this repo), or (B) do the concatenation once in render_charts and ship the per-config <config>.yaml inside the uploaded artifact so both downstream jobs just read it.
• Option B (upload the pre-concatenated file) has an open verification item: confirming no other consumer depends on the current shared-* artifact contents. The reporter already did a partial check (psa-checker reads a differently-named artifact) but flags this as needing confirmation before proceeding.
• Explicit sequencing dependency: this ticket should be done after MZCLD-3821 (the xargs -r bug fix) lands, to avoid fixing the bug twice and then deduplicating over it. MZCLD-3821 itself could not be read due to run-scope access policy, so its current status/completion is unverified from this session.
• This ticket is explicitly framed as a deliberate follow-up/deferred refactor from MZCLD-3077, which intentionally mirrored existing logic instead of refactoring in order to keep that earlier change small and reviewable. MZCLD-3077 could not be read due to run-scope access policy.

proposed actions

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3822"
    },
    "result": {
      "key": "MZCLD-3822",
      "summary": "Extract the rendered-manifest concatenation logic in diff-rendered-charts into a composite action",
      "status": "Backlog",
      "description_text": "Problem .github/workflows/diff-rendered-charts.yml  now concatenates rendered manifests per chart and per config in two places: diff_helm_charts , to build the multi-document YAML that dyff compares (added in MZCLD-3077) evaulate_helm_chart_automerge , to build the input that diffnest turns into JSON-patch for conftest Both do the same thing: enumerate config directories under  shared/{base,head}-charts/<chart>/ , then concatenate every file in each into a single  <config>.yaml . The two copies have already drifted, which is how the  xargs -r  bug in MZCLD-3821 ended up fixed on one side only. The duplication matters more than usual because the two consumers must agree. If the comment and the automerge verdict are ever computed from differently-assembled manifests, a PR could show a clean diff while conftest fails, or the reverse. Constraint The obvious fix, a shell script in this repo, does not work as-is. Consumers call this workflow via  uses: , and neither job checks out  deploy-actions  \u2014  diff_helm_charts  only downloads artifacts. A helper script committed here would not be present on the runner. Options: A composite action in this repo  (for example  actions/concat-rendered-manifests/ ), referenced by both jobs. Reusable workflows can reference actions from their own repository, so this resolves without an extra checkout. There is no  actions/  directory yet, so this establishes the pattern. Do the concatenation once in  render_charts  and include the per-config  <config>.yaml  alongside the rendered tree in the uploaded artifact, so both downstream jobs just read it. Removes the duplication entirely and saves repeated work, but changes artifact contents. Worth confirming nothing else consumes the  shared-*  artifacts first;  psa-checker  reads  k8s-manifests-*  from a different workflow, so it looks unaffected. The second is cleaner if the artifact change is safe, since it makes it structurally impossible for the two consumers to disagree. Notes Follow-up from MZCLD-3077, which intentionally mirrored the existing loop rather than refactoring, to keep that change reviewable and avoid touching the automerge path. Should be sequenced after MZCLD-3821 so the fix is not applied twice and then deduplicated.",
      "comment_count": 0,
      "comments": []
    }
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3821"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-3821"
      }
    },
    "blocked": true
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3077"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-3077"
      }
    },
    "blocked": true
  }
]

log