Conversation
|
@nuclearsandwich or @tfoote , would you know how to integrate that last step:
I can show you the token/url at dockerhup that a cron job would have to poke to trigger the automated docker build. |
improve rosdeb ignore snippets correct prefix in setup scripts
nuclearsandwich
left a comment
There was a problem hiding this comment.
I gave the Dockerfile a local build and test.
I had to muse over the injected rosdep databases. I think they're a decent solution but I think the rosdep files might benefit from more descriptive file names than core and base. Especially because base.yaml is the filename with all the deps in it and I was very confused by how it is used here.
My first suggestions are prerequisites.yaml or prereqs.yaml for what is currently called core.yaml and ros2-archive.yaml or just ros2.yaml for what is currently base.yaml.
ros2/nightly/nightly/core.yaml
Outdated
| fastcdr: {ubuntu: []} | ||
| fastrtps: {ubuntu: []} | ||
| libopensplice67: {ubuntu: []} | ||
| libopensplice69: {ubuntu: []} |
There was a problem hiding this comment.
Using an empty list to satisfy these will require anyone who does want to test with OpenSplice (or RTI Connext DDS below) to explicitly install the package as rosdep will resolve to the empty package.
There was a problem hiding this comment.
Do you know of a alternate way with could avoid installing these transport venders without this injection? Is this list overcompensating, or is there only a smaller set of keys we just need to skip?
to explicitly install the package as rosdep will resolve to the empty package.
Users could also add a new files to /etc/ros/rosdep/sources.list.d/ that takes president, no? Something like 10-default.list, denoting priority like with udev rules? I thought of adding the the rosdep entries for the prereqs.yaml and ros2.yaml into a separate default.list file with higher priority, but then decided against deviating from the existing footprint of a conventional install for the sake of consistency.
There was a problem hiding this comment.
Is this list overcompensating, or is there only a smaller set of keys we just need to skip?
The list in the documentation is a bit overstuffed to work for both Bouncy and Crystal. In general rosdep doesn't have the ability to distinguish between an optional or opportunistic dependency (use this this if it's there but don't freak out if it isn't) and a mandatory dependency. So I don't know that there's anything to do about it. It's just something that downstream consumers of the Dockerfile need to know if their intent is to use OpenSplice or RTI Connext DDS.
There was a problem hiding this comment.
Suppose we use --skip-keys for the opportunistic dependencies and keep only the mandatory dependencies in the prereqs.yaml, would that satisfy both uses? Short of calling rosdep install on a core package, rosdep wouldn't necessarily try to install the opportunistic dependency from a parent package already ignored/installed on the system.
@ruffsl and I spoke offline about this. As an initial rollout I'll have a cron-job that's set to run two hours after the ci build is triggered which checks the status of the latest build and triggers a docker build on success. If that works well we'll move that cron job's home to ROS 2 CI. This is mostly to avoid managing the Docker Hub token securely and handling the fact that only ci.ros2.org and not a community deployment of our CI scripts ought to be triggering builds. |
I checked the build history of the docker hub repo, and haven't seen any triggers for the last 5 days. I tested the ruby script you shared offline on my host, and it triggered. Are you sure your cron job is up and scheduled? |
|
Ping @nuclearsandwich , I still don't see the automate DockerHub repo being triggered by that cron-job. I've just been waiting to merge this until that last bit of the pipeline is working. |
Hah. I didn't think it would work until after the PR merged so I've been waiting to turn it on 😅. I'll start it tonight and hopefully we'll see it tomorrow. |
|
Ok, I'll merg it now and also update the branch for the build context on the docker hub repo settings. |
This PR address #201 and addes a new Docker Image tag, 'nightly', to the ROS2 automated repo, providing a covenant installation of ci.ros2.org nightly builds. Some remaining action items:
Docs on remote build triggers for Docker Hub.
WIP tag you can try:
ping @mkhansen-intel