Perform actions after a package was removed

[KN4CK3R]

The removal of packages outside of the defined package registry flow may lead to dirty data if the package type stores informations about the available packages outside of the database. For example the Cargo registry stores the package index in a git repository. At the moment the owner needs to rebuild the whole index in this case from the user settings.

This PR enforces an update of the index entry in the git repository. In future the Debian registry will need this too.

[delvh]

I do have to say, the current architecture looks pretty error-prone:
Every caller must ensure themselves that they call the post-removal.
Sooner or later, this will produce buggy and unmaintainable behavior, simply because someone forgets it.
I think it would be a better idea to define an interface Registry (or similar) that gets the methods that every registry needs, i.e. GetPackage, GetPackages, UploadPackage, EditPackage(not sure if that's supported), and DeletePackage (did I forget any common method?).
Then, you define an implementation per registry.
That way, adding new registries (and maintaining the existing ones) will be much easier as you only need to define such an implementation and can throw out a lot of code duplication.
Adding all that is certainly worth its own PR.

---

I think at the moment, you're the only one who really knows what's happening where inside the registry-related code.
That's not maintainable and a way too low bus factor.

[zeripath]

Why doesn't the packages_service run the cleanup function itself? Isn't it fragile to expect callers of packages_service.Remove... to remember to do the cleanup?

[KN4CK3R]

We must distinguish between two different deletion modes:

The first is specified by the package type registry api. If there is a designated delete method there is no problem because the deletion of package is an intended operation.

The second is our custom delete operation from the UI or API. This operation is not covered by the package type specification. Most package types are ok with this because the client just queries the available packages and now there is one missing, everything fine. But there are also package types where it is not possible to generate such query responses on the fly. An example is the Cargo registry which stores the package index in a git repository. If a package gets deleted from the UI/API the git repository must be changed too, otherwise the repository is out of sync with the db. Currently there is only a note in the Gitea documentation what to do in this case.

So this PR is only needed for the second unsupported case. There are only 4 places where such logic is needed. Deletion from the package UI, deletion from the admin UI, deletion from the package API (Gitea API, not the registry API) and deletion by a cleanup rule.

I think it would be a better idea to define an interface Registry (or similar) that gets the methods that every registry needs

That's a naïve view of how most package registries work and only a few will fit in. The common "interface" all registries (except the uploading of container images) use, are the methods in services/packages/packages.go. Everything in the router is registry type specific. From my view there is not much left which is duplicated.

I think at the moment, you're the only one who really knows what's happening where inside the registry-related code.

I will add a readme file for future developers to explain how everything works together. (We should have more of these rough overviews of how things work in Gitea. But there should not be to much detail so they are not outdated shortly after.) As seen in #20751 (comment) it looks like the interface is well thought out, otherwise it would not have been possible to add a new package type without asking questions.

Why doesn't the packages_service run the cleanup function itself? Isn't it fragile to expect callers of packages_service.Remove... to remember to do the cleanup?

I thought of multiple ways on how to implement it. The first guess is to add it into RemovePackageVersion which also handles the webhook notification. The first problem would be an import cycle there but that may be handled otherwise. The more important problem is that this method is used by the both deletion modes (defined and undefined). For the defined deletion this method should not perform the post-delete actions because they may (and are) different from the actions to be performed by the undefined deletion. So there could be a parameter to enable the actions but that's just again the "expect the callers" problem. I could add a RemovePackageVersionUndefined method which first calls RemovePackageVersion and then performs the actions. So the actions can't be forgotten but the caller must still use the correct method then. But I don't see a problem here generally because currently I can't think of a new way which would need unsupported deletes.

[lunny]

Can we have some tests?