-
Notifications
You must be signed in to change notification settings - Fork 3
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
Add CI for rolling-version on humble/iron #30
Conversation
.github/workflows/humble-unstable-from-rolling-binary-build.yml
Outdated
Show resolved
Hide resolved
I'm not sure calling them What do you think? |
I was looking for a term not used in the ROS ecosystem (like testing), but unstable is something typical in the debian world. But I'm open for other namings. But for sure it will be unstable :D |
@saikishor any idea why building controller_manager fails here? https://github.com/ros-controls/ros2_control_ci/actions/runs/8133285062/job/22224687946?pr=30 |
This happened to me earlier in my machine, I believe the reason is it has an installed version of |
Ah, you are right. It is installed with gazebo_ros2_control (see question in initial post)
But do we have an issue with overriding the binary version? |
And at least one test fails on iron :(
|
Ideally, if we use the upstream ros2_control, ideally it should work directly. We need to test it. In worst case, we can skip this as you suggested as we don't have to add compatibility with it
I believe yes, we might have an issue with the overriding binary versions. I think it is better to do it without any installed versions. |
That's weird, it needs to work. I can take a look later |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@christophfroehlich Can't we use reusable builds in this case on Iron
and Humble
?
sorry, what do you mean? Creating workflows in all our repos to build it there? sure, but we didn't want it to run on PR or pushs, so why not to make it centralized here? |
Sure! BTW I've tested building the gazebo_ros2_control upstream version in the workspace, it seems to work directly without any modifications. |
OK. but now also the humble workflow fails because of the binary installation of the test assets. I'll have a look these days, how I could fix this |
Sure. Thank you |
@saikishor humble tests are failing because of this incompatibility ros-controls/ros2_control#913 (comment) |
I'm sorry about it. I didn't run the tests locally. I didn't think about the python part. You are right. If I find some time, I'll get onto it |
bf51aaf
to
5d46db9
Compare
This reverts commit 2c047bd.
The humble jobs fail because of gz_ros2_control, but this is not included anywhere. I think this is imported from the cache because the normal stack build and this job share the cache? not sure about the
I don't want to test gz/ign_ros2_control on humble here. (see the errors we have with the normal stack build). |
It is weird that it is caching |
Yes, that's definitively a problem. The target-ws is restored by the key
with
resulting in
Given the I don't quite understand, why it is empty, though, I would expect it to be Edit: Re-reading the documentation makes that clear:
Since we're not inside a step when defining the prefix it is empty. Edit2: Thinking about this that might be a larger problem. That means that an action run from a PR might re-use the cache from the master branch as long (as long as neither a |
No, I think the |
but using |
Not sure, but either way if the job id isn't available... |
Maybe we could use a composable action instead of a reusable workflow? Then the job-id would be unique as we would like it. |
True, but do we want that? I guess, we want that for PR runs, right? We could add
The restore key obviously has to go hand-in hand. |
That does indeed not sound too bad... |
PRs targeting master should use the cache from the master branch, but not the other way round. Gitlab does not use caches from PRs, how does that work with github? base_ref is what we want for PRs, but how would that work with scheduled builds or push events?
if the jobs are unique for different branches, then this would solve the case from above? |
Not necessarily. Caches from PRs and scheduled builds would still get mixed up. That might be fine in most cases, but might as well lead to strange errors as the one mentioned above. I guess, the cleanest would be:
This way on a PR it would search for a cache e.g. That could work, right? Changing things to actual actions rather than reusable workflow could be a separate discussion, I think. |
not sure, what will be
Maybe it just solves the problem above, because the github.job then names the calling job. |
Indeed that's an interesting question, but it should at lease be available in contrast to the job's name.
It will still not be available outside of the steps, right? Or will it because it is part of the step of the calling job? I guess it is time to prototype something up to verify, I probably won't find time for that before the weekend. |
.github/workflows/rolling-compatibility-humble-binary-build.yml
Outdated
Show resolved
Hide resolved
I added gz_ros2_control now for the humble build, and it succeeds now as well. I'd merge this PR if ok for you @fmauch @saikishor, or do you have other naming suggestions? |
Nice great job guys. CI is passing now! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with the naming. Thanks for the changes and good work guys @christophfroehlich @fmauch 👏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, that looks good.
Accompanying
Any better ideas for the names of the workflows?
I don't think we want to fight the releases of ignition/gz on humble. Therefore, I excluded ign/gz_ros2_control