-
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
[Feature Request] Options to use colcon user configuration override #97
Comments
This is a reasonable enhancement.
|
I don't think But I think developers can add another step before using this action to copy their
Interesting. Can you elaborate more on what's the improvement you envision? |
What I meant is doing something similar to action-ros-ci where we allow users to pass a file or a URL (see this for example).
Thought you might have some insight as to whether there would have to be a docker specific implementation if we want to add this feature to a docker action. |
Ah sure. That's something doable. |
Description
As of this writing,
action-ros-ci
composes and executescolcon
tasks in the following order:colcon mixin add default <repo>
(optional)colcon build
colcon lcov-result --initial
colcon test
colcon lcov-result
Beyond the common flow,
action-ros-ci
synthesizes default parameters to some tasks. For example,--event-handlers console_cohesion+ --symlink-install
always goes tocolcon build
. And when it comes to customize the tasks, typically it exposes the options case-by-case, for example, it currently takesextra-cmake-args
for developers to customize the--cmake-args
forcolcon build
.On the other side,
colcon
has a user configuration concept, where developers can define aYAML
file to describe what arguments should go tocolcon
command by default. For example, if I have the following file defined and specified in%COLCON_DEFAULTS_FILE%
,Then, whenever I run
colcon build
, those arguments will be automatically applied to mybuild
task. This approach gives much more flexible to extend thecolcon
common flow without maintaining many parameter interfaces.I am proposing that we can have a built-in
defaults.yaml
to capture all the good default parameters that we have today. And it exposes a new parameter, for example,colcon-defaults-file
which is for developers to override the default settings and to use their customized one. I envision that could be something like:Related Issues
#89
The text was updated successfully, but these errors were encountered: