conan remote add : return code conflicting with travis and appveyor cache features

[piponazo]

Hi!

I have been recently trying the cache features existing in AppVeyor and Travis-ci. I think it is very convenient to use this feature when adding conan support in a project. With every commit we do in such projects (with conan support), travis and appveyor need to:

1. Install conan
2. Bring project dependencies with conan (Either fetch binaries from bintray or build packages during the build).

In both cases (travis and Appveyor) I end up doing something like this (I am just pasting here the AppVeyor example):

before_build:
- cmd: mkdir envs && cd envs
- cmd: python -m virtualenv conan
- cmd: conan/Scripts/activate
- cmd: python -m pip install conan==0.27.0
- cmd: cd ..
- cmd: conan remote add conan-pix4d https://api.bintray.com/conan/pix4d/conan && exit 0
- cmd: mkdir c:\Users\appveyor\.conan\profiles
- cmd: printf "os=Windows\narch=x86\ncompiler=Visual Studio\ncompiler.version=14\ncompiler.runtime=MD\nbuild_type=Release\n" > c:\Users\appveyor\.conan\profiles\release

...
cache:
  - c:\Users\appveyor\.conan\ -> conanfile.py  # conan profiles and dependencies
  - envs # Conan installation

However the command conan remote add fails when I enable the cache system because it detects that the remote is already there.

I could add an easy workaround in travis-ci to not stop the build when commands return non-zero values but in AppVeyor it seems trickier to workaround this.

My question is : Could conan remote add just print a warning and return 0, instead of failing. Would this affect to any well known workflow that you are using guys ?

[memsharded]

Quick question: Are the remotes the only configuration of the client you want to manage? Because if there is something else, like profiles, you would better manage it with conan config install and provide a repo. With that you will have reproducible environments, and it won't produce that error with conan remote add (remotes are completely redefined with config install)

If not, I don't think that there would be much user relying on that command returning an error, though it reads a bit inconsistent from the API point of view. What would be the behavior if you added the --insert argument, but the remote existed as latest remote? Just warn and left it pass unnoticed? Maybe an extra arg, with the semantics "not fail".

[piponazo]

I did not consider to use conan config install, but I looks like I could avoid this situation using this command and placing the conan cache in other directory (instead the default .conan/data).

I will play a bit more with these things and let you know if I can achieve my objective :)

[memsharded]

You might be fine keeping the default conan cache location. Defining the cache location, via CONAN_USER_HOME is mostly recommended for doing complete clean builds and install, but it doesn't look like your use case, is it?

[piponazo]

No, but I was thinking about having the conan cache location somewhere like in $HOME/conanCache and therefore I would not need to cache the complete $HOME/.cache directory but only the cache location. Then I could use conan config install to bring the configuration into the CI VMs, or just use my current existing code to configure it manually in each job.

The part I really want to cache is the conan cache.

[memsharded]

Ok, you might be using then the storage.path conan.conf property to define where your cache storage for packages is. Let me know how it goes with conan config install

[piponazo]

This approach of using conan config set storage.path seems to be enough for my case. I started to use it in Appveyor in it works perfectly :)

https://github.com/piponazo/exiv2/blob/appVeyorChanges/appveyor.yml

It should be easy to apply the same in Travis-ci. Thanks for you help!