Do not force creation of _cargo-index repo on publish

[merlleu]

Hello there,
Cargo Index over HTTP is now prefered over git for package updates: we should not force users who do not need the GIT repo to have the repo created/updated on each publish (it can still be created in the packages settings).

The current behavior when publishing is to check if the repo exist and create it on the fly if not, then update it's content.
Cargo HTTP Index does not rely on the repo itself so this will be useless for everyone not using the git protocol for cargo registry.

This PR only disable the creation on the fly of the repo when publishing a crate.

This is linked to #26844 (error 500 when trying to publish a crate if user is missing write access to the repo) because it's now optional.

[silverwind]

I noticed in a instance of mine that a _cargo-index repo was created, even though I never published a cargo package (I did publish other packages though). Will this get rid of this creation?

[merlleu]

I noticed in a instance of mine that a _cargo-index repo was created, even though I never published a cargo package (I did publish other packages though). Will this get rid of this creation?

Hello, from what I understood only 3 actions can trigger the repo creation: cargo publish or use of the Settings > Packages > Initialize/Rebuild Index.
Are you sure you did not use the 2 last buttons ? Might be worth creating a separate issue including commit log and the logs around the commits if you did not.

[silverwind]

Ah, yes it might have been the Initialize/Rebuild Index button. Sorry, it's off-topic here :)

[lunny]

Could we know the protocol of the client side? maybe we should obey the client side protocol to do that. Sparse or not.
Or maybe we can retire old protocol entirely.

[merlleu]

Could we know the protocol of the client side? maybe we should obey the client side protocol to do that. Sparse or not. Or maybe we can retire old protocol entirely.

We can't know this this unfortunately, I think we should push users toward using exclusively httpregistry, maybe remove all instructions to setup git registry and make it optional, then disable it entirely in a future version ?

[lunny]

Could we know the protocol of the client side? maybe we should obey the client side protocol to do that. Sparse or not. Or maybe we can retire old protocol entirely.

We can't know this this unfortunately, I think we should push users toward using exclusively httpregistry, maybe remove all instructions to setup git registry and make it optional, then disable it entirely in a future version ?

I would like the idea. As this PR, maybe we can have an option to enable/disable git registry. Maybe the default value could be false. So spare protocol could be the default one but git registry is optional.

[merlleu]

Could we know the protocol of the client side? maybe we should obey the client side protocol to do that. Sparse or not. Or maybe we can retire old protocol entirely.

We can't know this this unfortunately, I think we should push users toward using exclusively httpregistry, maybe remove all instructions to setup git registry and make it optional, then disable it entirely in a future version ?

I would like the idea. As this PR, maybe we can have an option to enable/disable git registry. Maybe the default value could be false. So spare protocol could be the default one but git registry is optional.

I think this is basically what this PR does: users will have to click "Init Index" in the org/user package settings to have the registry enabled. They can just remove the repo if they no longer want to use git registry and it should not create it again.

Please note that the authorization support for the cargo registry just made it to the nightly branch (on the client) so there should not be too much gitea users using this package registry yet, so we can probably remove the git version before too much people start using it.

[KN4CK3R]

Could you change the method name from AddOrUpdatePackageIndex to just UpdatePackageIndex then? (or a better name? TryUpdatePackageIndex, UpdateExistingPackageIndex, ...?)

[merlleu]

Could you change the method name from AddOrUpdatePackageIndex to just UpdatePackageIndex then? (or a better name? TryUpdatePackageIndex, UpdateExistingPackageIndex, ...?)

Thanks for the feedback, I renamed it to UpdatePackageIndexIfExists.