Conan: [question] How to promote updates to users?

[unzap]

This contains two questions related to updates in general.

version number and updates

When packaging pre-built binaries (CI snapshots) for different projects
and build configurations the reference will look something like:

project/1.0@user/rc1

When the reference stays as-is but the binary content will change
the sha1 changes and consumers can get new snapshots as updates:

conan install --update <reference>

But if I utilize the version number field to contain the snapshot number:

project/1.0.00001@user/rc1
project/1.0.00002@user/rc1
project/1.0.00003@user/rc1

Then a new package repository will be created and users can't get updates for
the original snapshot anymore (reference is different). Is there some way around this?
I'd like to offer users a change to just update the existing snapshot build including
all the dependencies (requires).

How to promote updates with dependencies?

Documentation says that conan copy can be used to promote updates:

conan copy project/1.0@user/rc1 user/final

This looks a very useful feature (e.g. flag a release and avoid re-packaging)
but I noticed that the "requirements" are not updated accordingly. Ok, this can
be tricky as the dependencies may follow completely different user/channel rules
as the main project. But is there any way to tackle this use case, which I think
can be quite common:

project/1.0@user/rc1
    requires: "A/1.0@user/rc1", "B/1.0@user/rc1"

A/1.0@user/rc1
    requires: "C/1.0@user/rc1"

conan copy project/1.0@user/rc1 user/final

The result would look like:

project/1.0@user/final
    requires: "A/1.0@user/final", "B/1.0@user/final"

A/1.0@user/final
    requires: "C/1.0@user/final"

[unzap]

@lasote @memsharded any comments or have I missed some part of the documentation :) ?

[Minimonium]

What about using
https://docs.conan.io/en/latest/reference/commands/misc/alias.html ?

[uilianries]

Hi!

Did you try alias ?

I've used copy to promote packages when there is an "official" username (e.g. company name). But the problem that I see is on the review stage, when the developer needs to freeze its recipe to be analyzed before to promote.

Using alias you can update your snapshot version and all users will get the latest version.

[unzap]

Hi @Minimonium @uilianries , thanks for the tip.

I tested a bit with the "alias" and it seems to do the trick:

> conan alias project/1.0@user/rc1 project/1.0@user/final
> conan search

project/1.0@user/final
project/1.0@user/rc1
A/1.0@user/rc1
B/1.0@user/rc1
C/1.0@user/rc1

But I found the following not "working":

> conan search project/1.0@user/final    # this is the alias for /rc1

Existing packages for recipe project/1.0@user/final:

There are no packages for reference 'project/1.0@user/final', but package recipe found.

@lasote @memsharded is there any way to read the same meta information from alias? I think for end users it is important to be able to list all the settings, options etc. used for building the package even if the package reference was an alias?

Given the "alias" option, would the work flow below work correctly by "conan rules" (simplified example)?

Producer:

project/1.0-001@user/rc1 # nightly snapshot, depends on A/1.0-001 and B/1.0-001
A/1.0-001@user/rc1 # nightly snapshot
B/1.0-001@user/rc1 # nightly snapshot

> conan alias project/1.0@user/rc1-latest project/1.0-001@user/rc1

Consumer:

> conan install project/1.0@user/rc1-latest

Producer:

project/1.0-002@user/rc1 # nightly snapshot, depends on A/1.0-002 and B/1.0-002
A/1.0-002@user/rc1 # nightly snapshot
B/1.0-002@user/rc1 # nightly snapshot

> conan alias project/1.0@user/rc1-latest project/1.0-002@user/rc1
> conan remove project/1.0-001@*/*
> conan remove A/1.0-001@*/*
> conan remove B/1.0-001@*/*

Consumer:

> conan update project/1.0@user/rc1-latest  # should point to latest snapshot

[danimtb]

Hi @unzap

I think the new revisions feature (currently under development and testing) is what you are looking for.

In the meantime the suggested approach with alias could be used as long as you have the bumping of the version in the alias automated in CI (everytime there is a new version of a certain reference, the alias is updated pointing to the new version).

[danimtb]

Hi @unzap,

Good news! Conan 1.13 comes with the new revisions feature I was talking about. Read how it works in the release blog post. Hope you find it useful https://blog.conan.io/2019/03/12/New-conan-release-1-13.html

[unzap]

@danimtb thanks!

[unzap]

@danimtb, how the revision feature "maps" to Artifactory's "maxUniqueSnapshots" feature? These two sound a bit similar to me?

[danimtb]

While the mechanism for snapshots in the server is quite similar to the concept of Artifactory, they are not part of the package management model. This means that you would have to request the specific snapshot from the server every time or even declare that in the requirements of a recipe.

The revisions feature is the same idea but integrated with a new protocol in Conan itself, meaning that each revision is not only something about the server but already part of the Conan workflow when installing recipes and packages.

[unzap]

How would one configure the repository in Artifactory, if the aim is to use the internal revisions feature but only a few latest revisions (snapshot builds) are needed? And as a plus the old revisions would be cleaned automatically?

maxUniqueSnapshots = 1? How to auto-cleanup old revisions?

[danimtb]

There are different strategies to achieve that although I think the max unique snapshots will not be valid in this case as revisions create new files that are considered different.

Please check this link for other approaches on how to achieve what you are proposing: https://jfrog.com/knowledge-base/artifactory-cleanup-methods-how-do-i-delete-old-artifacts/