run_88c6817cc2544638

input

{
  "request": "Triage Jira ticket MZCLD-3650: Add support for deployment.spec.revisionHistoryLimit in MozCloud Helm charts",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3650"
  ],
  "sourceContext": {
    "issue": "MZCLD-3650"
  }
}

summary

MZCLD-3650 is a low-priority, well-scoped feature request to add Helm chart support for setting `spec.revisionHistoryLimit` per Deployment in MozCloud charts. It originated from parity work during the llm-proxy migration (MZCLD-2331), where llm-proxy explicitly sets this field to 3 vs. the MozCloud chart default of 10 with no override currently available. The change is cosmetic (affects ReplicaSet retention only, no functional/runtime impact) and has a clear, testable acceptance criterion. Ticket currently has no comments and is sitting in Backlog. Recommend confirming scope/chart ownership and prioritizing as a small, low-risk enhancement, and note that the referenced MZCLD-2331 ticket could not be pulled for additional context due to access restrictions.

findings

• Request is a small Helm chart enhancement: expose revisionHistoryLimit as a configurable per-deployment value in the values schema and Deployment template.
• Change is explicitly flagged as cosmetic/low priority - affects only ReplicaSet history retention, not application behavior.
• Originated from a concrete migration parity gap: llm-proxy sets revisionHistoryLimit=3 on both its Deployments, but the MozCloud chart hardcodes/defaults to 10 with no override mechanism.
• Ticket has no comments and is unassigned/untriaged (status: Backlog), so no prior discussion of implementation approach exists yet.
• Could not retrieve the linked context ticket MZCLD-2331 to confirm whether other similar parity gaps were identified in the same migration that might be batched with this work; access to that ticket was blocked by policy.

proposed actions

Triage note: This is a small, low-risk Helm chart enhancement to expose `revisionHistoryLimit` as a per-deployment override in the MozCloud chart values (currently hardcoded/defaulted to 10, no override path). It was surfaced for parity during the llm-proxy migration (MZCLD-2331), where llm-proxy explicitly needs a value of 3. Impact is cosmetic (ReplicaSet history retention only) with no functional/runtime risk, and the acceptance criteria are clear and testable (value flows through to the rendered Deployment spec). Recommend: (1) confirming chart ownership/repo, (2) adding `revisionHistoryLimit` to the values schema with the current default (10) preserved for backward compatibility, (3) adding a template test/snapshot to verify the override renders correctly, and (4) linking back to MZCLD-2331 for traceability. Given low complexity and no functional risk, this looks suitable for a 'good first issue' or quick-win backlog item; suggest prioritizing in the next chart maintenance pass rather than urgent triage.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3650"
    },
    "result": {
      "key": "MZCLD-3650",
      "summary": "Add support for deployment.spec.revisionHistoryLimit in MozCloud Helm charts",
      "status": "Backlog",
      "description_text": "Context:  Surfaced during the  llm-proxy  mozcloud migration (MZCLD-2331). Low priority / cosmetic. Problem.  Deployments cannot set  spec.revisionHistoryLimit . Both  llm-proxy  Deployments set it to  3 ; the mozcloud default is  10  with no override. Purely cosmetic (ReplicaSet retention) but needed for exact parity. Ask.  Allow setting  revisionHistoryLimit  per deployment. Acceptance criteria.   revisionHistoryLimit  is configurable per deployment and appears in the rendered Deployment spec.",
      "comment_count": 0,
      "comments": []
    }
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-2331"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-2331"
      }
    },
    "blocked": true
  }
]

log