Setup Conan Action Github Action

A GitHub Action to install and configure the Conan package manager in your workflow. This action provides a simple and flexible way to set up Conan with custom configurations and audit settings.

Features

• 🚀 Install any version of Conan 2.x
• ⚙️ Apply custom Conan configurations
• 🔐 Configure audit tokens for dependencies vulnerabilities scanning
• 🗂️ Cache Conan packages using GitHub cache
• 🔍 Support for custom Conan home
• 💪 Cross-platform support

Usage

Basic Usage

Install Conan, authenticate to Audit server, install custom configurations:

steps:
  - name: Checkout code
    uses: actions/checkout@v4

  - name: Install Conan
    uses: conan-io/setup-conan@v1
    with:
      audit_token: ${{ secrets.CONAN_AUDIT_TOKEN }}
      config_urls: |
        https://github.com/<org>/conan-config.git
        https://myrepo.com/conan-config.git

  - name: Install Conan dependencies
    run: conan install . --build=missing

Using Lockfiles

In order to ensure repeatability, the use of lockfiles on the consumer side is greatly encouraged:

  - name: Install Conan dependencies with lockfile
    run: conan install . --lockfile=conan.lock --lockfile-partial --lockfile-out=conan.lock --build=missing

Lockfiles ensure that Conan will resolve the same graph in a repeatable and consistent manner - thus making sure the same versions are used across multiple systems (CI, developers, etc).

Lockfiles are strict by default, that means that if there is some requires and it cannot find a matching locked reference in the lockfile, it will error and stop. For cases where it is expected that the lockfile will not be complete, as there might be new dependencies, the --lockfile-partial argument can be used.

By default, conan install will not generate an output lockfile, but if the --lockfile-out argument is provided, pointing to a filename, then a lockfile will be generated from the current dependency graph. The same lockfile can be cached or stored in the repository, so that it can be used in the future.

Options

This Github Action offers options inputs to execute extra steps just after installing Conan. This is useful for installing custom configurations or applying any other setup you need. It's possible to customize the action using the following options:

Option	Type	Description
version	string	Conan client version 2.x to be installed. By default, it's the latest version available.
home	string	A custom path to be used as Conan cache directory.
audit_token	string	The Conan audit token to authenticate to the Audit server with Conan.
config_urls	list	URLs of the Git repositories containing the custom Conan configurations to be installed.
cache_packages	boolean	Cache all stored Conan packages, under Conan cache, using Github cache support. See Caching Conan packages. false by default
cache_key	string	Extra segment added to the computed cache key, so each value gets its own cache. See Caching Conan packages.
use_venv	boolean	Use a virtual environment for the Python version set in the GitHub runner.
profile_detect	boolean	Automatically detect and use a Conan profile based on the GitHub runner environment. true by default
python_version	string	DEPRECATED Use the Python version set in the GitHub runner instead or a GitHub Action to set up Python.

Caching Conan packages

When cache_packages: true is set, the Conan packages folder (<conan-home>/p) is cached using actions/cache.

  - name: Install Conan
    uses: conan-io/setup-conan@v1
    with:
      cache_packages: true

  - name: Install Conan dependencies
    run: conan install . --build=missing

Each job saves its own cache entry and restores the most recent one saved on the same kind of runner (OS, architecture and runner image). Conan then builds or downloads anything missing, and the updated cache is saved when the job finishes.

Custom cache key

To separate caches, set cache_key. It is added as an extra segment to the computed key (conan-<cache_key>-<os>-<arch>-<image>-<run>), so each value gets its own cache and keeps the default behavior: the most recent entry with the same cache_key is restored, and a new one is saved when the job finishes. Use it to keep caches apart, for example one per job in a build matrix:

  - name: Install Conan
    uses: conan-io/setup-conan@v1
    with:
      cache_packages: true
      cache_key: ${{ matrix.build_type }}

For further information how caching works with GitHub Actions, see the actions/cache documentation.

Keeping the cache small

The cache keeps everything from earlier runs, including source and build folders, and every job uploads a new entry that counts towards the GitHub repository cache limit. If the size becomes a problem, Conan can remove those folders and the packages that have not been used recently. For example, in a step after the last Conan command:

  - name: Clean Conan cache
    run: |
      conan cache clean "*" --source --build --temp
      conan remove "*" --lru=4w --confirm

For further reference, please see the Conan cache documentation and the Conan remove documentation.

Using setup-python Action alongside setup-conan

If you are using the setup-python action in your workflow, you can use it alongside the setup-conan action. However, keep in mind PKG_CONFIG_PATH is configured by the setup-python action, so it may break the Conan build in case needing to consume .pc files generated by Conan. As workaround, you can clear the PKG_CONFIG_PATH environment variable before running the Conan install command:

  - name: Install Python
    uses: actions/setup-python@v4
    with:
      python-version: '3.x'

  - name: Clear PKG_CONFIG_PATH
    shell: bash
    run: echo "PKG_CONFIG_PATH=" >> $GITHUB_ENV

  - name: Install Conan dependencies
    run: conan install . --build=missing

For further details on how to manage enviroment variables of setup-python action, please refer to the setup-python documentation.

License

This project is licensed under the MIT License. See the LICENSE file for details.