Skip to main content

Configuring your feedstock

You can configure how your feedstock is set up and built via the conda-forge.yml file that is present in its root directory. Additionally, a small subset of options are configured in recipe/conda_build_config.yaml.

Rerendering the feedstock after you modify this file is usually required and always a good idea (see Rerendering feedstocks).

recipe/conda_build_config.yaml​

While most settings are configured via conda-forge.yml, some settings are defined in recipe/conda_build_config.yaml. Unlike the former, this file can take advantage of selectors to match specific job configurations (e.g. CPU vs. GPU jobs).

Note that conda_build_config.yaml conventions specify that all values must be a list of strings, even if they only take one item. Multiple items are often only needed when filtering conditions with selectors.

channel_sources​

Each item must be a comma-separated list of channels to use to install dependencies for the recipe. Only conda-forge and its labels are supported.

Example:

recipe/conda_build_config.yaml
channel_sources:
  - conda-forge/label/A_rc,conda-forge

Search query for real-world examples.

channel_targets​

The channel where the packages will be uploaded to, expressed as a space-separated channel label pair. Defaults to ["conda-forge main"].

You only need to define this if you need to upload packages to a different label (e.g. RCs).

Example:

recipe/conda_build_config.yaml
channel_targets:
  - conda-forge A_rc

Search query for real-world examples

github_actions_labels​

Defines the value that will populate the runs-on field on Github Actions build workflows (e.g. ubuntu-latest).

You can use it to configure custom runners on self-hosted infrastructure, or override the default Github-hosted runner / VM image. Refer to conda-forge/admin-requests for possible values.

Each string must be one of:

  • A non-empty string that will be taken as is for the runs-on field(s) matching the selector for the respective item. Use this to configure self-hosted runners as needed. If the string contains the substring gpu, it may enable special behaviour on that platform (e.g. Docker GPU passthrough arguments).
  • A non-empty string that starts with self-hosted@ will be dealt with in the same way, but:
    • The self-hosted@ prefix will be removed.
    • Generic self-hosted labels will be appended to runs-on. This is needed in some providers that expect additional labels like self-hosted and Linux. Other providers either don't need it, or fail with these labels.
  • If absent or set to default, runs-on will use the pre-configured Github-hosted runner (e.g. ubuntu-latest for Linux x64).

Example:

recipe/conda_build_config.yaml
github_actions_labels:
- a-custom-self-hosted-provider  # [linux64]
# absent value for linux-aarch64 means it will use the default; same as:
# - default  # [linux and aarch64]

Search query for real-world examples

conda-forge.yml schema​

info
This documentation is autogenerated from conda-smithy's JSON Schema.

This model describes in detail the top-level fields in conda-forge.yml. General configuration options are described below within the Fields specifications. Additional examples are provided as part of the object description. Values and options are subject to change, and will be flagged as Deprecated as appropriate.

appveyor​

AppVeyor CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed.

azure​

Azure Pipelines CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed. For example:

azure:
    # flag for forcing the building all supported providers
    force: False
    # toggle for storing the conda build_artifacts directory (including the
    # built packages) as an Azure pipeline artifact that can be downloaded
    store_build_artifacts: False
    # limit the amount of CI jobs running concurrently at a given time
    # each OS will get its proportional share of the configured value
    max_parallel: 25

Freeing up disk space before a build is no longer configured here. Use the top-level workflow_settings.free_disk_space option instead, which accepts skip (default), quick or max.

Below is an example configuration for setting up a self-hosted Azure agent for Linux:

azure:
    settings_linux:
        pool:
            name: your_local_pool_name
            demands:
                - some_key -equals some_value
        workspace:
            clean: all
        strategy:
            maxParallel: 1

Below is an example configuration for adding a swapfile on an Azure agent for Linux and Windows:

azure:
    settings_linux:
        swapfile_size: 10GiB
    settings_win:
        variables:
            SET_PAGEFILE: 'True'

If you need more space on Windows, you can use C: at the cost of IO performance:

azure:
    settings_win:
        variables:
            CONDA_BLD_PATH: "C:\bld"
            MINIFORGE_HOME: "C:\Miniforge"

bot​

build_platform​

This is a mapping from the target platform to the build platform for the package to be built. For example, the following builds a osx-64 package on the linux-64 build platform using cross-compiling.

build_platform:
    osx_64: linux_64

Leaving this field empty implicitly requests to build a package natively. i.e.

build_platform:
    linux_64: linux_64
    linux_ppc64le: linux_ppc64le
    linux_aarch64: linux_aarch64
    osx_64: osx_64
    osx_arm64: osx_arm64
    win_64: win_64
    win_arm64: win_arm64

build_with_mambabuild​

Deprecated

build_with_mambabuild is deprecated, use conda_build_tool instead.

channel_priority​

The channel priority level for the conda solver during feedstock builds. For extra information, see the Strict channel priority section on conda documentation.

choco​

This parameter allows for conda-smithy to run chocoloatey installs on Windows when additional system packages are needed. This is a list of strings that represent package names and any additional parameters. For example,

choco:
    # install a package
    - nvidia-display-driver

    # install a package with a specific version
    - cuda --version=11.0.3

This is currently only implemented for Azure Pipelines. The command that is run is choco install {entry} -fdv -y --debug. That is, choco install is executed with a standard set of additional flags that are useful on CI.

circle​

Circle CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed.

clone_depth​

The depth of the git clone.

compiler_stack​

Deprecated

Compiler stack environment variable. This is used to specify the compiler stack to use for builds. Deprecated.

compiler_stack: comp7

conda_build​

Settings in this block are used to control how conda build runs and produces artifacts. An example of the such configuration is:

conda_build:
    pkg_format: 2
    zstd_compression_level: 16
    error_overlinking: False

conda_build_tool​

Use this option to choose which tool is used to build your recipe.

conda_forge_output_validation​

This field must be set to True for feedstocks in the conda-forge GitHub organization. It enables the required feedstock artifact validation as described in Output Validation and Feedstock Tokens.

conda_install_tool​

Use this option to choose which tool is used to provision the tooling in your feedstock. Defaults to micromamba.

If conda or mamba are chosen, the latest Miniforge will be used to provision the base environment. If micromamba or pixi are chosen, Miniforge is not involved; the environment is created directly by micromamba or pixi.

conda_solver​

Choose which conda solver plugin to use for feedstock builds.

config_version​

The conda-smithy config version to be used for conda_build_config.yaml files in recipe and conda-forge-pinning. This should not be manually modified.

docker​

This is a mapping for Docker-specific configuration options. Some options are

docker:
    executable: docker
    command: "bash"

drone​

Drone CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed.

exclusive_config_file​

Exclusive conda-build config file to replace conda-forge-pinning. For advanced usage only.

github​

Mapping for GitHub-specific configuration options. The defaults are as follows:

github:
    user_or_org: conda-forge
    repo_name: "my_repo"
    branch_name: main
    tooling_branch_name: main

github_actions​

GitHub Actions CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed.

idle_timeout_minutes​

Configurable idle timeout. Used for packages that don't have chatty enough builds. Applicable only to circleci and travis.

idle_timeout_minutes: 60

linter​

Settings in this block are used to control how conda smithy lints. An example of the such configuration is:

linter:
    skip:
        - lint_noarch_selectors

matrix​

Deprecated

Build matrices were used to specify a set of build configurations to run for each package pinned dependency. This has been deprecated in favor of the provider field. More information can be found in the Build Matrices section of the conda-forge docs.

max_py_ver​

Deprecated

Maximum Python version. This is used to specify the maximum Python version to use for builds. Deprecated.

max_py_ver: 37

max_r_ver​

Deprecated

Maximum R version. This is used to specify the maximum R version to use for builds. Deprecated.

max_r_ver: 34

min_py_ver​

Deprecated

Minimum Python version. This is used to specify the minimum Python version to use for builds. Deprecated.

min_py_ver: 27

min_r_ver​

Deprecated

Minimum R version. This is used to specify the minimum R version to use for builds. Deprecated.

min_r_ver: 34

noarch_platforms​

Platforms on which to build noarch packages. The preferred default is a single build on linux_64.

noarch_platforms: linux_64

To build on multiple platforms, e.g. for simple packages with platform-specific dependencies, provide a list.

noarch_platforms:
  - linux_64
  - win_64

os_version​

This key is used to set the OS versions for linux_* platforms. Valid entries map a linux platform and arch to either alma9, alma8 or cos7. For CUDA 11.8 images, a choice equivalent to alma8 is ubi8.

Currently alma9 is the default, though alma10 is available for opt-in where necessary. rocky10 may be added in the future.

Note that the image version does not imply a matching glibc requirement (which can be set using c_stdlib_version in recipe/conda_build_config.yaml).

If you need to opt into older images, here's an example how to do it:

os_version:
    linux_64: cos7
    linux_aarch64: cos7
    linux_ppc64le: cos7

