Closed clalancette closed 2 years ago
Not sure if we should deploy it to the test buildfarm first or not, I'll wait for feedback before trying that.
I'm content with the GitHub Actions coverage for this change.
Note that the single failure in the RPM builds is caused by the poor state of RHEL builds in Rolling at the moment, and isn't affected by this change anyway.
I'm content with the GitHub Actions coverage for this change.
Thanks. I guess the next question is how we test this particular change. Should I attempt to deploy it to the test buildfarm? Should we just merge it and deploy to the real buildfarm? How do you want to proceed?
I guess the next question is how we test this particular change.
GitHub Actions is already testing this change in both devel and CI jobs for both ROS 1 and ROS 2. I think it's fine to be merged.
This change doesn't require deployment and will take effect immediately when merged.
This change doesn't require deployment and will take effect immediately when merged.
Ah, perfect. OK, thanks. I'm going to go ahead and merge this, and hopefully the CI jobs will start to get a bit happier.
Versions later than that are arbitrarily adding an additional local path, throwing all of our tools off.
This is meant to be a temporary fix until we completely remove the need to use pip to install any packages.
Signed-off-by: Chris Lalancette clalancette@openrobotics.org
Note that we are attempting to fix the CI jobs here, but the change is in
devel_task.Dockerfile.em
. As far as I can tell, the CI jobs reuse this Dockerfile template, so this is the correct place. Please let me know if I'm wrong about this. But because this is used on both the devel jobs and the CI jobs, the possibility for breakage is doubled.Also note that I've not tested this on a "live" buildfarm yet. Not sure if we should deploy it to the test buildfarm first or not, I'll wait for feedback before trying that.