canonical / charmcraft

Collaborate, build and publish charmed operators for Kubernetes, Linux and Windows.
Apache License 2.0
66 stars 71 forks source link

`charmcraft pack` retains no longer existing files from previous packs #710

Open sed-i opened 2 years ago

sed-i commented 2 years ago

When I repack a charm, the resulting charm has a file that no longer exists in the working directory:

> $ ls src/prometheus_alert_rules
total 16K
drwxrwxr-x 2 tux tux 4.0K Mar 10 15:00 .
drwxrwxr-x 5 tux tux 4.0K Mar 10 15:00 ..
-rw-rw-r-- 1 tux tux  323 Mar 10 15:00 always_firing_absent.rule
-rw-rw-r-- 1 tux tux  301 Mar 10 15:00 always_firing_numeric.rule

> $ charmcraft pack
Charms packed:
    avalanche-k8s_ubuntu-20.04-amd64.charm

> $ unzip -l avalanche-k8s_ubuntu-20.04-amd64.charm | grep always_firing
      306  2021-12-01 19:21   src/prometheus_alert_rules/always_firing.rule
      323  2022-03-10 20:00   src/prometheus_alert_rules/always_firing_absent.rule
      301  2022-03-10 20:00   src/prometheus_alert_rules/always_firing_numeric.rule

Note how src/prometheus_alert_rules/always_firing.rule doesn't exist in the workdir, but is present in the archive.

This issue went away after clean:

> $ charmcraft clean
Cleaned project 'avalanche-k8s'.

> $ charmcraft pack
Charms packed:
    avalanche-k8s_ubuntu-20.04-amd64.charm

> $ unzip -l avalanche-k8s_ubuntu-20.04-amd64.charm | grep always_firing
      323  2022-03-10 20:00   src/prometheus_alert_rules/always_firing_absent.rule
      301  2022-03-10 20:00   src/prometheus_alert_rules/always_firing_numeric.rule

Environment

PietroPasotti commented 2 years ago

I've encountered the same issue several times in the past

PietroPasotti commented 2 years ago

will keep my eyes peeled on whether it still occurs on latest release

facundobatista commented 2 years ago

It's a known bug, so yes, still there in latest release (sorry).

syncronize-issues-to-jira[bot] commented 1 month ago

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/CRAFT-3422.

This message was autogenerated

lengau commented 1 month ago

Confirmed this is still an issue. I've made an upstream bug report: https://github.com/canonical/craft-parts/issues/851

lengau commented 1 month ago

Workaround for this: you can clean a specific part without destroying the build container with charmcraft clean <part-name>. e.g. charmcraft clean charm