package​

Default location for a package feedstock directory basename.

private_upload​

Whether to upload to a private channel.

private_upload: False

provider​

The provider field is a mapping from build platform (not target platform) to CI service. It determines which service handles each build platform. If a desired build platform is not available with a selected provider (either natively or with emulation), the build will be disabled. Use the build_platform field to manually specify cross-compilation when no providers offer a desired build platform.

The following are available as supported build platforms:

  • linux_64
  • osx_64
  • osx_arm64
  • win_64
  • win_arm64
  • linux_aarch64
  • linux_ppc64le
  • linux_riscv64
  • linux_s390x
  • linux_armv7l

The following CI services are recognized:

  • azure
  • github_actions
  • circle (deprecated)
  • travis (deprecated)
  • appveyor (deprecated)
  • None or False to disable a build platform.
  • default to choose an appropriate CI (only if available)
  • native to choose an appropriate CI for native compiling (only if available)
  • emulated to choose an appropriate CI for compiling inside an emulation of the target platform (only if available)

For example, making explicit that linux_64 builds on github actions, osx_64 builds on azure, and switching win_64 to Appveyor:

provider:
    linux_64: github_actions
    osx_64: azure
    win_64: appveyor

Currently, x86_64 platforms are enabled, but other build platforms are disabled by default. i.e. an empty provider entry is equivalent to the following:

provider:
    linux_64: github_actions
    osx_64: azure
    win_64: github_actions
    linux_ppc64le: None
    linux_aarch64: None
    osx_arm64: None
    win_arm64: None

To enable linux_ppc64le and linux_aarch64 add the following:

provider:
    linux_ppc64le: default
    linux_aarch64: default

recipe_dir​

The relative path to the recipe directory. The default is:

recipe_dir: recipe

remote_ci_setup​

This option can be used to override the default conda-forge-ci-setup package. Can be given with ${url or channel_alias}::package_name, defaults to conda-forge channel_alias if no prefix is given.

remote_ci_setup: ["conda-forge-ci-setup=4", "conda-build>=26.3"]

secrets​

List of secrets to be used in GitHub Actions. The default is an empty list and will not be used.

shellcheck​

Shell scripts used for builds or activation scripts can be linted with shellcheck. This option can be used to enable shellcheck and configure its behavior. This is not enabled by default, but can be enabled like so:

shellcheck:
    enabled: True

skip_render​

This option specifies a list of files which conda smithy will skip rendering. This is useful for files that are not templates, but are still in the recipe directory. The default value is an empty list [], which will consider that all files can be rendered. For example, if you want to skip rendering the .gitignore and LICENSE.txt files, you can add the following:

skip_render:
    - .gitignore
    - LICENSE.txt

templates​

This is mostly an internal field for specifying where template files reside. You shouldn't need to modify it.

test​

This is used to configure on which platforms a recipe is tested.

test: native_and_emulated

Will do testing only if the platform is native or if there is an emulator.

test: native

Will do testing only if the platform is native.

test_on_native_only​

Deprecated

This was used for disabling testing for cross-compiling.

warning
This has been deprecated in favor of the top-level `test` field. It is now mapped to `test: native_and_emulated`.

travis​

Travis CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed.

trusted_publishers​

CI jobs allowed to ask conda-forge to update this feedstock's version via conda-forge's trusted publishing. A job sends the identity token its provider issued it and the claims are checked against these entries, so no secret is held by either side. Only the version is under the requester's control; the sources come from the recipe as always.

trusted_publishers:
  - provider: github
    repository: DIRACGrid/DIRAC
    repository_owner_id: 694842
    workflow: deploy.yml
  - provider: gitlab
    url: https://gitlab.cern.ch
    project_path: lhcb-core/LbEnv
    namespace_id: 783
    ref_type: tag
    ref_protected: true

upload_on_branch​

This parameter restricts uploading access on work from certain branches of the same repo. Only the branch listed in upload_on_branch will trigger uploading of packages to the target channel. The default is to skip this check if the key upload_on_branch is not in conda-forge.yml. To restrict uploads to the main branch:

upload_on_branch: main

woodpecker​

Woodpecker CI settings. This is usually read-only and should not normally be manually modified. Tools like conda-smithy may modify this, as needed.

workflow_settings​

Per-workflow settings.

workflow_settings:
  store_build_artifacts:
    # there can be at most one value for each workflow
    - provider: github_actions
      platform: linux_aarch64
      value: true
    - platform: [linux_64, win_64]  # OR
      value: true