Keep and Untagged seem to compound, is that intentional?

[DeBiese]

Describe the bug
First of all, not sure if this is a bug. But let me describe a scenario.

When you have a repository with 50 tags all linked to a single manifest (so 50 manifests) and you run purge on this 1 repository with "--keep 10 --untagged" and for simplicity lets say you set "--ago 0d".

Then purge would first untag 40 manifests, leaving you with 10 still tagged.
And after that, it would remove 30 of the 40 untagged manifests.

The end result being:
10 tags
20 manifests

To Reproduce
See description

Expected behavior
With the example above in mind, I somehow expected to end up with 10 tags and 10 manifests.
I'm just wondering if how it currently works is intentional or a byproduct of adding (the keep) functionality where this is a (happy) accident.

Any relevant environment information

• OS: Windows
• Version (acr-cli) 0.19

[estebanreyl]

This is a good observation and a reasonable concern. The behavior comes from the fact that untagging and deleting untagged manifests are executed as separate phases, and the --keep value is applied independently in each phase.

For example:
During the untag phase, --keep 10 means keep 10 tags.
During the delete untagged manifests phase, --keep 10 means keep 10 untagged manifests.

So in the scenario above, you could end up keeping the 10 tagged manifests preserved by the untag phase, plus an additional 10 untagged manifests preserved by the delete phase.

This is admittedly a bit confusing because a single flag influences two different operations. The original intent was for --keep to act as a safety mechanism in both phases, but it's fair to argue that the resulting behavior is not entirely intuitive and can appear as though the retention counts are compounding. Its hard to design around this additionally because tags and manifests are not one to one mapped in practice and there can be preexisting untagged manifests so which should get deleted and which get kept is not obvious if you try to account for the two phases. Maybe what we could improve is adding a new --keep-tags and keep-untagged flag or something of the sort to help disambiguate.

[DeBiese]

I'm not entirely sure that throwing additional flags at it is the solution here.
I'd sooner go for sticking to the current --keep flag, BUT making sure that all manifests that are untagged due to this current operation are unprotected by the --keep. The --keep on untagged would only protect those that were already untagged before this command started.
And maybe document that it works that way to avoid confusion.