-
Notifications
You must be signed in to change notification settings - Fork 53
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 colcon-mixin-name-build and colcon-mixin-name-test overrides #526
Conversation
Codecov Report
@@ Coverage Diff @@
## master #526 +/- ##
==========================================
- Coverage 42.42% 40.19% -2.24%
==========================================
Files 2 2
Lines 198 209 +11
Branches 36 40 +4
==========================================
Hits 84 84
- Misses 114 125 +11
Continue to review full report at Codecov.
|
Signed-off-by: ddengster <ed.fan@osrfoundation.org>
Signed-off-by: ddengster <ed.fan@osrfoundation.org>
Signed-off-by: ddengster <ed.fan@osrfoundation.org>
colcon-mixin-name-test: | ||
default: "" | ||
description: "Colcon mixin to be used to as input to colcon test(empty means no mixin). Overrides colcon-mixin-name" | ||
required: false |
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.
It wouldn't be backwards compatible, but maybe colcon-mixin-name
should just be removed in this case.
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.
yea it'd be a breaking change; i'm content with leaving it be for now. let me know if you'd like this change in the PR
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 think either way should be fine. We can always remove colcon-mixin-name
later and avoid breaking changes for now.
I'll let the people who actually have approval rights/write access take it from here and decide.
it does run them: https://github.com/ros-tooling/action-ros-ci/pull/526/checks?check_run_id=1868379801#step:14:3 btw you'll have to either sign-off the two commits resulting from my code suggestions, or just squash everything and sign-off |
Signed-off-by: ddengster <ed.fan@osrfoundation.org>
Signed-off-by: ddengster <ed.fan@osrfoundation.org>
Signed-off-by: ddengster <ed.fan@osrfoundation.org>
Co-authored-by: Christophe Bedard <bedard.christophe@gmail.com> Signed-off-by: ddengster <ed.fan@osrfoundation.org>
Btw if you change this to "Fixes #x" or "Closes #x" then github can auto-close for you - it only accepts a few specific verbs. Sorry for being a little slow to get to this, but per my comment #525 (comment) - I think this API could be more generic (and make the API actually be smaller overall). What do you think about this suggestion? I personally like it better than adding more specific arguments, as that can get out of control as we add more access points. It's the approach used in https://github.com/ros-tooling/cross_compile#package-selection-and-build-customization |
See reply #525 (comment). Should we merge this PR if there's no solution there? |
Thanks for the patience - I was able to get a proof of concept solution working that I think is acceptable. PR here #555 - see the PR description for what's going on. Specifically check out the run output here https://github.com/ros-tooling/action-ros-ci/pull/555/checks?check_run_id=2009781903#step:6:28 As long as we document the usage - "Use a leading | for multiline, must be valid JSON", I think this solution could work really well. What do you think? |
That looks nice. Since there's overlap between the settings/values in a colcon defaults file and the action's inputs, do we offer both options and have one override the other, e.g. I'm asking this because having multiple ways of doing something is generally not a good thing, UX-wise. Perhaps we should open a separate issue to talk about this. |
Yes, I'm thinking it would be best to phase out the duplicated options. For now, defaults will always be overridden by an explicit command line option, so there is a clear behavior |
@emersonknapp what should we do with this PR and #525? It's now possible to do what this PR aims to enable (use Personally, maybe overriding what I said above, I'd be fine with merging this PR, since using mixins is a common enough use-case. We could draw the line here (wrt duplicate options/flags in inputs and |
I would prefer to have users use the colcon defaults option for all mixins now - I'd rather remove |
Use case implemented by #591 |
Fixes #525