Feature request: ovewrite_permissions for conan server

[piponazo]

Hi,

I would like to describe a feature that would be really interesting for the company I am working at.

Scenario

In our company we do not allow anybody to write directly on the master branch of the main repository and everyone must work on branches and create Pull Request to merge things into master. We have a branch in which we are integrating conan into our project (C++ code) and infrastructure (Jenkins and nodes running in different platforms: Mac OSX, Linux and Windows). Most of the work is done in that branch, but now we are trying to see the different situations we could have and how to deal with them before merging that branch into master.

One of our main concerns is the stability of the conan-server we have configured in our local network. Since we should be able to compile the project in any moment of its history if somebody overwrite accidentally a recipe in the server we would need to manually clean-up the mess in the conan-server.

Example case

Let us imagine that the branch I mentioned before is already merged in master and we have in our project the dependency:

OpenMesh/4.1.1@piponazo/stable

Somebody decides to create a branch in which he/she will try to update that dependency. That person starts to make changes in the recipe but he/she forgets about updating the version number. Once he/she is confident about the changes and uploads the recipe to the server, the damage is done in the conan-server. The moment in which other compilations are triggered by the CI system on the master branch, it will take the new recipe uploaded by the person that is working on the feature-branch.

Possible solution

I have been discussing about this with some colleagues and we think that a nice feature to make more difficult to reach that situation would be to have a new option in the conan server for avoiding to overwrite recipes that are already in the server.

[overwrite_permissions]

I would like to know if somebody has already thought about this case or if there are other approaches for avoiding those situations. I know that this is a corner case in which we are assuming human failures, but sadly the experience says that human errors are frequent :sob:.

If you consider that this feature would be interesting I would like to help to implement it :wink:

[sourcedelica]

I am almost positive there is another issue that talks about this but for the life of me I can't track it down.

Coming from the Maven world where it's verboten to overwrite an existing version in a repo it was strange to be able to do this in Conan (and the whole Node leftpad controversy was foreign). The Maven approach makes sense where you have multiple layers of repositories. If you modify a particular artifact+version, how do you update all the other downstream copies? It's not feasible.

But it was very handy to be able to keep uploading fixes for the same "version" while developing a Conanfile for a 3rd party library where I needed to keep the version number fixed (it wasn't my library, after all).

I like your idea. I was thinking a convention where certain channels (like stable) are frozen could also work. Or a hybrid where you set certain channels to be frozen on the server. There's other stuff that you'd potentially want to set at the channel level: allow uploads by only people in certain roles, etc. Stuff that Artifactory probably already has :)

[memsharded]

Actually, the overwrite of a dependency might make sense in Maven too with the concept of snapshot, during development.

In fact I have a question/concern. I would say that the issue here about human failure might be related to the whole picture, and maybe the thing is that only CI should be able to upload to stable branch by default, and that can be already defined in current permissions. Having individual users uploading packages from their machines and their user-accounts doesn't sound very safe, and should be avoided in the first case.

[sourcedelica]

Yes, Maven SNAPSHOT is a special case. :) and a very handy feature

On Tue, Nov 22, 2016 at 3:28 PM James notifications@github.com wrote:

Actually, the overwrite of a dependency might make sense in Maven too with the concept of snapshot, during development.

In fact I have a question/concern. I would say that the issue here about human failure might be related to the whole picture, and maybe the thing is that only CI should be able to upload to stable branch by default, and that can be already defined in current permissions. Having individual users uploading packages from their machines and their user-accounts doesn't sound very safe, and should be avoided in the first case.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/conan-io/conan/issues/679#issuecomment-262356246, or mute the thread https://github.com/notifications/unsubscribe-auth/AEBjBEE1sDMsBvfQ7glbdUB-WlVBtAcdks5rA1BVgaJpZM4K3R1g .

Sent from Gmail Mobile

[sourcedelica]

Cool, I didn't know you could like limit a branch to certain users.

[memsharded]

Sure, the "snapshot" in maven is useful, that is part of the rationale we used for allow package overwriting, it is something needed often for development.

Yes, permissions are in the form of package recipe reference -> authorized users:

opencv/2.3.4@lasote/testing: default_user, default_user2

So not exactly a branch, but you should be able to allow certain users for certain user/channel

[sourcedelica]

Thx. I will check it out.

Yes, the thing about SNAPSHOT is that it's explicitly not a version.

On Wed, Nov 23, 2016 at 11:34 AM James notifications@github.com wrote:

Sure, the "snapshot" in maven is useful, that is part of the rationale we used for allow package overwriting, it is something needed often for development.

Yes, permissions are in the form of package recipe reference -> authorized users:

opencv/2.3.4@lasote/testing: default_user, default_user2

So not exactly a branch, but you should be able to allow certain users for certain user/channel

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/conan-io/conan/issues/679#issuecomment-262565468, or mute the thread https://github.com/notifications/unsubscribe-auth/AEBjBJFrjszbAmVyjQ92-AjgAxdhxKvxks5rBGsOgaJpZM4K3R1g .

Sent from Gmail Mobile

[lasote]

Now we have the Artifactory community edition for C/C++ totally free and it has fine control of the permissions. We are keeping the conan server as the open source MIT reference implementation of the conan server protocol, but we recommend to use Artifactory because it is much more advanced.