Conan: `conan upload` should fail if package exists on remote

[alessandrodn]

Hi,
I setup a local repository for a small dev team.
Whenever a package is built, I upload a package using conan remote.
I would like Conan not to overwrite an existing package with the same name/version@user/channel.

Simple example:

conan upload --remote local-server package/1.0.0@user/channel

If this command is going to overwrite an existing package, Conan should warn the user and fail.

Error: an existing package with this version already exist!

There may be an option --force that let the user forcing the overwrite of the package.

[lasote]

This is not suitable for CI environment, where the recipes and packages are uploaded from several different machines, so it cannot be a default behavior. I think this should be a server feature more than a client feature. If you don't want to allow overriding a recipe you don't want a user with a bad configuration overriding it by mistake. Artifactory has support for controlling the permissions that way.
Here is a similar issue reported: #1381

[alessandrodn]

I see your point and have some questions; I don't know if this is the right place to post this, sorry in advance.

So far I used Conan for managing external libraries and it works great.
I am struggling to get a working model to manage internal dependencies for a project which consist of several components.

1. You said, basically in CI there is just one version of the package which is continuously overwritten: how do manage different co-existent releases in this model?
   Let's say release 1.0 is out, we release 2.0 which change the code base and overwrite the old packages; now a patch to be applied to 1.0...
2. If you have a single package, how do you manage different branches? do you build a package just for the master branch once changes are committed?
3. Who generate the packages? Jenkins (CI) only or any developer can upload packages?
4. What is the developer workflow? lets say, he checks out the component he need to modify, but he also want to build the final product to verify everything works fine. Does he generate a package for his new component?
5. If we want to use package version, is there a way to automate the version bump in the requires section? so far I am using a version derived from timestamp when generating the package, but the developer still need to modify the conanfile with the requirements.

Thanks a lot for your support.

[lasote]

You said, basically in CI there is just one version of the package which is continuously overwritten: how do manage different co-existent releases in this model?
Let's say release 1.0 is out, we release 2.0 which change the code base and overwrite the old packages; now a patch to be applied to 1.0...

The package version should follow the release version, when you release 2.0 is a different package from 1.0. If a patch is applied to 1.0 it should be 1.0.1

If you have a single package, how do you manage different branches? do you build a package just for the master branch once changes are committed?

It depends on the workflow it fits better for you. I usually have branches "release/XXX" and "testing/XXX", if a branch "release/XXX" is pushed, the CI will create and upload the packages to a server. Maybe the CI could upload to a different server or repository when the branch is testing (suitable with Artifactory, that supports multiple repositories of conan or any other package manager)

Who generate the packages? Jenkins (CI) only or any developer can upload packages?

Again, it depends. For a production environment sounds reasonable to limit the permissions to a user in the CI server so he is the only one able to upload packages to a "release" repository.

What is the developer workflow? lets say, he checks out the component he need to modify, but he also want to build the final product to verify everything works fine. Does he generate a package for his new component?
If we want to use package version, is there a way to automate the version bump in the requires section? so far I am using a version derived from timestamp when generating the package, but the developer still need to modify the conanfile with the requirements.

If the component "A" gets modified, then the version should be bumped (unless you are in development). Then, what to do with the packages depending on it? There are several approaches:

1. Version ranges, to depend automatically on the latest "A"
2. Alias package: This is a recipe that can be pointed to a different reference, so you can update and upload the alias poining to the new updated version of "A"
3. Change the packages depending on "A" manually to update them to A+1

These workflows works well, the more complicated flow we are trying to improve in the following Conan versions is the development workflow. If you are constantly updating the libraries you are packaging, it is not smooth to constantly create package revisions not even creating packages. By now we have the "local commands": conan source, conan build, conan package and conan package_files, that will enable you to work as a develop in your local workspace. Take a look to the issue https://github.com/conan-io/conan/issues/447 and in general to all of the issues marked with the "development flow" label.

[madpipeline]

I've only read the title, but: Since Conan 1.2 there is a --no-overwrite parameter to conan upload. This might help.