ros-tooling / action-ros-ci Goto Github PK
View Code? Open in Web Editor NEWGithub Action to build and test ROS 2 packages using colcon
License: Apache License 2.0
Github Action to build and test ROS 2 packages using colcon
License: Apache License 2.0
@zmichaels11 commented on Tue Nov 19 2019
It looks like ubuntu build returns a false positive success when ros1_bridge is used
ros2/rosbag2_bag_v2#10 (comment)
This might be caused by ros1_bridge
failing to build and might be resolved by Issues #21 and #20.
The GitHub action should have reported a failure.
The GitHub action reported success.
See the following rosbag2_bag_v2 CI run.
When someone wants to contribute to our repos from a forked repo, the tests will fail.
Initial report in ros-tooling/setup-ros2#16 duplicated below.
Noticed this issue in ros-tooling/cross_compile#37.
In this PR, the base branch is from a fork of the repo where the action runs.
PR base branch: https://github.com/aws-ros-dev/cross_compile/tree/allabana/doc-fixes
Main repo: https://github.com/ros-tooling/cross_compile
Instead of cloning the fork and checking out the source branch, the action looks for the branch in the parent repo. When it is unable to find the branch, the test errors out.
Test log output:
repositories:
cross_compile:
type: git
url: "https://github.com/ros-tooling/cross_compile.git"
version: "allabana/doc-fixes"
EOF
=== src/cross_compile (git) ===
Could not checkout ref 'allabana/doc-fixes': error: pathspec 'allabana/doc-fixes' did not match any file(s) known to git
##[error]The process 'bash' failed with exit code 1
##[error]Node run failed with exit code 1
According to this document:
Workflows do not run on private base repositories when you open a pull request from a forked repository.
It explains that github actions must be turned in the forked repo. Reason it doesn't occur automatically is because there are some secrets that need to be transferred which is not safe.
Further discussion here.
2.19.0
to 2.19.1
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
@typescript-eslint/eslint-plugin is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
The new version differs by 5 commits.
1c8f0df
chore: publish v2.19.1
4c12dac
fix(typescript-estree): ts returning wrong file with project references (#1575)
e9cf734
docs(eslint-plugin): fix typo in readme
10d86b1
docs(eslint-plugin): [no-dupe-class-members] fix typo (#1566)
4670aab
fix(eslint-plugin): [unbound-method] blacklist a few unbound natives (#1562)
See the full diff
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
When a step fails, CI should report the step which failed.
Make failures report that colcon (or whatever tool) failed instead of bash.
See https://github.com/RoverRobotics-forks/rmw_cyclonedds/runs/565373542?check_suite_focus=true
13.7.0
to 13.7.1
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
As a GH action user, I want to be able to build and run tests on more than one package.
A repo might contain multiple ROS2 packages. (ex: rosbag2)
And passing multiple space separated package names did not work see error in rosbag2 actions
Once all above items are checked, this story can be moved to done.
When looking at the checks currently applied at rosbag2 I see some mismatch which I can't really explain.
For example in this PR: ros2/rosbag2#225
I see that build_and_test
fails with cpplint
and uncrustify
not being happy:
[6.446s] The following tests FAILED:
[6.446s] 5 - cpplint (Failed)
[6.446s] 7 - uncrustify (Failed)
However, the dedicated checks (uncrustify and cpplint) are returning successful. How should I interpret this?
Description
codecov
action does not run on forks of repositories because secret token is not accessible from the fork.
Details
codecov-action
needs a CODECOV_TOKEN
to be able to run the action and generate coverage reports. This token is stored in the repository as a secret, and accessed in the Action from within the repo. Example: system_metrics_collector.
When a fork is created, a new repo is created that does not have access to the original repo's secrets. codecov-action
always fails to run from forked versions.
We need to find a way around this so external contributors who for the Tooling WG's repos are able to run codecov on their forks and PRs.
12.12.18
to 12.12.19
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
βοΈ Important announcement: Greenkeeper will be saying goodbye π and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io
2.24.0
to 2.25.0
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
@typescript-eslint/eslint-plugin is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
class-literal-property-style
rule (#1582) (b2dbd89)The new version differs by 19 commits.
9cd3e4f
chore: publish v2.25.0
b2dbd89
feat(eslint-plugin): add class-literal-property-style
rule (#1582)
3eb5d45
feat(experimental-utils): expose ast utility functions (#1670)
2b9603d
feat(eslint-plugin): [no-unnecessary-condition] ignore basic array indexing false positives (#1534)
c82d121
chore(typescript-estree): remove unfinished comment (#1770)
199863d
fix(eslint-plugin): [quotes] false positive with backtick in import equals statement (#1769)
6646959
fix(eslint-plugin): fix message of no-base-to-string (#1755)
f76a1b3
feat(eslint-plugin): [no-unnec-type-assertion] allow const assertions (#1741)
09d8afc
fix(typescript-estree): export * regression from 133f622f (#1751)
52b061e
chore: try fetching all tags and history in canary job
19cc9a9
chore: try fetching all tags and history in canary job
61a779c
chore: try fetching all history in canary job
d6e273d
chore: standardise issue templates (#1760)
abf1a2f
fix(eslint-plugin-tslint): fix tslintConfig memoization key (#1719)
3814d4e
fix: only run publish_canary_version on master
There are 19 commits in total.
See the full diff
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
CI fails to find pathspec for pull request hook. I believe itβs likely looking at the wrong remote for the vcs import step (the targeted repo versus the repo containing the pull request hook)
PR branch is pulled in and tested.
Failure log:
https://github.com/ros2/rmw_cyclonedds/runs/551468986?check_suite_focus=true
bash -c vcs import src/ < package.repo
1290
=== src/rmw_cyclonedds (git) ===
1291
Could not checkout ref 'readme-edits': error: pathspec 'readme-edits' did not match any file(s) known to git
This action uses packages like curl
that are not installed by this action and not provided by the official ros docker images
Action should install those and run without crashing on missing packages
Fails on curl
invocation: https://github.com/mikaelarguedas/sros2/runs/541489082
** Steps to reproduce the behavior, e.g.
bash -c curl 'https://raw.githubusercontent.com/ros2/ros2/master/ros2.repos' | vcs import src/
bash: curl: command not found
Input data is not valid format: 'NoneType' object is not subscriptable
##[error]The process 'bash' failed with exit code 1
4.0.10
to 4.1.0
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
husky is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
The new version differs by 9 commits.
ef5b965
4.1.0
0ba2ea2
Update .gitattributes
f66057b
Update snapshot
14837e5
Add empty line
de7a61e
Update .npmignore
27df561
Refactor hooks (#654)
e7af456
fix snapshot (#653)
46c72a1
update .gitignore
7790e65
Bugfix: prevent errors (#650)
See the full diff
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
See this PR for details
CMake Error at CMakeLists.txt:38 (find_package):
By not providing "Findament_cmake_gtest.cmake" in CMAKE_MODULE_PATH this
project has asked CMake to find a package configuration file provided by
"ament_cmake_gtest", but CMake did not find one.
Could not find a package configuration file provided by "ament_cmake_gtest"
with any of the following names:
ament_cmake_gtestConfig.cmake
ament_cmake_gtest-config.cmake
Add the installation prefix of "ament_cmake_gtest" to CMAKE_PREFIX_PATH or
set "ament_cmake_gtest_DIR" to a directory containing one of the above
files. If "ament_cmake_gtest" provides a separate development package or
SDK, be sure it has been installed.
Need to declare the mapping between the path and project root.
https://docs.codecov.io/docs/fixing-paths
See e.g. https://codecov.io/gh/ros-tooling/system_metrics_collector/tree/master/ros2_ws/src/system_metrics_collector/system_metrics_collector/src/moving_average_statistics => types.hpp
Consider using https://github.com/microsoft/setup-msbuild instead of invoking the vcvarsall.bat script by path.
As seen when trying to add GitHub actions to ROS2 diagnostics the macos actions is unable to compile.
[ 2%] Building CXX object Foundation/CMakeFiles/Foundation.dir/src/AsyncChannel.cpp.o
/Users/runner/runners/2.165.2/work/diagnostics/diagnostics/ros_ws/build/poco_vendor/poco-1.8.0.1-release-prefix/src/poco-1.8.0.1-release/Foundation/src/AsyncChannel.cpp:49:15: error: out-of-line definition of 'AsyncChannel' does not match any declaration in 'Poco::AsyncChannel'
AsyncChannel::AsyncChannel(Channel* pChannel, Thread::Priority prio):
^~~~~~~~~~~~
/Users/runner/runners/2.165.2/work/diagnostics/diagnostics/ros_ws/build/poco_vendor/poco-1.8.0.1-release-prefix/src/poco-1.8.0.1-release/Foundation/src/AsyncChannel.cpp:72:20: error: out-of-line definition of 'setChannel' does not match any declaration in 'Poco::AsyncChannel'
void AsyncChannel::setChannel(Channel* pChannel)
^~~~~~~~~~
/Users/runner/runners/2.165.2/work/diagnostics/diagnostics/ros_ws/build/poco_vendor/poco-1.8.0.1-release-prefix/src/poco-1.8.0.1-release/Foundation/src/AsyncChannel.cpp:82:24: error: return type of out-of-line definition of 'Poco::AsyncChannel::getChannel' differs from that in the declaration
Channel* AsyncChannel::getChannel() const
~~~~~~~~ ^
/usr/local/include/Poco/AsyncChannel.h:54:15: note: previous declaration is here
Channel::Ptr getChannel() const;
~~~~~~~~~~~~ ^
/Users/runner/runners/2.165.2/work/diagnostics/diagnostics/ros_ws/build/poco_vendor/poco-1.8.0.1-release-prefix/src/poco-1.8.0.1-release/Foundation/src/AsyncChannel.cpp:84:9: error: no viable conversion from returned value of type 'const Channel::Ptr' (aka 'const AutoPtr<Poco::Channel>') to function return type 'Poco::Channel *'
return _pChannel;
^~~~~~~~~
/usr/local/include/Poco/AutoPtr.h:268:2: note: candidate function not viable: 'this' argument has type 'const Channel::Ptr' (aka 'const AutoPtr<Poco::Channel>'), but method is not marked const
operator C* ()
I can confirm that poco_vendor
compiles version 1.81. successfully locally on my OSX computer.
The ros2_control repo recently added GH actions.
Any of the tests that use rclcpp::init()
in the setup fail on macOS with the following stack trace:
unknown file: Failure
2: C++ exception with description
"failed to initialized rcl init options: failed to find shared library of rmw implementation.
Searched rmw_fastrtps_cpp,
at /Users/runner/runners/2.164.0/work/ros2_control/ros2_control/ros_ws/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:61,
at /Users/runner/runners/2.164.0/work/ros2_control/ros2_control/ros_ws/src/ros2/rcl/rcl/src/rcl/init_options.c:55"
thrown in SetUpTestCase()
An example stacktrace can be found in the run here.
The error cannot be reproduced locally on both Ubuntu and macOS systems. This seems to be a GH Action specific issue.
Fails to build with Ubuntu 18.04 and ROS source (i.e. master).
Note that all other platform/district pairs appear to build.
matrix:
os: [ubuntu-18.04, macOS-latest, windows-latest]
rosdistro: [dashing, eloquent, source]
https://github.com/RoverRobotics-forks/rmw_cyclonedds/pull/1/checks?check_run_id=544943756
βοΈ Important announcement: Greenkeeper will be saying goodbye π and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io
2.24.0
to 2.25.0
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
@typescript-eslint/parser is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
class-literal-property-style
rule (#1582) (b2dbd89)The new version differs by 19 commits.
9cd3e4f
chore: publish v2.25.0
b2dbd89
feat(eslint-plugin): add class-literal-property-style
rule (#1582)
3eb5d45
feat(experimental-utils): expose ast utility functions (#1670)
2b9603d
feat(eslint-plugin): [no-unnecessary-condition] ignore basic array indexing false positives (#1534)
c82d121
chore(typescript-estree): remove unfinished comment (#1770)
199863d
fix(eslint-plugin): [quotes] false positive with backtick in import equals statement (#1769)
6646959
fix(eslint-plugin): fix message of no-base-to-string (#1755)
f76a1b3
feat(eslint-plugin): [no-unnec-type-assertion] allow const assertions (#1741)
09d8afc
fix(typescript-estree): export * regression from 133f622f (#1751)
52b061e
chore: try fetching all tags and history in canary job
19cc9a9
chore: try fetching all tags and history in canary job
61a779c
chore: try fetching all history in canary job
d6e273d
chore: standardise issue templates (#1760)
abf1a2f
fix(eslint-plugin-tslint): fix tslintConfig memoization key (#1719)
3814d4e
fix: only run publish_canary_version on master
There are 19 commits in total.
See the full diff
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
When a user specifies cmake
in their workflow linting matrix, ros-<ROSDISTRO>-ament-cmake
installs correctly, however, the linter command is not executed correctly.
This action currently attempts to run ament_cmake
which is not valid. The correct command is ament_lint_cmake
.
If lint_cmake
is specified in the linter matrix, then the workflow fails because ament-lint-cmake
is not a valid package.
Example:
jobs:
ament_lint_cpp:
runs-on: ubuntu-18.04
strategy:
fail-fast: false
matrix:
linter: [copyright, cppcheck, cpplint, cmake, uncrustify, xmllint]
2.18.0
to 2.19.0
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
@typescript-eslint/parser is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
filter
(#1517) (b24fbe8)The new version differs by 17 commits.
bec59ff
chore: publish v2.19.0
0a110eb
feat(eslint-plugin): [unbound-method] support bound builtins (#1526)
9e0f6dd
feat(eslint-plugin): add switch-exhaustiveness-check rule (#972)
7c70323
fix(typescript-estree): persisted parse and module none (#1516)
159b16e
feat(eslint-plugin): [no-float-prom] fixer + msg for ignoreVoid (#1473)
b22424e
feat(eslint-plugin): add extension [no-dupe-class-members] (#1492)
9e7d161
fix(eslint-plugin): [embt] fix allowTypedFunctionExpressions (#1553)
45ae0b9
fix(eslint-plugin): [require-await] improve performance (#1536)
39929b2
test(typescript-estree): fix issue in jest config (#1559)
95174d5
docs(eslint-plugin): corrected typo unbounded-method (#1558)
8643d56
chore(eslint-plugin): remove redundant code and update tests (#1557)
569259e
test: enable isolatedModules
for tests (#1546)
b24fbe8
feat(eslint-plugin): support negative matches for filter
(#1517)
6613fad
test: update jest and babel dependencies (#1530)
54201ab
feat(eslint-plugin): [no-extra-non-null-assert] add fixer (#1468)
There are 17 commits in total.
See the full diff
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
π¨ You need to enable Continuous Integration on Greenkeeper branches of this repository. π¨
To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.
Since we didnβt receive a CI status on the greenkeeper/initial
branch, itβs possible that you donβt have CI set up yet.
We recommend using:
If you have already set up a CI for this repository, you might need to check how itβs configured. Make sure it is set to run on all new branches. If you donβt want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/
.
Once you have installed and configured CI on this repository correctly, youβll need to re-trigger Greenkeeperβs initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.
Previously we had stability issues with GH Actions, ex: apt-mirror syncs.
To help remedy this, the builds for Ubuntu should run in a Docker container.
If we want to run CI for a different ROS distribution using a binary installation, rosdep will only install binary dependencies for Eloquent.
The distro that rosdep uses should be based on the ROS binary installation, if one is installed. Otherwise, I think a reasonable default if the latest available distro (currently Eloquent).
rosdep always uses Eloquent regardless of what binary ROS installation is required.
--rosdistro eloquent
I believe this is causing the subsequent build failure since it cannot find the required package in Dashing.
π¨ You need to enable Continuous Integration on Greenkeeper branches of this repository. π¨
To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.
Since we didnβt receive a CI status on the greenkeeper/initial
branch, itβs possible that you donβt have CI set up yet.
We recommend using:
If you have already set up a CI for this repository, you might need to check how itβs configured. Make sure it is set to run on all new branches. If you donβt want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/
.
Once you have installed and configured CI on this repository correctly, youβll need to re-trigger Greenkeeperβs initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.
24.0.23
to 24.0.24
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
@types/jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
https://github.com/ubuntu-robotics/nodl/pull/4/checks?check_run_id=430372431
.
βββ .github
β βββ workflows
β βββ test.yml
βββ LICENSE
βββ nodl_python
β βββ LICENSE
β βββ nodl
β β βββ __init__.py
β β βββ nodl_parse.py
β β βββ nodl_types.py
β βββ package.xml
β βββ setup.py
β βββ test
β βββ nodl.xml
β βββ test_flake8.py
β βββ test_mypy.py
β βββ test_nodl_parse.py
β βββ test_pep257.py
βββ README.md
from pathlib import Path
from typing import List
import lxml.etree as etree
import pytest
from rclpy import qos
import nodl.nodl_parse as nodl_parse
import nodl.nodl_types as nodl_types
[4.037s] =================================== FAILURES ===================================
[4.038s] _________________________________ test_flake8 __________________________________
[4.038s] test/test_flake8.py:22: in test_flake8
[4.038s] assert rc == 0, 'Found errors'
[4.038s] E AssertionError: Found errors
[4.038s] E assert 1 == 0
[4.038s] ----------------------------- Captured stdout call -----------------------------
[4.038s]
[4.038s] ./test/test_nodl_parse.py:21:1: I100 Import statements are in the wrong order. 'import nodl.nodl_parse' should be before 'from rclpy import qos'
[4.038s] import nodl.nodl_parse as nodl_parse
[4.038s] ^
[4.038s]
[4.038s] ./nodl/nodl_parse.py:22:1: I100 Import statements are in the wrong order. 'from nodl.nodl_types import Action, Node, Parameter, Service, Topic' should be before 'from rclpy.duration import Duration'
[4.039s] from nodl.nodl_types import Action, Node, Parameter, Service, Topic
[4.039s] ^
[4.039s]
[4.039s] 2 I100 Import statements are in the wrong order. 'from nodl.nodl_types import Action, Node, Parameter, Service, Topic' should be before 'from rclpy.duration import Duration'
As of this writing, action-ros-ci
composes and executes colcon
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 to colcon build
. And when it comes to customize the tasks, typically it exposes the options case-by-case, for example, it currently takes extra-cmake-args
for developers to customize the --cmake-args
for colcon build
.
On the other side, colcon
has a user configuration concept, where developers can define a YAML
file to describe what arguments should go to colcon
command by default. For example, if I have the following file defined and specified in %COLCON_DEFAULTS_FILE%
,
# defaults.yaml
{
"build": {
"symlink-install": true,
"cmake-args": [
"-G",
"Ninja",
"-DCMAKE_PREFIX_PATH=d:/install",
"-DCATKIN_SKIP_TESTING=ON",
"-DCMAKE_BUILD_TYPE=Release"],
"event-handlers": ["console_cohesion+"],
"install-base": "d:/install",
"parallel-workers" : 1,
"merge-install": true
}
}
Then, whenever I run colcon build
, those arguments will be automatically applied to my build
task. This approach gives much more flexible to extend the colcon
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:
- uses: ros-tooling/action-ros-ci@master
with:
package-name: abc_package
colcon-defaults-file: ${{ github.workspace }}/defaults.yaml
As a GH action user, I can run Bloom pre-release script to generate Debian packages for my software.
Once all above items are checked, this story can be moved to done.
βοΈ Important announcement: Greenkeeper will be saying goodbye π and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io
25.2.1
to 25.3.0
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
ts-jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
Please excuse me if I submit this idea on the wrong place.
For a repository which is not yet to onboard with GitHub workflow, a list of templates will be shown to developers to help quickly onboard based on their project types. It could be useful for developers who is looking for a beginner CI/CD workflow for their projects.
And GitHub manages the list of templates here: https://github.com/actions/starter-workflows
What if we add ROS CI actions to be one of that?
Per https://github.com/ubuntu-robotics/nodl/pull/4/checks?check_run_id=437779651
--- stderr: fastrtps
CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find Asio (missing: ASIO_INCLUDE_DIR)
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
cmake/modules/FindAsio.cmake:16 (find_package_handle_standard_args)
cmake/common/eprosima_libraries.cmake:96 (find_package)
CMakeLists.txt:219 (eprosima_find_thirdparty)
It would be nice to have a minimal, well-formed ROS2 project that builds with action-ros2-ci
to use as reference for setting up action-ros2-ci
in other projects.
Build all packages in the workspace by default - by providing no package specifiers to colcon build
and colcon test
.
Continue to allow use of package-name
to limit the packages built. This would make it a non-API-breaking change since all existing workflows will continue working.
Originally from ros2/rosbag2#259
More future-proof alternative: Modifying the actions to determine the package list based on repository content rather than requiring maintainers to provide an explicit list (if an explicit list is passed this could override the default of "all packages in the repo")
My thoughts are that this could be a bool input param to specify if the user wants the CI to look for all directories with a package.xml
file.
I am not sure if this has been discussed, but would it be useful to have a feature to automatically generate the .rosinstall
file with only the packages within the dependency graph and then do vcs import
for the build-from-source CI?
For example, for rmw_implemenation
package, we can get its build dependencies in .rosinstall
by:
rosinstall_generator rmw_implementation --rosdistro eloquent --deps-only --deps --upstream-development
As more ROS 2 packages are released into rosdistro
, this approach could scale better beyond the ROS 2 essential packages.
The windows nightly test builds for action-ros-ci are failing.
The workflows should pass.
The workflows are failing.
This might simply require a bump of the setup-ros version. This issue started 2 days ago however, changes to the windows builds were made over 6 days ago and would have been caught earlier.
While looking into the action for generating code coverage reports I realized that we could be replicating code in many different repositories that could be hard to maintain, upgrade or fix. A typical implementation can be found at: https://github.com/ros2/rcpputils/pull/33/files
I'm particularly looking into the build_and_test
and step:
build_and_test:
runs-on: ${{ matrix.os }}
strategy:
fail-fast: false
matrix:
os: [ubuntu-18.04]
steps:
- uses: ros-tooling/[email protected]
- uses: ros-tooling/[email protected]
with:
package-name: rcpputils
- uses: actions/upload-artifact@master
with:
name: colcon-logs
path: ros_ws/log
The problem I found with this is that the actions used in the step (setup-ros, actions-ros-ci and upload logs) are part of a common use case: build and test. While this is fine to get things working, a more centralized approach could be taken, something like:
build_and_test:
runs-on: ${{ matrix.os }}
strategy:
fail-fast: false
matrix:
os: [ubuntu-18.04]
steps:
- uses: ros-tooling/[email protected]
with:
package-name: rcpputils (potentially to be removed if we infer packages names from sources)
Some benefits I see:
build-and-test-ros
controls the combination of versions used for setup-ros
, actions-ros-ci
and upload
. Make things easier to deliver fixes or avoid problems when mixing random versions together.build_and_test use case could be extended with more features and the ROS package maintainers only need to update the version of
build-and-test-ros`.Flexibility for special configurations of the same use cases could be achieved by:
colcon-log-path
)We could use this approach to create a code-coverage action that wraps the actions and commands needed for generating a codecov report (see j-rivero/rcpputils@0fc5e5e#diff-fe8421955fd596131bb6f1b78984b2fbR16-R38).
I'm far from being an expert with actions so feedback is very welcome. Thanks.
As a GH action user, I can build and run tests on Windows for my packages.
Once all above items are checked, this story can be moved to done.
12.12.0
to 12.12.1
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
In addition to the vcs-repo-file-url
input, it would be nice to be able to pass supplemental repo files. The use-case is for projects that require more than one repository that are not part of the core repositories listed at https://github.com/ros2/ros2. Rather than making a copy of the default repositories file and appending to it, it would be nicer to just be able to provide one or more additional files with the extra repositories.
I think it makes sense to add a new input for supplemental repo files, e.g. vcs-supplemental-repo-file-urls
.
Alternatively, the existing input, vcs-repo-file-url
, could be refactored to take more than one file. But, I lean towards the first option so we don't have to explicitly pass the base file all the time.
The latter repo files should act as overlays to the previous. I.e. if a repository appears in multiple repo files, then the version of the repository specified in the latter repo file should be used.
When you install ros1 it remove catkin-pkg, so this only affects rosbag2_bag_v2 right now
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.