Renovate: `unpublishSafe` Confusing for Docker Updates

[hutson]

_Possibly a bug, possibly a feature in disguise_

What Renovate type are you using?

Renovate GitHub App

Describe the bug

For one of our conventional-changelog/releaser-tools pull requests from Renovate, I am seeing the following _pending_ status:

 renovate/unpublish-safe Pending — Packages < 24 hours old can be unpublished

We do "unpublishSafe": true in our renovate.json file.

However, that pull request is updating a Docker hash.

I don't believe unpublishSafe applies to Docker images from Docker Hub.

To Reproduce

Steps to reproduce the behavior:

1. Fork conventional-changelog/releaser-tools by creating a new project and pushing the releaser-tools repository to that project.
2. Install Renovate on the repository.
3. Wait for pending pull request to update Docker image hash.

Expected behavior

I'm not really sure. Docker Hub does not have the same 24 hour unpublish policy Npm has, so the commit status message, as is, doesn't really make sense for Docker updates. However, I do think Docker allows images and tags to be removed at any time. So should there be a different status for Docker updates, and if so, what?

[rarkins]

I was thinking about this just today actually, although this specific behaviour was unintentional and not desirable.

The thinking was:

1. Docker tags can always be unpublished
2. Docker hashes should typically not get unpublished (but kind of depends on the registry)
3. Neither of these is really useful with our unpublishSafe setting because it's not like the unpublishable ones will magically become safe in the same PR

Similar for GitHub-sourced packages for any manager - they could always disappear, even if a hash.

My conclusion was we probably need to skip the concept of unpublishSafe for any registry type that isn't like npm where it has a period of unpublishability that then turns safe, although it's a little unintuitive. i.e. for any registry that is always possible to unpublish, treat them as never unpublishable.

If you agree, I will fix this up soon.

[hutson]

skip the concept of unpublishSafe for any registry type that isn't like npm where it has a period of unpublishability

Agreed.

it's a little unintuitive. i.e. for any registry that is always possible to unpublish, treat them as never unpublishable.

I agree, it isn't intuitive, but GitHub lacks the facilities for adding additional context to a pull request not directly tied to a commit status (unless you add a line to the PR comment that states that the version can be unpublished at any time according to the registry's policies.).

[rarkins]

Fixed in 603b77799b22fcb2864013fab1b6ecff517ffa59 / v12.47.0