--project-dir fails to find metadata.yaml when running in destructive mode
Metadata
Current evaluation
Destructive pack with --project-dir and split metadata.yaml was a path-resolution bug; later lifecycle fixes and the documented Charmcraft 4.2.1 fix for analogous #2493 resolve it.
Suggested action: close resolved
Reason: Commit 5e634d96 fixes -p handling, and current unmanaged-mode code changes project_dir before evicting the cached project service so parts load from the requested path. Charmcraft 4.2.1 release notes also explicitly list #2493, the same separate-metadata.yaml plus --project-dir failure, as resolved.
Evaluated by: mr-cal-bot
Impact:
28
Quick Win:
16
Complexity:
35
Confidence:
95
Actionability:
90
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 |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
28
Quick Win:
16
Complexity:
35
Confidence:
95
Actionability:
90
|
close resolved | Destructive pack with --project-dir and split metadata.yaml was a path-resolution bug; later lifecycle fixes and the documented Charmcraft 4.2.1 fix for analogous #2493 resolve it. | |
| qwen/qwen3.6-35b-a3b |
Impact:
30
Quick Win:
14
Complexity:
40
Confidence:
85
Actionability:
80
|
keep open | Bug where --project-dir fails to locate metadata.yaml in destructive mode, causing proof to fail. Maintainer acknowledged the issue and identified path resolution in parts as the likely cause. | |
| qwen/qwen3.8-27b |
Impact:
30
Quick Win:
14
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. |
Update history
No update history recorded yet.
Related work
-
Likely Fixed By:
canonical/charmcraft#2493
(confidence 96%)
A later report of the same split-metadata.yaml and --project-dir failure, explicitly documented as fixed in Charmcraft 4.2.1.
-
Likely Fixed By:
canonical/charmcraft#2600
(confidence 92%)
Commit 5e634d96 fixes -p handling and updates unmanaged-mode project-directory initialization.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #2493 Packing fails when using a separate metadata.yaml file and `--project-dir` argument | charmcraft | closed | Fixed by PR #2644 (c87eca0d), which loads separate metadata.yaml from the correct project directory. The fix was slated for Charmcraft 4.2.1. | |
| #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. |