-
Notifications
You must be signed in to change notification settings - Fork 2
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
Use GitHub Actions CI #136
Comments
I've been experimenting with https://github.com/ros-tooling/action-ros-ci in the following branch: It recommends using the https://github.com/ros-tooling/setup-ros action step to configure the system for using ROS (installing build tops, adding ROS apt repositories), which I plan to use for configuring base system. The action-ros-ci workflow doesn't have great support for private repositories though. As outlined in ros-tooling/action-ros-ci#224, despite the fact that For now, I will use |
Thanks for the update! |
Relates to #135 |
It looks like |
I happened to try a build with ROS eloquent instead of dashing, and it gave the following error:
I'm guessing some of the ament syntax has changed since dashing, so we should keep this in mind when updating to a new version of ros2 / ament. |
first approach in maliput/maliput#343 |
maliput/maliput#343 has merged. Next steps could include:
|
Before moving forward with more CI steps, I think we should take another package, let's say maliput-dragway which consumes maliput as a dependency. I think a reasonable path forward would be:
On a separate note, which linters are you thinking of? We have clang-format that checks the code is properly linted and similarly we have for python. That is already checked via ctests. Am I missing something else? |
ok, shall I create a new GitHub user account to hold read access to these repositories so we can use its token in the Actions CI?
sorry, I meant static analyzers, like scan-build |
Todo @scpeters: reach out to https://github.com/ros-tooling/setup-ros maintainers to see if they are willing to create a separate action that doesn't install DDS implementations |
Steps required for enabling GitHub Actions CI on a new package (starting with https://github.com/ToyotaResearchInstitute/maliput-dragway)
|
it looks like the logic for installing DDS implementations is intermingled with compilers and development tools in the package_manager/apt.ts file. DDS-specific lines:
|
|
experimenting with compiling maliput with both gcc and clang in maliput/maliput@b14c695, but it currently only has clang 6 installed. I need to copy the following logic in order to install the correct value of clang (currently version 8): |
I submitted an issue ros-tooling/setup-ros#276 requesting a parameter to make it easy for a specific version of clang be installed. Now that I think about it; it might make more sense for this to be done as a separate action, though I don't have any experience making actions. |
enabling Actions CI for dragway: maliput/maliput_dragway#9 |
I've seen actions that install apt packages but haven't seen one that adds a new repo source. I would try to split this task into: 1- Installation What do you think? |
Also, I came across this PR: https://github.com/onqtam/doctest/pull/285/files that includes several compilers. It might help. |
@scpeters how difficult would it be to either setup a From reviewing all the PRs, I could see that the following is repeated:
And in the future we will add:
If we can pass the tokens and the repositories when checking out the private repositories and the package names when testing, I think our action files will be considerably reduced. BTW, I don't think we need to address it now, I think it would be nice to have and understand what it would take. |
I think it could be nice to generalize these actions if it can reduce duplication of the configuration and build scripts. At the moment, these actions are still under development and don't involve too much duplication, so I'd prefer to continue with the present setup for now but keep this in mind in case there is more duplication that we want to mitigate |
Status: all repositories that require a gcc build have Github Actions. |
our Jenkins CI has some logic to switch branches for package dependencies if they have a branch name matching the current branch of the leaf package to be tested: this is not enabled for GitHub Actions yet, but it could be. it would require setting |
About scan_build:
|
Per maliput/delphyne#717 (comment) investigation, we should:
- uses: ros-tooling/[email protected]
env:
ACTIONS_ALLOW_UNSECURE_COMMANDS: true
See https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/ for context about the change. |
I think if we bump to |
due to maliput/maliput#368 requiring changes in some downstream packages, I'm adding logic for checking out matching branch names if available in those packages:
it still needs to be added to a few other repositories |
Implementation has finished. |
We'd like to try using GitHub Actions CI for maliput and other delphyne dependencies, which will be especially useful after open-sourcing these repositories.
I've started by looking at maliput, which is easiest because it doesn't have any private dependencies. To checkout private GitHub repositories, you need to add a GitHub token as a secret inside the repository, so it's much easier to configure GitHub actions for repositories with only public dependencies.
My first attempt is in the following branch:
It tries to avoid using packages.ros.org by installing python packages using pip and adding ament to the colcon workspace. I ran into some trouble configuring
rosdep
, so I'm going to try using https://github.com/ros-tooling/action-ros-ci to see if that's easier to configure.The text was updated successfully, but these errors were encountered: