clean behavior is confusing
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Snapcraft |
Triaged
|
High
|
Sergio Schvezov |
Bug Description
When using snapcraft in practice I've been often stumbling upon the behavior of "cleaning".
Several small nits that come in mind right now:
1. Forcing a particular stage does not work
If one types "snapcraft build some-part", this should indeed build the part. Right now it skips if it was already done before, which is a fine behavior when a part name is not given, but when the developer requested a specific part, it should actually respect the request rather than assuming a cached result is okay.
2. "snapcraft clean" doesn't always work
For example:
% snapcraft clean --step snap
'snap' is not a valid step for part 'qt5-packages'
3. Removing content doesn't work
This is the most obvious way to "clean" when one really cannot tell snapcraft what to do. Just nuke the phase content (e.g. "rm -rf ./snap/"). Instead of taking the cue that the directory is simply not there, snapcraft barfs on internal state:
% rm -rf snap
% snapcraft snap
Skipping pull qt5conf (already ran)
(...)
[Errno 2] No such file or directory:
'/home/
To recover from this state I had to nuke the parts/qt5conf path, which is not intuitive.
We need to urgently improve the experience of people re-running stages, as this is foundation of the try-and-run cycle.
[Impact]
* `snapcraft clean` is a convoluted cli to manage states for parts.
* This introduces un and re prefixes for the lifecycle commands available for snapcraft
[Test Case]
* Run snapcraft prime
* Run snapcraft reprime
* Verify the lifecycle step is rerun.
* Repeat for pull, build and stage
* Run unprime, unstage, unbuild and unpull
* Run snapcraft reprime <part-name>
* Verify the lifecycle step for only <part-name> is rerun.
* Repeat for pull, build and stage
* Run unprime, unstage, unbuild and unpull for <part-name>
* Verify only <part-name> is cleaned.
* Run snapcraft clean with and without <part-name> and -s <step> and verify it still works with a deprecation message shown to use the new syntax.
[Regression Potential]
* This should had minimal effect on regressions as the clean command is staying for backwards compatibility.
* The un and re commands will be UI modifications not touching the lower layers of snapcraft that manage states.
* The "re" commands are totally new feature but with minimal impact (per plugin).
Changed in snapcraft: | |
status: | New → Confirmed |
importance: | Undecided → High |
description: | updated |
Changed in snapcraft: | |
status: | Confirmed → Triaged |
assignee: | nobody → Sergio Schvezov (sergiusens) |
milestone: | none → 2.11 |
Changed in snapcraft: | |
milestone: | 2.12 → 2.13 |
Changed in snapcraft: | |
milestone: | 2.13 → 2.14 |
Changed in snapcraft: | |
milestone: | 2.13 → none |
tags: | added: clean |
tags: | added: 18.10-build-caching |
tags: | added: craft-5 |
I ended up nuking the whole parts directory because I couldn't get the system to move data correctly to the later stages. :-(