[question] Support for avoiding the upload of new recipe revisions in conan upload? about conan HOT 6 OPEN

Hi @schwaerz

Thanks for your question.

Therefore - when creating an actual release on the main branch - we'd like to be able to tell conan to not create a new revision if there's already another revision existing for the version which is about to be uploaded.

I am afraid I don't fully understand this. Do you mean that the revision already exists? If it creates a new revision because there are changes to the code, why would you like to discard those changes?

Can you please clarify a bit more the flow? Thanks!

from conan.

Hi @memsharded

Thanks for the quick answer.

Scenario is as follows:

1. We do a release, let's say version 1.2.3. Git commit gets tagged accordingly by the CI automation.
2. Some changes will be done (feature branch). However they miss to do a version update.
3. Changes will be merged to master. The build on the master branch will automatically upload the package once all the tests passed.

Now what would happen is:

• There would be a new revision in Artifactory of that version. However it will not fit to the tagged git commit anymore. The tagged commit still belongs to the old revision. We must not move the git tag, as the old version may have been shipped already. We have to keep that tag in place to ensure we will be able to reproduce things easily.

Ultimately it'd be good to have the option to

• Skip creation of a new revsion (issueing a WARNING)
• Fail the build - so the developers would notice that they forgot to increase the version number

As an alternative I thought about checking - at the beginning of the CI run - whether there's already a tag in the repo matching the version about to be built. But that did not feel sufficiently reliable.

from conan.

Thanks for the details.

2. Some changes will be done (feature branch). However they miss to do a version update.

I think this is the root issue, and it is basically a fundamental versioning problem. I'd say that it is a "broken" flow in the sense that you don't want to allow newer revisions of an "already frozen" 1.2.3 version.

This happens a lot, in other technologies, this is not a Conan problem per-se.

A typical solutions is that the tag process for a "1.2.3" release typically changes and does a newer commit, automatically that bumps the version to something like 1.2.4-dev or something like that, specially for large teams in which you cannot trust the next dev that does a PR to bump the version themselves.

Changes will be merged to master.

I think this is a situation that needs to be avoided.
So the second option Fail the build - so the developers would notice that they forgot to increase the version number, seems the most reasonable to me.

So far I cannot see a potential Conan feature to help with this. But implementing a merge-request or pre-merge check should be something like: pick the last version of the main branch, if it is not a prerelease -dev (or other convention) branch, and the coming changes do not change the version, then reject it.

The logic seems too custom and too CI-centered, that seems beyond Conan. But maybe you could leverage a Conan custom command for this check in a convenient way?

from conan.

@memsharded Thanks for the detailed answer. In fact we were already thinking about implementing a conan custom command. Just wanted to check whether it'd probably be worth making a PR against Conan itself (i.e. command line switch to fail the upload command in case it would create a new recipe revision).

However I understand that this most probably will not go through.

We will spend some more thoughts on it. I will update this ticket once we decided upon the way forward. Thanks. :)

from conan.

Just wanted to check whether it'd probably be worth making a PR against Conan itself (i.e. command line switch to fail the upload command in case it would create a new recipe revision).

However I understand that this most probably will not go through.

Yes, at the moment I don't think it is worth the complexity to be added for the value

We will spend some more thoughts on it. I will update this ticket once we decided upon the way forward. Thanks. :)

Sounds good thanks very much. Maybe if you move forward a custom command and share it, we would have an even better understanding of the feature implementation and possible risks/complexity to make it built-in.

from conan.

Sounds good thanks very much. Maybe if you move forward a custom command and share it, we would have an even better understanding of the feature implementation and possible risks/complexity to make it built-in.

Once we got approval from legal, we gladly would share that solution on GitHub :)

from conan.