| Service | OS | Status |
|---|---|---|
| Jenkins | Linux |
Dockerfiles for different GCC and Clang compiler versions. You can use these images directly in your project or with the conan-package-tools project.
⚠️ Warning: The images listed below are intended for generating open-source library packages and we cannot guarantee any kind of stability. We strongly recommend using your own generated images for production environments taking the dockerfiles in this repository as a reference.
There are two main folders which store our Dockerfiles legacy and modern.
As the name suggests, they are our legacy, a few images are still used by Conan Center, and all of them are superseded by the Moderns images.
Please, read the table below to understand which images are still maintained. All images produced by legacy only contain the compiler name, version, and arch, e.g. conanio/gcc10, conan/gcc7-armv7hf
Also, all non-x64 images are no longer supported. Because we do not use them on Conan Center, we do not have maintainers/experts enough to keep them, and we have only a few users looking for them.
For personal projects, avoid the legacy folder.
The Modern folder stores our new design, re-using the same Dockerfile for any compiler version. Consider this folder for new projects, as we will maintain it for a long period. All images generated by modern design are named using the compiler name, version, distro and its version, e.g. conanio/gcc11-ubuntu18.04. Only x64 is supported. Please, read the issue #205 to obtain more information about our decision related to design, distro version, glibc support, system package and compilers.
The images are uploaded to Docker Hub:
| Version | Arch | Status, Life cycle |
|---|---|---|
| conanio/gcc46: gcc 4.6 | x86_64 | |
| conanio/gcc48: gcc 4.8 | x86_64 | |
| conanio/gcc48-x86: gcc 4.8 | x86 | |
| conanio/gcc49: gcc 4.9 | x86_64 | |
| conanio/gcc49-x86: gcc 4.9 | x86 | |
| conanio/gcc49-armv7: gcc 4.9 | armv7 | |
| conanio/gcc49-armv7hf: gcc 4.9 | armv7hf | |
| conanio/gcc52: gcc 5.2 | x86_64 | |
| conanio/gcc53: gcc 5.3 | x86_64 | |
| conanio/gcc54: gcc 5.4 | x86_64 | |
| conanio/gcc63: gcc 6.3 | x86_64 | |
| conanio/gcc64: gcc 6.4 | x86_64 | |
| conanio/gcc72: gcc 7.2 | x86_64 |
GCC>=5 is ABI compatible for minor versions. To solve multiple minors, there are generic images by major version. If you are interested to understand the motivation, read this issue.
| Version | Arch | Status, Life cycle |
|---|---|---|
| conanio/clang38: clang 3.8 | x86_64 | |
| conanio/clang39-x86: clang 3.9 | x86 | |
| conanio/clang39: clang 3.9 | x86_64 | |
| conanio/clang40-x86: clang 4.0 | x86 | |
| conanio/clang40: clang 4.0 | x86_64 | |
| conanio/clang50-x86: clang 5.0 | x86 | |
| conanio/clang50: clang 5.0 | x86_64 | |
| conanio/clang60-x86: clang 6.0 | x86 | |
| conanio/clang60: clang 6.0 | x86_64 | |
| conanio/clang7-x86: clang 7 | x86 | |
| conanio/clang7: clang 7 | x86_64 | |
| conanio/clang8-x86: clang 8 | x86 | |
| conanio/clang8: clang 8 | x86_64 | |
| conanio/clang9-x86: clang 9 | x86 | |
| conanio/clang9: clang 9 | x86_64 | |
| conanio/clang10: clang 10 | x86_64 | |
| conanio/clang10: clang 11 | x86_64 | ✅ Supported |
We cannot re-distribute Windows docker images, since Visual Studio Build Tools is licensed as supplemental license for Visual Studio. For more information, see https://github.com/Microsoft/vs-dockerfiles#samples. However, you can download the Docker recipe and build.
| Version | Arch | Status, Life cycle |
|---|---|---|
| conanio/android-clang8: Android clang 8 x86_64 | x86_64 | |
| conanio/android-clang8-x86: Android clang 8 x86 | x86 | |
| conanio/android-clang8-armv7: Android clang 8 ARMv7 | armv7 | |
| conanio/android-clang8-armv8: Android clang 8 ARMv8 | armv8 |
To learn how to build using Android docker images, please, visit official docs.
Conan Docker Tools provides an image version with only Conan Server installed, very useful for the cases it is necessary to run a server without touching the host.
| Version | Arch | Status, Life cycle |
|---|---|---|
| conanio/conan_server | ANY | ✅ Supported |
Conan Docker Tools provides an image version with only Conan client installed, very useful for the cases it is necessary to run a command without touching the host.
| Version | Arch | Status, Life cycle |
|---|---|---|
| conanio/conan | ANY | ✅ Supported |
conanio/gcc7-centos6 is a special image version based on CentOS 6, GCC 7 and glibc 2.12 (very old glibc version). This is intended to build executables that run almost on any Linux because glibc guarantees backward compatibility. You can use this image to build your Conan build tools packages (build_requires). This image is ONLY able to build x86_64 binaries.
conanio/gcc7-centos6-x86 is a special image version based on CentOS 6 i386, GCC 7 and glibc 2.12 (very old glibc version). This is intended to build executables that run almost on any Linux because glibc guarantees backward compatibility. You can use this image to build your Conan build tools packages (build_requires). This image is ONLY able to build x86 binaries.
⚠️ Warning: CentOS 6 reached EOL and won't be longer maintained. Thus, bothconanio/gcc7-centos6andconanio/gcc7-centos6-x86are still available for download, but no new version will be released.
These Docker images can be used to build your project using the Travis CI CI service, even if you are not using Conan. It's always recommended to build and test your C/C++ projects in a Docker image running in Travis:
- Travis CI images are old, so installing a newer version of gcc and the needed tools can be hard. Check this thread.
- The generated binaries will use the old libc/libstdc++ installed in the system, so ABI incompatibilities can occur if you use these packages in more modern distributions.
To setup your project, copy the contents of the folder example_project_test to your project. You need to modify:
.travis.yml: enable or disable additionalGCCorClangversions by adding more entries to the matrix using DOCKER_IMAGE.travis/run_project_build.sh: adapt to build or test your project
.travis.yml
os: linux
services:
- docker
sudo: required
language: python
env:
matrix:
- DOCKER_IMAGE=conanio/gcc8 # GCC 8.x
- DOCKER_IMAGE=conanio/clang7 # Clang 7
matrix:
include:
- os: osx
osx_image: xcode11.3 # Apple-Clang 11.0
language: generic
env:
before_install:
- ./.travis/before_install.sh
install:
- ./.travis/install.sh
script:
- ./.travis/run.sh.travis/run_project_build.sh. Change it according your project build needed commands:
#!/bin/bash
rm -rf build && mkdir -p build && cd build
conan install ../ --build=missing
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release ..
cmake --build .If you use Jenkins to build your packages and also you use Jenkins Slave to run each docker container, you could use our Docker images prepared for Jenkins Slave. Those images run the script jenkins-slave.sh, which starts the slave during the container entrypoint.
| Version | Arch | Status, Life cycle |
|---|---|---|
| conanio/clang39-jnlp-slave-x86: clang 3.9 | x86 | |
| conanio/clang39-jnlp-slave: clang 3.9 | x86_64 | |
| conanio/clang40-jnlp-slave-x86: clang 4.0 | x86 | |
| conanio/clang40-jnlp-slave: clang 4.0 | x86_64 | |
| conanio/clang50-jnlp-slave-x86: clang 5.0 | x86 | |
| conanio/clang50-jnlp-slave: clang 5.0 | x86_64 | |
| conanio/clang60-jnlp-slave-x86: clang 6.0 | x86 | |
| conanio/clang60-jnlp-slave: clang 6.0 | x86_64 | |
| conanio/clang7-jnlp-slave-x86: clang 7 | x86 | |
| conanio/clang7-jnlp-slave: clang 7 | x86_64 | |
| conanio/clang8-jnlp-slave-x86: clang 8 | x86 | |
| conanio/clang8-jnlp-slave: clang 8 | x86_64 | |
| conanio/clang8-jnlp-slave-x86: clang 9 | x86 | |
| conanio/clang8-jnlp-slave: clang 9 | x86_64 | |
| conanio/clang8-jnlp-slave: clang 10 | x86_64 | |
| conanio/clang8-jnlp-slave: clang 11 | x86_64 | ✅ Supported |
You can also use the images locally to build or test packages, this is an example command:
docker run -v/tmp/.conan:/home/conan/.conan conanio/gcc63 bash -c "conan install lz4/1.8.3@bincrafters/stable --build missing"This command is sharing /tmp/.conan as a shared folder with the conan home, so the Boost package will be built there.
You can change the directory or execute any other command that works for your needs.
If you are familiarized with Docker compose, also it's possible to start a new container by:
docker-compose run -v/tmp/.conan:/home/conan/.conan gcc63 bash -c "conan install lz4/1.8.3@bincrafters/stable --build missing"The images are already built and uploaded to the conanio Docker Hub account. If you want to build your own images you can do it by:
$ python build.pyThe script build.py will build, test and deploy your Docker image. You can configure all stages by environment variables listed below.
Also, you can build only a version:
E.g Build and test only a image with Conan and gcc-6
$ CONAN_GCC_VERSIONS="6" python build.pyE.g Build and test only the images with Conan and clang-8, clang-9
$ CONAN_CLANG_VERSIONS="8,9" python build.pyE.g Build and test only the images with Conan and Visual Studio 14.0 (It ONLY works on Windows).
$ CONAN_VISUAL_VERSIONS="14.0" python build.pyThe stages that compose the script will be described below:
The first stage collect all compiler versions listed in CONAN_GCC_VERSIONS for Gcc, in CONAN_CLANG_VERSIONS for Clang and CONAN_VISUAL_VERSIONS for Visual Studio. If you do not set any compiler version, the script will execute all supported versions for Gcc and Clang.
You can configure only a compiler version or a list, by these variables. If you skipped a compiler list, the build will not be executed for that compiler.
The image tag can be configured by DOCKER_BUILD_TAG. Build default will used latest.
Each image created on this stage will be tagged as DOCKER_USERNAME/conan_compiler_version.
The image will not be removed after build.
The second stage runs the new image created and builds the Conan package gtest/1.8.1.
The same build variables, as CONAN_GCC_VERSIONS, CONAN_CLANG_VERSIONS and CONAN_VISUAL_VERSIONS are used to select the compiler and version.
All tests build the package gtest/1.8.1, for x86 and x86_64.
Gcc images use libstdc++.
Clang images use libc++ and libstdc++.
Visual Studio images use MD for runtime.
The packages created on test, are not uploaded to Conan server, Are just to validate the image.
The final stage pushes the image to docker server (hub.docker). DOCKER_UPLOAD should be true.
The login uses DOCKER_LOGIN_USERNAME and DOCKER_PASSWORD to authenticate.
E.g Upload Docker images to Docker hub, after build and test:
$ DOCKER_USERNAME="conanio" DOCKER_PASSWORD="conan" DOCKER_UPLOAD="TRUE" python build.pyYou can also use environment variables to change the behavior of Conan Docker Tools.
This is especially useful for CI integration.
Build and Test variables:
- GCC_VERSIONS: GCC versions to build, test and deploy, comma separated, e.g. "4.6,4.8,4.9,5.2,5.3,5.4,6.2.6.3"
- CLANG_VERSIONS: Clang versions to build, test and deploy, comma separated, e.g. "3.8,3.9,4.0"
- VISUAL_VERSIONS: Visual Studio versions to build, test and deploy, comma separated, e.g. "14,15"
- DOCKER_BUILD_TAG: Docker image tag, e.g "latest", "0.28.1"
- SUDO_COMMAND: Sudo command used on Linux distros, e.g. "sudo"
- DOCKER_CACHE: Allow to cache docker layers during the build, to speed up local testing
- DOCKER_CROSS: Cross-compiling image prefix, currently only "android" is supported
Upload related variables:
- DOCKER_USERNAME: Your Docker username to authenticate in Docker server.
- DOCKER_PASSWORD: Your Docker password to authenticate in Docker server
- DOCKER_UPLOAD: If attributed to true, it will upload the generated docker image, positive words are accepted, e.g "True", "1", "Yes". Default "False"
- BUILD_CONAN_SERVER_IMAGE: If attributest to true, it will build and upload an image with the conan_server
- DOCKER_UPLOAD_ONLY_WHEN_STABLE: Only upload only when is master branch.