Open PeteAudinate opened 7 months ago
Finally (unrelated to this) what is the best way of programatically applying a
core.*
config value?
Just to clarify this a bit: we'd like to apply different core.*
configurations on different machines. In this case, to enable the download cache for CI machines but not on developer machines.
Hi @PeteAudinate
You are right, there is some documentation pending for this feature.
My understanding is that it can be used on a CI node to prevent the need to repeatedly download dependencies from a Conan remote every time a job is run. Is it suitable for this use case?
Yes, this is the use case, trade local storage for network transfer. In practice for fast networks it is not a huge saving, because artifacts are kept as-is, so it is still necessary to unzip them, and that is the most expensive operation. But it will certainly save bandwidth in any case
More specifically, are there concurrency guarantees? For example, is safe to use even if multiple executors are running simultaneously on the same machine?
Yes, the download cache is designed to be concurrent, at the machine level (lock-synchronization use file system locks, which is an OS-level mechanism), so it might not work for network or shared drives across different machines, specially different OSs, but it should be able to use it from multiple concurrent Conan caches in the same machine.
Finally (unrelated to this) what is the best way of programatically applying a core.* config value? Conan v1 had conan config set. It looks like core config can't be overridden with profiles or commandline parameters. Does this mean the only way is something like echo "core.foo=bar" >> .conan2/global.conf, or is there a better way?
There are no global.conf
edition commands in 2.0, because the file is a jinja template and it is not possible to round-trip it.
But it should be doable to add some conditional on jinja to enable the conf only for specific machines, based for example in some environment variable. You can always have another different global.conf
and conan config install
that file only from CI. Note the conan config install
can be used for multiple origins, to install individual folders, etc.
Many thanks @memsharded for your quick reply, exactly what I was hoping to hear! Much appreciated.
I'd considered the extra conan config install, though then we'd have multiple global.conf
files that need keeping in sync. The templating option sounds promising though, thanks for the tip.
Thanks for the feedback. I am re-opening and moving to the docs repo, this would still be nice to document better.
What is your question?
The
core.download:download_cache
config is mentioned in https://docs.conan.io/2/reference/config_files/global_conf.html but not really described anywhere. Would it be possible to provide some more information for this feature?My understanding is that it can be used on a CI node to prevent the need to repeatedly download dependencies from a Conan remote every time a job is run. Is it suitable for this use case?
More specifically, are there concurrency guarantees? For example, is safe to use even if multiple executors are running simultaneously on the same machine?
Finally (unrelated to this) what is the best way of programatically applying a
core.*
config value? Conan v1 hadconan config set
. It looks likecore
config can't be overridden with profiles or commandline parameters. Does this mean the only way is something likeecho "core.foo=bar" >> .conan2/global.conf
, or is there a better way?Many thanks for your help.
Have you read the CONTRIBUTING guide?