Description
Feature Description
Currently there never will be a link between a (NuGet) package and a repository when publishing a package for the first time. So someone has to link it manually at the moment. I can imagine a solution, where the link happens automatically, atleast for NuGet. In .NET projects there is a field namend RepositoryUrl, which could be used to automatically link to an existing repository.
GitHub for example requires this field to be set. Otherwise it'll be rejected. You can read about that here.
Also note the Troubleshooting part there which says:
Your NuGet package may fail to push if the RepositoryUrl in .csproj is not set to the expected repository .
Maybe GitHub enforces this, because there can't be packages without a link to a repository. I'm not sure though.
Some questions we have to think about it:
- What would happen, if the url specified is wrong/invalid?
- What would happen, if the url specified is from another server/the repository doesn't exist?
- What would happen, if the package is already existing in gitea but isn't linked to any repository?
- What would happen, if the package is already existing in gitea but is linked to a diffrent repository?
I would answer these as follows:
- Reject the publish with a meaningful message. Something like that the url has the wrong format. Depends on what is checked here.
- Reject the publish with a meaningful message. Something like that the repository specified couldn't be found in that gitea instance
- Link the package to the specified repository
- Reject the publish with a meaningful message. The package link should be changed manually before (once) or the RepositoryUrl needs to be fixed. I don't prefer an automatic overwrite of the existing link because this could be a mistake and the user maybe didn't even recognized so.
EDIT: Maybe this can be adopted for other registries too. I'm not familiar with these though.
Screenshots
No response