Renaming a file in a directory declared as a source for a part doesn't trigger a new pull

[dilyn-corner]

Bug Description

If for some part source: src/ is declared and the pull step already ran and I rename src/foo to src/bar, the pull step is not retriggered. This can cause at best, a missing file in the final snap, and at worst later steps to fail for no obvious reason.

To Reproduce

Create a snap with a part using plugin: dump and source: src/, with at least one file in src/. Run at least snapcraft pull. Rename that file, and rerun the build.

Environment

Ubuntu 23.10, building with snapcraft latest/edge with --use-lxd.

snapcraft.yaml

name: my-snap-name # you probably want to 'snapcraft register <name>'
base: core24 # the base snap is the execution environment for this snap
version: '0.1' # just for humans, typically '1.2+git' or '1.3.2'
summary: Single-line elevator pitch for your amazing snap # 79 char long summary
description: |
  This is my-snap's description. You have a paragraph or two to tell the
  most important story about your snap. Keep it under 100 words though,
  we live in tweetspace and your description wants to look good in the snap
  store.

grade: devel # must be 'stable' to release into candidate/stable channels
confinement: devmode # use 'strict' once you have the right plugs and slots

parts:
  my-part:
    # See 'snapcraft plugins'
    plugin: dump
    source: src/
    override-stage: |
      craftctl default
      [ -e "${CRAFT_STAGE}/foo" ] || exit 1

Relevant log output

First build:

dilyn@Ares:~/test -> snapcraft
Starting snapcraft, version 8.3.2.post51+git22ba3ae03
Logging execution to '/home/dilyn/.local/state/snapcraft/log/snapcraft-20240818-191843.140066.log'
Launching managed ubuntu 24.04 instance...
Creating instance from base instance
Starting instance
Starting snapcraft, version 8.3.2.post51+git22ba3ae03
Logging execution to '/tmp/snapcraft.log'
Initialising lifecycle
Installing build-packages
Installing build-snaps
Pulling my-part
Building my-part
:: + cp --archive --link --no-dereference . /root/parts/my-part/install
Staging my-part
:: + craftctl default
:: + '[' -e /root/stage/foo ']'
Priming my-part
Packing...
Reading snap metadata...
Running linters...
Running linter: classic
Running linter: library
Creating snap package...
Packed my-snap-name_0.1_amd64.snap



Second build, after mv src/foo src/bar:
dilyn@Ares:~/test -> snapcraft
Starting snapcraft, version 8.3.2.post51+git22ba3ae03
Logging execution to '/home/dilyn/.local/state/snapcraft/log/snapcraft-20240818-192056.040803.log'
Launching managed ubuntu 24.04 instance...
Starting instance
Starting snapcraft, version 8.3.2.post51+git22ba3ae03
Logging execution to '/tmp/snapcraft.log'
Initialising lifecycle
Installing build-packages
Installing build-snaps
Skipping pull for my-part (already ran)
Skipping build for my-part (already ran)
Skipping stage for my-part (already ran)
Skipping prime for my-part (already ran)
Packing...
Reading snap metadata...
Running linters...
Running linter: classic
Running linter: library
Creating snap package...
Packed my-snap-name_0.1_amd64.snap

Additional context

This is a hard problem to solve :)

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

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

This message was autogenerated

[mr-cal]

I agree that this is would be a very useful enhancement but I don't believe there is a precedence. For example, snapcraft doesn't check if remote sources have been modified on every run.

I filed an upstream bug as well: canonical/craft-parts#817

[dilyn-corner]

I would only expect snapcraft to repull a remote source just in case something like source-checksum or source-commit changed -- I'd recommend someone always specify these. There is no analogue for a local dir source.

The most confusing aspect of this is that if the contents of a file in a source dir changes, the pull step retriggers. You'd think this would extend to that file no longer existing, as well...