← Back to issue list

Changing charmcraft.yaml doesn't update the resulting charm's metadata.yaml

View original Github issue

Metadata

Project
charmcraft
Number
#1530
Type
issue
State
open
Author
lengau
Labels
—
Created
Updated
Closed
—

Current evaluation

The original stale metadata.yaml bug was fixed by merged PR #2874; a later Charmcraft 5.5.0 stale-repack variant remains tracked in craft-application#821.

Suggested action: close resolved

Reason: Merged PR canonical/charmcraft#2874 implemented metadata mediation so metadata.yaml is generated from charmcraft.yaml, with approvals and fast and slow test jobs passing; current package code also serializes the project metadata model. A separate post-5.5.0 stale-repack regression remains open in canonical/craft-application#821.

Evaluated by: mr-cal-bot

Impact: 52 Quick Win: 20 Complexity: 42 Confidence: 94 Actionability: 67

Issue body

### Bug Description A change to charmcraft.yaml + re-packing doesn't change metadata.yaml ### To Reproduce Change charmcraft.yaml, re-pack, check metadata.yaml ### Environment charmcraft edge ### charmcraft.yaml ```shell any ``` ### Relevant log output ```shell n/a ```

Evaluation history

Date Model Scores Action Summary
stealth/space-bunny-alpha
Impact: 52
Quick Win: 20
Complexity: 42
Confidence: 94
Actionability: 67
close resolved The original stale metadata.yaml bug was fixed by merged PR #2874; a later Charmcraft 5.5.0 stale-repack variant remains tracked in craft-application#821.
qwen/qwen3.6-35b-a3b
Impact: 30
Quick Win: 14
Complexity: 40
Confidence: 85
Actionability: 80
close resolved Issue about charmcraft.yaml changes not updating metadata.yaml. Resolved by PR #2874 which implemented metadata mediation to generate metadata.yaml from charmcraft.yaml.
qwen/qwen3.8-27b
Impact: 55
Quick Win: 25
Staleness: 65
Complexity: 55
Confidence: 70
Support Request: 5
keep open Bug: editing charmcraft.yaml then re-running `charmcraft pack` does not update the resulting charm's metadata.yaml. Filed by a maintainer (lengau); last comment (2024-09-09) says it's unclear if still reproducible. Related open craft-application#821 describes the same 'Already packed' skip behavior.
qwen/qwen3.6-35b-a3b
Staleness: 85
Complexity: 30
Confidence: 60
Support Request: 20
close stale Unverified bug report claiming charmcraft.yaml changes do not update metadata.yaml. Over two years old, lacks reproduction details, and the author noted uncertainty about its current relevance. No maintainer engagement.
qwen3.6-35b-a3b-mtp-q6
Staleness: 85
Complexity: 40
Confidence: 60
Support Request: 25
needs triage Unlabelled report that modifying charmcraft.yaml does not update metadata.yaml during repacking. Open for over two years with no maintainer response; author recently noted uncertainty about current relevance.
qwen3.6-35b-a3b-mtp-q6
Staleness: 85
Complexity: 20
Confidence: 80
Support Request: 60
close stale Report that changes to charmcraft.yaml do not update metadata.yaml during repackaging. The original author recently questioned if the issue persists, and there has been no maintainer follow-up or reproduction details.

Update history

No update history recorded yet.

Related work

  • Likely Fixed By: canonical/charmcraft#2874 (confidence 98%)

    Merged PR that mediated metadata.yaml creation from charmcraft.yaml.

  • Related To: canonical/craft-application#821 (confidence 94%)

    Tracks a later stale .charm variant after Craft Application 5.5.0.

  • Related To: canonical/charmcraft#2890 (confidence 86%)

    Open PR intended to prevent repacking unchanged projects and is reportedly associated with craft-application#821.

Related issues

Issue Project State Summary Similarity
#821 5.5.0 changes pack semantics if the project file has different metadata craft-application open Metadata-only charmcraft.yaml edits were skipped as "Already packed," leaving stale .charm artifacts; Charmcraft PR #2890 is reported to fix repacking after the edit.
81%
#1160 `charmcraft pack` does not recognize updated `charmcraft.yaml` file charmcraft open Tracked upstream: charmcraft pack ignores build-snaps channel changes in charmcraft.yaml unless clean is run. Root cause is craft-parts#496 (build-snaps missing from properties_of_interest), still unfixed; charmcraft only needs a craft-parts bump once patched.
75%
#1666 fix: only keep metadata.yaml for reactive charms charmcraft merged Merged #1666 (b2b127e6), retaining metadata.yaml only for reactive charms so non-reactive repacks no longer carry stale integration metadata; fixes #1654.
74%
#2498 fix: `charmcraft pack --project-dir` with metadata.yaml charmcraft closed Closed unmerged; superseded by #2644, which fixed metadata lookup for --project-dir and shipped in Charmcraft 4.2.1.
74%
#2856 Implement metadata mediation for metadata.yaml charmcraft closed Fixed by merged charmcraft PR #2874, which added a craft-application package service to mediate metadata.yaml creation.
73%
#1974 Check `charmcraft.yaml` for charm name charmcraft merged Merged PR #1974 (commit beb5c145), fixing #1973: list-lib now reads the charm name from charmcraft.yaml instead of requiring metadata.yaml.
73%
#1468 replaced metadata.yaml with charmcraft.yaml in integration test templates charmcraft closed #1468 was closed as superseded after CLA/signature blockers; PR #1540 merged the equivalent metadata.yaml-to-charmcraft.yaml integration-template update in commit f3f82031.
72%
#2874 feat: mediate creation of metadata.yaml charmcraft merged PR #2874 merged to charmcraft main (2 approvals): implements craft-application's package service API so metadata.yaml creation is mediated in Charm/rock layers, tracking CHARMCRAFT-723.
71%
#699 Release 1.5 charmcraft merged Charmcraft 1.5 was released by merging canonical/charmcraft#699, which updated release metadata in two files.
71%
#2680 `name` field missing from packed charm's `metadata.yaml` when defined in `charmcraft.yaml` alongside a separate `metadata.yaml` charmcraft open Packed charm metadata.yaml omits name when name is in charmcraft.yaml and separate metadata.yaml lacks it, making charm undeployable. Confirmed by second user; no maintainer triage yet.
70%