--project-dir fails to find metadata.yaml when running in destructive mode
Metadata
Current evaluation
charmcraft pack --destructive-mode -p <dir> fails for reactive charms: charm proof cannot find metadata.yaml because the reactive plugin runs it in the wrong directory. Maintainer marked it low priority in Aug 2024; no fix since.
Suggested action: keep open
Reason: Maintainer @lengau triaged it (2024-08-14) as a real bug related to how parts directories are made in destructive mode, and an internal ticket CRAFT-3224 was created, so it is acknowledged but explicitly deprioritized. The reactive plugin still exists in the codebase (charmcraft/parts/plugins/_reactive.py) and runs charm proof from the build dir, so the bug is likely still present, but destructive mode is discouraged and the reporter's workaround (cd into the charm dir) works, keeping impact modest.
Impact:
30
Quick Win:
13.5
Staleness:
75
Complexity:
55
Confidence:
65
Support Request:
10
Issue body
### Bug Description
This is a low priority bug, but I thought I'd report it anyway.
In this project: https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+ref/master
Our CI recently started failing, with no apparent reason.
The charmcraft version is 3.1.1
Part of our ci is the following command:
```
charmcraft pack -v --destructive-mode -p charms/focal/autopkgtest-cloud-worker/
```
which has been failing with:
```
:: :: + /snap/charmcraft/4369/bin/python3 -I /snap/charmcraft/4369/lib/python3.10/site-packages/charmcraft/parts/reactive.py autopkgtest-cloud-worker /build/lpci/project/parts/charm/build /build/lpci/project/parts/charm/install
:: :: FATAL: No bundle.yaml (Bundle) or metadata.yaml (Charm) found, cannot proof
:: :: charm tool execution command=['charm', 'proof']
```
However, the metadata.yaml is there, as the following works:
```
cd charms/focal/autopkgtest-cloud-worker/
charmcraft pack -v --destructive-mode
```
FTR, we have a pretty outdated charm. We don't have a charmcraft.yaml and instead have a metadata.yaml, layer.yaml, etc, and I'm aware we're building our charms in this pipeline in a pretty janky way :)
### To Reproduce
git clone -b master https://git.launchpad.net/autopkgtest-cloud
cd autopkgtest-cloud/
snap install lpci --classic
lpci run # feel free to comment out the other jobs in .launchpad.yaml to make it faster
### Environment
destructive mode via LPCI
focal
### charmcraft.yaml
```shell
the yaml files are under:
charms/focal/autopkgtest-cloud-worker/
charms/focal/autopkgtest-web/
```
### Relevant log output
```shell
:: :: + /snap/charmcraft/4369/bin/python3 -I /snap/charmcraft/4369/lib/python3.10/site-packages/charmcraft/parts/reactive.py autopkgtest-cloud-worker /build/lpci/project/parts/charm/build /build/lpci/project/parts/charm/install
:: :: FATAL: No bundle.yaml (Bundle) or metadata.yaml (Charm) found, cannot proof
:: :: charm tool execution command=['charm', 'proof']
```
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| qwen/qwen3.8-27b |
Impact:
30
Quick Win:
13.5
Staleness:
75
Complexity:
55
Confidence:
65
Support Request:
10
|
keep open | charmcraft pack --destructive-mode -p <dir> fails for reactive charms: charm proof cannot find metadata.yaml because the reactive plugin runs it in the wrong directory. Maintainer marked it low priority in Aug 2024; no fix since. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
85
Complexity:
40
Confidence:
75
Support Request:
15
|
close stale | charmcraft pack --destructive-mode fails to locate metadata.yaml when using --project-dir, though it works from the target directory. Acknowledged by maintainer as low priority due to destructive mode being discouraged. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
75
Complexity:
40
Confidence:
75
Support Request:
20
|
keep open | Bug where --project-dir fails to locate metadata.yaml in destructive mode. Acknowledged by maintainer as low priority and linked to an internal ticket, but has been inactive for nearly a year. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
85
Complexity:
45
Confidence:
80
Support Request:
15
|
close stale | Bug where charmcraft pack --destructive-mode with project-dir fails to locate metadata.yaml, unlike running from within the directory. Acknowledged as low priority with a workaround, but remains unresolved after over a year. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
75
Complexity:
40
Confidence:
75
Support Request:
15
|
keep open | charmcraft pack --destructive-mode fails to locate metadata.yaml when using --project-dir. Maintainers acknowledge the bug but mark it low priority since destructive mode is discouraged in CI. Internal ticket CRAFT-3224 created. Awaiting triage. |
Update history
No update history recorded yet.
Related work
-
Related To:
canonical/charmcraft#2427
(confidence 40%)
fix(lifecycle): fix --project-dir and --output (#2427) touched project-dir handling in the lifecycle; may have changed behavior but no evidence it fixed this specific destructive-mode reactive case.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #2498 fix: `charmcraft pack --project-dir` with metadata.yaml | charmcraft | closed | Merged fix for charmcraft pack --project-dir failing with legacy metadata.yaml. Resolved by changing the working directory to the project directory before loading and preprocessing configuration files. Resolves issue #2493. | |
| #1524 fix(package): don't write a metadata.yaml if it already exists. | charmcraft | merged | Merged a fix preventing overwrites of existing metadata.yaml files. Approved by two reviewers, this change enables reactive charm support in destructive mode as a partial resolution for issue #1488. |