-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate Travis to use docker to test on recent linux distributions #96
Comments
traversaro
changed the title
Migrate to use docker to test on xenial, bionic and ideally the latest debian stable
Migrate Travis to use docker to test on xenial, bionic and ideally the latest debian stable
Jun 23, 2018
traversaro
changed the title
Migrate Travis to use docker to test on xenial, bionic and ideally the latest debian stable
Migrate Travis to use docker to test on recent linux distributions
Jun 23, 2018
traversaro
added a commit
to traversaro/robotology-superbuild
that referenced
this issue
Aug 20, 2018
This was referenced Aug 20, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the moment, the
robotology-superbuild
is being tested on Travis on a environment that is quite different from the one actually used by most users. A solution for this would be to move Linux builds to adocker
based environment, as done for example in the repo of the DART simulator https://github.com/dartsim/dart/blob/master/.travis.yml or in thewb-toolbox
robotology/wb-toolbox#136 .Given that the robotology-superbuild is supposed to build all its own non-system dependencies, I think it would make sense to just use some of the bare docker images, or perhaps refactor the images in https://github.com/robotology-playground/docker_images to just have an image with the system dependencies installed.
Given that we already have 4 builds (and I do not think it is wise to increase this number) I think we should test the superbuild on xenial, bionic and debian stable and testing.
A nice byproduct of this approach would be that we would refactor some of the build steps in
bash
scripts that could be reused also by the internal based Jenkins system @mbrunettini .The text was updated successfully, but these errors were encountered: