Harmonize the tooling versions
Issue by HansUweRempler
Wednesday Dec 11, 2019 at 20:02 GMT
Originally opened as https://github.com/Bosch-AE-SW/cddk-oss/issues/425
Is your feature request related to a problem? Please describe. We have an inconsistency in our tooling versions.
Describe the solution you'd like Define versions for the quick start section and use the same in the CI Docker image for the following:
- [ ] arm-none-eabi Expected outcome: version number
- [ ] CMake Expected outcome: version number
- [ ] git Expected outcome: version number
- [ ] Use above versions in quick start guide http://kiso.rempler.de:1313/3.-user-guide/quick_start/ Expected outcome: updated docu
- [ ] Use above versions in CI Docker image https://github.com/Bosch-AE-SW/cddk-oss/blob/master/ci/docker/Dockerfile Expected outcome: Dockerfile with explicit version numbers
Describe alternatives you've considered n/a
Additional context Follow-up to https://github.com/Bosch-AE-SW/cddk-oss/issues/381
Comment by vkonov
Thursday Jan 16, 2020 at 15:36 GMT
Our Docker image uses Debian 10 as base and packages directly from the repository. To see the versions available for each package, we can use apt policy cmake:
root@e61f5e6190e8:/# apt policy cmake
cmake:
Installed: (none)
Candidate: 3.13.4-1
Version table:
3.13.4-1 500
500 http://deb.debian.org/debian buster/main amd64 Packages
There is only one option in the default configured repository in any given moment. If we specify exact version dependency for the package in the Dockerfile (for example: RUN apt install cmake=3.13.4-1), then a couple of days later the same Dockerfile might not build, because the upstream version is bumped to '3.13.4-3'. For us to have specific versions of tools in the docker image, we need to download them from somewhere else, manage the dependencies, etc. and I believe it's a bad idea.
Since the Docker images are versioned in the DTR, we can use this versioning from now on to verify newer packages with the tools we need and upgrade only once we are certain the new image is working as expected. Additionally we can use older base images and combinations of repos (for example in Debian stretch/oldstable cmake's package is 3.7.2) to verify we haven't broken any promises by saying "CMake 3.7 or later" in the docs.
For now I'd like to add the current versions as comments in the Dockerfile, but not enforce them there, spend some time to find and verify the lowest reasonable working version of each tool we are using (gcc, arm gcc, cmake, clang-*, make, etc.) and fill it in the docs. @HansUweRempler, @sebastianpfischer, @elbosch, @khalifima, @yongbosch what would you say?
PS: There is also an option for defining a meta-package for apt with all our dependencies that could say 'cmake between 3.7 and 3.12.8, gcc between 8.1 and 8.3' for example, but I think that's not necessary.