Skip to content
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

Official ROS docker images do not ship compilers anymore #515

Closed
mathias-luedtke opened this issue May 28, 2020 · 14 comments
Closed

Official ROS docker images do not ship compilers anymore #515

mathias-luedtke opened this issue May 28, 2020 · 14 comments

Comments

@mathias-luedtke
Copy link
Member

mathias-luedtke commented May 28, 2020

This breaks most ROS_REPO=ros builds. See #514 as well.

@gavanderhoorn
Copy link
Member

According to @ruffsl in ROS Noetic Ninjemys Release:

Building tools (rosdep, compilers, git, rosinstall etc) are now in ros:noetic-ros-base and not part of the ros-core image anymore

@mathias-luedtke
Copy link
Member Author

@gavanderhoorn: Thanks for pointing this out! Mostly just read new posts..

It looks like this affected all other images as well.

@gavanderhoorn
Copy link
Member

[RFC] Restricting the size of ROS docker images has some more details.

It wasn't communicated too well though imo.

@mathias-luedtke
Copy link
Member Author

The *-base includes too many other dependencies, some undeclared dependencies would be shadowed..

My idea is now to install all needed tools "on-demand".
This way, industrial_ci could be used with any Debian-based image and support use cases like #459

It is not much left anyway: https://github.com/ros-industrial/industrial_ci/blob/master/industrial_ci/src/docker.sh#L235-L248

@ruffsl
Copy link

ruffsl commented May 28, 2020

[RFC] Restricting the size of ROS docker images has some more details

pinging @mikaelarguedas , as may be of interest

@mikaelarguedas
Copy link
Contributor

Thanks for the ping,

Would a set of images similar to what is described at osrf/docker_images#408 be of interest?

@mathias-luedtke
Copy link
Member Author

@mikaelarguedas: Yes, that could be a reasonable default choice, at least for the more recent distros :)

@mikaelarguedas
Copy link
Contributor

Good to know.

at least for the more recent distros :)

My initial feeling was to provide these images only for currently active ROS Distro/ OS Distro combinations but a case could be made for a wider set of tags.

If you have feedback or a wishlist of what tags / packages / configuration options you'd like to see in these images, please comment directly on the ticket

@mathias-luedtke
Copy link
Member Author

My initial feeling was to provide these images only for currently active ROS Distro/ OS Distro

Yes, that's fine :)

@gavanderhoorn
Copy link
Member

So, is this also related to this issue? Or is it something else?

@mathias-luedtke
Copy link
Member Author

mathias-luedtke commented May 31, 2020

@gavanderhoorn:

It is a regression of #516
And perhaps a problem with catkin-tools, which requires catkin for building non-catkin packages.

@mathias-luedtke
Copy link
Member Author

It is a regression of #516

It would have failed anyway without ROS_REPO=ros
#518 should fix it

@gavanderhoorn
Copy link
Member

It would have failed anyway without ROS_REPO=ros

I'm not sure I understand what you mean by this: the repository which had a failed build does have ROS_REPO=ros in the .travis.yml?

@mathias-luedtke
Copy link
Member Author

@gavanderhoorn:
Your repository has ROS_REPO=ros configured, which selects the official Docker image.
If you would have used the default (ROS_REPO=testing), then it would have built the custom Docker image and it would have failed even without the latest changes.

#525 works properly for both cases :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants