← 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

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.

Suggested action: keep open

Reason: A maintainer (lengau) acknowledged the issue on 2024-09-09 ('I'm unsure whether this is still an issue - need to check'), so it is triaged and not stale-dead. The related open craft-application#821 ('5.5.0 changes pack semantics if the project file has different metadata' — pack skips rebuilding when charmcraft.yaml metadata changes, reporting 'Already packed') indicates the underlying bug is still present and unresolved, so it should remain open pending verification.

Impact: 55 Quick Win: 24.75 Staleness: 65 Complexity: 55 Confidence: 70 Support Request: 5

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
qwen/qwen3.8-27b
Impact: 55
Quick Win: 24.75
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.
qwen3.6-35b-a3b-mtp-q6
Staleness: 85
Complexity: 25
Confidence: 60
Support Request: 15
needs triage Modifying charmcraft.yaml fails to update the generated metadata.yaml during repacking. Issue remains open but author needs to verify current reproducibility. Synced to Jira CRAFT-2505. Awaiting confirmation or triage.

Update history

No update history recorded yet.

Related work

  • Duplicate Of: canonical/craft-application#821 (confidence 75%)

    craft-application#821 reports the same symptom: charmcraft pack skips rebuilding when charmcraft.yaml metadata changes, so metadata.yaml in the packed charm goes stale. That issue is open and awaiting resolution, suggesting this is still reproducible.

Related issues

Issue Project State Summary Similarity
#1160 `charmcraft pack` does not recognize updated `charmcraft.yaml` file charmcraft open charmcraft pack ignores updated build-snaps channel in charmcraft.yaml without a clean; tracked as a craft-parts bug (canonical/craft-parts#496, still open) awaiting a dependency patch release to pull into charmcraft.
80%
#821 5.5.0 changes pack semantics if the project file has different metadata craft-application open Charmcraft pack skips repacking when only charmcraft.yaml metadata (e.g. summary, config, platforms) changes, leaving a stale .charm. Triaged and moved to craft-application; workaround is clean. Conditional repacking support added in #1111.
78%
#2273 charmcraft.yaml deleted while packing (working tree not clean) charmcraft open charmcraft pack deletes charmcraft.yaml from the working tree, making git describe --dirty report -dirty on clean release builds. Reported with charmcraft 3.4.3, no maintainer response or labels in ~13 months.
74%
#710 `charmcraft pack` retains no longer existing files from previous packs charmcraft open charmcraft pack includes files deleted from the working directory in the charm archive; clean fixes it. Triaged as a known bug, re-confirmed present in Oct 2024, upstream craft-parts bug filed, per-part clean workaround documented.
74%
#552 `charmcraft pack` runs indefinitely when using parts charmcraft closed The charmcraft pack hang was caused by a duplicate ignore patterns bug. This was fixed in Charmcraft 1.3.0. The author confirmed they would upgrade and close the issue pending recurrence.
73%
#2341 Packing a bundle produces a zip that is rejected by charmhub charmcraft open charmcraft 3.x pack produces a bundle zip with metadata.yaml instead of bundle.yaml, so charmcraft upload is rejected by charmhub. A maintainer asked for the charmcraft.yaml on 2025-06-27; no further activity since.
72%
#907 `charmcraft pack` does not handle updating a file's execution permissions without a `charmcraft clean` charmcraft open charmcraft pack ignores local file permission changes (e.g., chmod +x on src/charm.py) until a full charmcraft clean, causing confusing lint errors. Maintainer reproduced and filed upstream craft-parts#311; still unfixed.
72%
#2680 `name` field missing from packed charm's `metadata.yaml` when defined in `charmcraft.yaml` alongside a separate `metadata.yaml` charmcraft open Charmcraft 4.0.1 packs a metadata.yaml without the `name` field when `name` is defined in charmcraft.yaml and a separate metadata.yaml (lacking `name`) exists, making the charm undeployable in Juju. Confirmed by a second user; no maintainer response yet.
72%
#746 `charmcraft pack` for existing environment does not remove files that have been deleted charmcraft closed Closed as a duplicate of issue #710. The charmcraft pack command was reported to retain deleted files in the charm archive across builds. Resolution and tracking are handled in the referenced duplicate issue.
71%
#1931 Successfully pack charm with incorrect charm.py file permission charmcraft open charmcraft pack succeeds even when src/charm.py lacks the execute bit, producing a charm that fails at deploy with 'Permission denied'. Requested a warning/error or auto-fix at pack time. No maintainer activity; an entrypoint linter now exists but only runs via charmcraft analyze, not pack.
71%