tool calls
[
{
"capability": "jira.issue.read",
"args": {
"key": "MZCLD-3823"
},
"result": {
"key": "MZCLD-3823",
"summary": "Determine how the Helm diff workflow should learn a chart's release name",
"status": "Backlog",
"description_text": "Problem diff-rendered-charts.yml renders charts under their directory name, which is what Argo CD uses by default. A chart whose tenant config sets release_name is therefore rendered under a name production never uses. This is invisible for ordinary chart changes: a consistent but wrong release name still produces a correct diff, because both sides get the same names. It breaks when one side derives resource names from the release name and the other does not, which is exactly a migration to the mozcloud charts. There, every resource appears as both added and removed, which is the noise MZCLD-3077 exists to eliminate. The migration pattern makes this sharper rather than incidental. Migrated charts deliberately name resources with the release name baked in so that existing resources are adopted rather than recreated. Bugzilla is a good example: its mozcloud values name resources gha-bugzilla , gha-bugzilla-log4perl , gha-bugzilla-cron-* and so on, matching the gha release. So the migrated side of a diff encodes the real release name explicitly, while the pre-migration side derives it from whatever release name the workflow happened to pass. The workflow therefore has to know the real release name for a migration diff to line up at all. Roughly 50 chart/environment combinations across about 30 tenants are affected: pattern examples shared gha release sumo, fxa, nucleus, bugzilla, ctms, dap versioned suffixes treeherder to treeherder-v2 , pontoon to pontoon-v1 prefixed variants common-voice: audio to gha-audio , bundler to gha-bundler per-environment outgoing to outgoing-stage and outgoing-prod renamed youtube-test to yttest Constraint The authoritative values live in global-platform-admin/tenants/*.yaml , resolved by applicationsets.yaml:119 as per-environment override, then chart-level override, then chart directory name. The diff workflow runs in the tenant repo and cannot see them. Nothing in a chart's directory records the release name today; the generated .argocd-source-*.yaml files carry only image parameters. What we need to decide How the workflow should obtain the correct release name per chart and per environment, accepting that some duplication may be the pragmatic answer, and how to keep whatever we choose from drifting from the tenant config. Candidate approaches None of these is settled; they are starting points, and a combination may be better than any one of them. Metadata in the chart directory. A Chart.yaml annotation is the most promising variant: Helm v3 provides an official annotations map, verified to work without affecting helm template or helm lint , and per-environment names are expressible with suffixed keys. Colocated with the chart and reviewed alongside it, but duplicated from the tenant config. See the release-name findings comment on MZCLD-3077. A workflow input. A JSON map passed by each consumer. No new file convention, but copies ~50 entries per consumer repo and drifts silently. Publish from global-platform-admin. Generate the resolved release name into the tenant repo, as .argocd-source-*.yaml files already are. No duplication and always current, at the cost of a change to the bootstrap chart. Query the tenant config at CI time. Authoritative and unduplicated, but couples the repos and needs cross-repo auth. Make the comparison resilient instead. Normalise or ignore a uniform name prefix when matching resources, so the release name stops mattering. Avoids the data problem entirely but risks masking real renames, and would not help where the migrated side bakes the release name into resource names that differ in more than a prefix. A consistency check in global-platform-admin CI would complement any approach that duplicates the value, turning silent drift into a failing check. Already mitigated MZCLD-3077 added detection for the symptom. When resources appear as both added and removed with names differing only in their leading - separated segments, the comment and job log flag the diff as probably misleading and name the prefix delta, for example treeherder -> treeherder-v2 . Verified against the four shapes above plus the original release-name default. That makes the problem visible rather than silent. It does not fix it: the diff for an affected chart is still not reviewable.",
"comment_count": 0,
"comments": []
}
},
{
"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
}
]