Giter VIP home page Giter VIP logo

action-ros-ci's Introduction

action-ros-ci

GitHub Action Status Dependabot Status codecov

This action builds and tests a ROS or ROS 2 workspace from source.

  1. Requirements
  2. Overview
  3. Action Output
  4. Usage
    1. Build and run tests for your ROS 2 package
    2. Build with a custom repos or rosinstall file
    3. Build a ROS 1 workspace
    4. Skip tests
    5. Use a colcon defaults.yaml file
    6. Do not use --symlink-install when building
    7. Enable Address Sanitizer to automatically report memory issues
    8. Generate and process code coverage data
    9. Store colcon logs as build artifacts
    10. Use with private repos
    11. Skip rosdep install
    12. Interdependent pull requests or merge requests
  5. Developing
  6. License

Requirements

This action requires the following ROS development tools to be installed (and initialized if applicable) on the CI worker instance:

colcon-common-extensions
colcon-lcov-result  # Optional
colcon-coveragepy-result
colcon-mixin
rosdep
vcstool

On Linux, the setup can be done through ros-tooling/setup-ros, or by running the action in a Docker image containing the appropriate binaries.

Note: for Windows, action-ros-ci currently needs to be run on windows-2019 or needs another action to install Visual Studio 2019.

Overview

The action first assembles a workspace, then runs colcon build, and colcon test in it.

The workspace is built by running:

  • vcs import on the repo file(s) specified through the vcs-repo-file-url argument, if any (defaults to none)
  • checkout the code under test in the workspace using vcs
  • rosdep install for the workspace, to get its dependencies
  • run colcon build (optionally limited to packages specified in package-name)
  • run colcon test (optionally limited to packages specified in package-name; optionally skipped)

This action requires targeting a ROS or ROS 2 distribution explicitly. This is provided via the target-ros1-distro or target-ros2-distro inputs, respectively. Either or both may be specified, if neither is provided an error will be raised. This input is used to source setup.sh for any installed ROS binaries (e.g. installed using ros-tooling/setup-ros), as well as used as an argument to rosdep install.

Action Output

This action defines an output variable: ros-workspace-directory-name. It contains the path to the root of the ROS workspace assembled by the action.

The variable value should be used to retrieve logs, binaries, etc. after the action completes.

Usage

See action.yml to get the list of inputs supported by this action.

action-ros-ci-template offers a template for using action-ros-ci.

Build and run tests for your ROS 2 package

Here are the two simplest use-cases.

Using dependencies from binaries

In this case, action-ros-ci will rely on setup-ros for installing ROS 2 binaries.

steps:
  - uses: ros-tooling/[email protected]
    with:
      required-ros-distributions: jazzy
  - uses: ros-tooling/[email protected]
    with:
      package-name: my_package
      target-ros2-distro: jazzy

Building ROS 2 dependencies from source

In this case, action-ros-ci will build all necessary ROS 2 dependencies of my_package from source.

steps:
  - uses: ros-tooling/[email protected]
  - uses: ros-tooling/[email protected]
    with:
      package-name: my_package
      target-ros2-distro: jazzy
      vcs-repo-file-url: https://raw.githubusercontent.com/ros2/ros2/jazzy/ros2.repos

Schedule an action on a specific branch

If you want to continue supporting older ROS releases while developing on an the main branch use acton-ros-ci with ref on a scheduled job. Without setting ref the default branch and most recent commit will be used.

name: Jazzy Source Build
on:
  schedule:
    # At 00:00 on Sunday.
    - cron '0 0 * * 0'

jobs:
  jazzy_source:
    runs_on: ubuntu-latest
    container:
      image: ubuntu:noble
    steps:
      - uses: ros-tooling/[email protected]
        with:
          required-ros-distributions: jazzy
      - uses: ros-tooling/[email protected]
        with:
          package-name: my_package
          ref: jazzy
          target-ros2-distro: jazzy
          vcs-repo-file-url: https://raw.githubusercontent.com/ros2/ros2/jazzy/ros2.repos

Build with a custom repos or rosinstall file

You can specify your own repos file using the vcs-repo-file-url input. You can also automatically generate your package's dependencies using the following workflow:

steps:
  - uses: actions/checkout@v4
  - uses: ros-tooling/[email protected]
  # Run the generator and output the results to a file.
  - run: |
      rosinstall_generator <package-name> --rosdistro <target-distro> \
      --deps-only --deps --upstream-development > /tmp/deps.repos
  # Pass the file to the action
  - uses: ros-tooling/[email protected]
    with:
      package-name: my_package
      target-ros2-distro: jazzy
      vcs-repo-file-url: /tmp/deps.repos

Note that the actions/checkout step is required when using a custom repos file from your repository.

Build a ROS 1 workspace

Building a ROS 1 workspace works the same way. Simply use target-ros1-distro instead of target-ros2-distro.

steps:
  - uses: ros-tooling/[email protected]
    with:
      required-ros-distributions: noetic
  - uses: ros-tooling/[email protected]
    with:
      package-name: my_package
      target-ros1-distro: noetic

Skip tests

To skip tests and code coverage data processing, set the skip-tests option to true.

steps:
  - uses: ros-tooling/[email protected]
    with:
      required-ros-distributions: jazzy
  - uses: ros-tooling/[email protected]
    with:
      package-name: my_package
      target-ros2-distro: jazzy
      skip-tests: true

Use a colcon defaults.yaml file

To use a colcon defaults.yaml file, provide a valid JSON string through the colcon-defaults input. This allows using a colcon option/argument that is not exposed by this action's inputs.

steps:
  - uses: ros-tooling/[email protected]
    with:
      required-ros-distributions: jazzy
  - uses: ros-tooling/[email protected]
    with:
      package-name: my_package
      target-ros2-distro: jazzy
      colcon-defaults: |
        {
          "build": {
            "cmake-args": [
                "-DMY_CUSTOM_OPTION=ON"
            ]
          }
        }

Do not use --symlink-install when building

By default, --symlink-install is used with colcon build. To avoid this, set the no-symlink-install input to true.

steps:
  - uses: ros-tooling/[email protected]
    with:
      required-ros-distributions: jazzy
  - uses: ros-tooling/[email protected]
    with:
      package-name: my_package
      target-ros2-distro: jazzy
      no-symlink-install: true

Enable Address Sanitizer to automatically report memory issues

ASan is an open-source tool developed to automatically report memory corruption bugs.

steps:
  - uses: ros-tooling/[email protected]
    with:
      required-ros-distributions: jazzy
  - uses: ros-tooling/[email protected]
    with:
      colcon-defaults: |
        {
          "build": {
            "mixin": ["asan-gcc"]
          }
        }
      colcon-mixin-repository: https://raw.githubusercontent.com/colcon/colcon-mixin-repository/b8436aa16c0bdbc01081b12caa253cbf16e0fb82/index.yaml
      package-name: my_package
      target-ros2-distro: jazzy

To look for detected memory errors, check the build logs for entries containing ERROR: AddressSanitizer. Example:

==9442== ERROR: AddressSanitizer heap-use-after-free on address 0x7f7ddab8c084 at pc 0x403c8c bp 0x7fff87fb82d0 sp 0x7fff87fb82c8

ASan is analyzing memory issues at runtime. ASan diagnostic messages will be emitted by the package tests when they run.

Generate and process code coverage data

Generate code coverage information using lcov and colcon-lcov-result

Generate code coverage information for C/C++ files using the appropriate mixins for gcc. action-ros-ci uses colcon-lcov-result to aggregate generated coverage information.

Flags can be passed manually using, for instance, extra-cmake-args, but it is preferable to use a colcon mixin (through colcon-defaults) to pass the appropriate flags automatically.

steps:
  - uses: ros-tooling/[email protected]
    with:
      required-ros-distributions: jazzy
  - uses: ros-tooling/[email protected]
    with:
      package-name: my_package
      target-ros2-distro: jazzy
      colcon-defaults: |
        {
          "build": {
            "mixin": ["coverage-gcc"]
          }
        }
      # If possible, pin the repository in the workflow to a specific commit to avoid
      # changes in colcon-mixin-repository from breaking your tests.
      colcon-mixin-repository: https://raw.githubusercontent.com/colcon/colcon-mixin-repository/b8436aa16c0bdbc01081b12caa253cbf16e0fb82/index.yaml

Generate code coverage information using coveragepy and colcon-coveragepy-result

Generate code coverage information for Python files using the appropriate mixins. action-ros-ci uses colcon-coveragepy-result to aggregate generated coverage information.

steps:
  - uses: ros-tooling/[email protected]
    with:
      required-ros-distributions: jazzy
  - uses: ros-tooling/[email protected]
    with:
      package-name: my_package
      target-ros2-distro: jazzy
      colcon-defaults: |
        {
          "build": {
            "mixin": ["coverage-pytest"]
          },
          "test": {
            "mixin": ["coverage-pytest"]
          }
        }
      # If possible, pin the repository in the workflow to a specific commit to avoid
      # changes in colcon-mixin-repository from breaking your tests.
      colcon-mixin-repository: https://raw.githubusercontent.com/colcon/colcon-mixin-repository/b8436aa16c0bdbc01081b12caa253cbf16e0fb82/index.yaml

Integrate action-ros-ci with codecov

The generated code coverage information can be uploaded to codecov.io.

For a private repo, you will need to setup a secret CODECOV_TOKEN in your repository settings. See codecov/codecov-action documentation for more information about how to setup the action.

steps:
  - uses: actions/checkout@v4
  - uses: ros-tooling/[email protected]
    with:
      required-ros-distributions: jazzy
  - uses: ros-tooling/[email protected]
    with:
      package-name: my_package
      target-ros2-distro: jazzy
      colcon-defaults: |
        {
          "build": {
            "mixin": ["coverage-gcc", "coverage-pytest"]
          },
          "test": {
            "mixin": ["coverage-pytest"]
          }
        }
      # If possible, pin the repository in the workflow to a specific commit to avoid
      # changes in colcon-mixin-repository from breaking your tests.
      colcon-mixin-repository: https://raw.githubusercontent.com/colcon/colcon-mixin-repository/b8436aa16c0bdbc01081b12caa253cbf16e0fb82/index.yaml
  - uses: codecov/[email protected]
    with:
      token: ${{ secrets.CODECOV_TOKEN }}  # only needed for private repos
      files: ros_ws/lcov/total_coverage.info,ros_ws/coveragepy/.coverage
      flags: unittests
      name: codecov-umbrella

You will also need to add a codecov.yml configuration file (at the root of your repo):

fixes:
  # For each package in your repo
  - "ros_ws/src/*/my_repo/my_package/::"

The configuration file is required to let codecov map the workspace directory structure to the Git repository structure, and setup the links between codecov and GitHub properly. Note here that actions/checkout is required because codecov/codecov-action needs the codecov.yml file.

Store colcon logs as build artifacts

GitHub workflows can persist data generated in workers during the build using artifacts. action-ros-ci generated colcon logs can be saved as follows:

steps:
  # ...
  - uses: ros-tooling/[email protected]
    id: action_ros_ci_step
    with:
      package-name: ament_copyright
      target-ros2-distro: jazzy
  - uses: actions/upload-artifact@v1
    with:
      name: colcon-logs
      path: ${{ steps.action_ros_ci_step.outputs.ros-workspace-directory-name }}/log
    if: always() # upload the logs even when the build fails

Use with private repos

action-ros-ci needs a token to be able to clone private repositories. If the only private repository your workflow needs is the one against which it runs, using the default GITHUB_TOKEN will work. However, if your workflow also clones other private repositories (e.g., repositories included in repos files provided through vcs-repo-file-url), you will need to generate a personal access token (PAT) with the "repo" scope and add it to your repo's secrets. For example, if this secret is called REPO_TOKEN:

steps:
  # ...
  - uses: ros-tooling/[email protected]
    with:
      package-name: my_package
      # If there are no private dependencies, no need to create a PAT or add a secret
      import-token: ${{ secrets.GITHUB_TOKEN }}
      # If there are private dependencies (e.g., in a file provided through vcs-repo-file-url), a PAT is required
      import-token: ${{ secrets.REPO_TOKEN }}
      # ...

Skip rosdep install

Include an option to bypass rosdep install for workflow that uses specific docker image and better control of dependencies. To check for missing dependencies within the workflow's image, user can run with rosdep-check: true flag.

runs-on: ubuntu-latest
container:
  image: ghcr.io/ros-tooling/setup-ros-docker/setup-ros-docker-ubuntu-noble-ros-jazzy-ros-base
steps:
  # ...
  - uses: ros-tooling/[email protected]
    with:
      target-ros2-distro: jazzy
      package-name: ament_copyright
      vcs-repo-file-url: "https://raw.githubusercontent.com/ros2/ros2/release-jazzy-20240523/ros2.repos"
      skip-rosdep-install: true
      rosdep-check: true

Interdependent pull requests or merge requests

This action allows declaring PR dependencies by providing:

  • repos file(s) to override the one(s) defined through the vcs-repo-file-url action input
  • supplemental repos file(s) to be used along with the rest

For example, this may be useful when your PR depends on PRs/MRs/branches from other repos for it to work or be properly tested.

Include links in your PR's description using the following format:

action-ros-ci-repos-override: https://gist.github.com/some-user/some.repos
action-ros-ci-repos-override: https://gist.github.com/some-user/some-other.repos
action-ros-ci-repos-supplemental: https://gist.github.com/some-user/some-supplemental.repos
action-ros-ci-repos-supplemental: file://path/to/some/other/supplemental.repos

Developing

For developing and releasing action-ros-ci, see DEVELOPING.md.

License

The scripts and documentation in this project are released under the Apache 2 license.

action-ros-ci's People

Contributors

christian-rauch avatar christianrauch avatar christophebedard avatar clalancette avatar dabonnie avatar dependabot-preview[bot] avatar dependabot[bot] avatar emersonknapp avatar flynneva avatar francocipollone avatar greenkeeper[bot] avatar ijnek avatar j-rivero avatar jacobperron avatar jikawa-az avatar kaichie avatar kenji-miyake avatar mikaelarguedas avatar mm318 avatar moriarty avatar rotu avatar sallydly avatar seanyen avatar snehaldb90 avatar wep21 avatar wmmc88 avatar zmichaels11 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

action-ros-ci's Issues

Action cannot run standalone, relies on packages not listed as prerequisites

Description

This action uses packages like curl that are not installed by this action and not provided by the official ros docker images

Expected Behavior

Action should install those and run without crashing on missing packages

Actual Behavior

Fails on curl invocation: https://github.com/mikaelarguedas/sros2/runs/541489082

To Reproduce

** Steps to reproduce the behavior, e.g.

  1. Go to this commit mikaelarguedas/sros2@ce218ee
  2. Run after the commit https://github.com/mikaelarguedas/sros2/runs/541489082
  3. in the logs, click on " Run ros-tooling/action-ros-ci@master"
  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

System (please complete the following information)

  • OS: Ubuntu Focal
  • ROS 2 master

Proposal: create github actions that include common commands/actions for recurrent use cases

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:

  • There is only one version to be updated by the third party repositories by ROS maintainers
  • The version of 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.
  • The 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:

  • Add optional parameters to the build-and-test-ros action (like colcon-log-path)
  • Nothing is stopping maintainers of not using the individual actions and compose custom workflows (like it is being done now in the rcpputils PR).

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.

macOS cannot run rclcpp::init in tests

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.

An in-range update of @typescript-eslint/eslint-plugin is breaking the build 🚨

The devDependency @typescript-eslint/eslint-plugin was updated from 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.

Status Details
  • ❌ ROS 2 Test Suite (Docker, Eloquent): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS 2 Test Suite (Docker, Dashing): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS Test Suite (Docker, Kinetic): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS Test Suite: There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS 2 Test Suite (windows-latest): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS 2 Test Suite (ubuntu-18.04): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS 2 Test Suite (macOS-latest): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS Test Suite (Docker, Melodic): There are 1 failures, 0 warnings, and 0 notices.

Release Notes for v2.19.1

2.19.1 (2020-02-10)

Bug Fixes

  • eslint-plugin: [unbound-method] blacklist a few unbound natives (#1562) (4670aab)
  • typescript-estree: ts returning wrong file with project references (#1575) (4c12dac)
Commits

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

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @types/jest is breaking the build 🚨

The devDependency @types/jest was updated from 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.

Status Details
  • βœ… ROS Test Suite: null
  • ❌ ROS 2 Test Suite (windows-latest): There are 2 failures, 0 warnings, and 0 notices.
  • βœ… ROS 2 Test Suite (ubuntu-18.04): null
  • βœ… ROS 2 Test Suite (macOS-latest): null

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Windows nightly test workflows are failing

Description

The windows nightly test builds for action-ros-ci are failing.

Expected Behavior

The workflows should pass.

Actual Behavior

The workflows are failing.

Additional context

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.

Windows source build failing, "Could not find ASIO"

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)

Automatically package dependencies resolving by `rosinstall_generator`?

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.

Support supplementary repo files

Description

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.

Completion Criteria

  • Provide a mechanism to pass a secondary repo file.

Implementation Notes / Suggestions

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.

Testing Notes / Suggestions

  • Test with a repository that is not in the base repo file.
  • Test with a repository that is in the base repo file, but with a different version.

An in-range update of @types/node is breaking the build 🚨

The devDependency @types/node was updated from 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.

Status Details
  • βœ… ROS 2 Test Suite (Docker, Dashing): null
  • βœ… ROS 2 Test Suite (Docker, Eloquent): null
  • βœ… ROS Test Suite (Docker, Melodic): null
  • ❌ ROS Test Suite (Docker, Kinetic): There are 2 failures, 0 warnings, and 0 notices.
  • βœ… ROS Test Suite: null
  • βœ… ROS 2 Test Suite (windows-latest): null
  • βœ… ROS 2 Test Suite (ubuntu-18.04): null
  • βœ… ROS 2 Test Suite (macOS-latest): null

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Not obvious how to correctly build from source

Description

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

Exit Criteria

  • All inputs of the action are validated and properly throw an error if the input parameter is invalid
  • Clarify the documentation to explain that by default, action-ros-ci is building from source because the default VCS file is containing all the ROS 2 repositories.

Unable to test codecov from personal forks

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.

Missing ament_cmake_gtest package

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.

An in-range update of @typescript-eslint/parser is breaking the build 🚨


☝️ 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


The devDependency @typescript-eslint/parser was updated from 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.

Status Details
  • βœ… ROS 2 Test Suite (Docker, Dashing): null
  • βœ… ROS 2 Test Suite (rosdep, Dashing binary): null
  • ❌ ROS Test Suite (Docker, Melodic): There are 1 failures, 0 warnings, and 0 notices.
  • βœ… ROS 2 Test Suite (Docker, Eloquent): null
  • ❌ ROS Test Suite: There are 1 failures, 0 warnings, and 0 notices.
  • βœ… ROS 2 Test Suite (windows-latest): null
  • βœ… ROS 2 Test Suite (ubuntu-18.04): null
  • βœ… ROS 2 Test Suite (macOS-latest): null
  • βœ… ROS Test Suite (Docker, Kinetic): null

Release Notes for v2.25.0

2.25.0 (2020-03-23)

Bug Fixes

Features

  • eslint-plugin: [no-unnec-type-assertion] allow const assertions (#1741) (f76a1b3)
  • eslint-plugin: [no-unnecessary-condition] ignore basic array indexing false positives (#1534) (2b9603d)
  • eslint-plugin: add class-literal-property-style rule (#1582) (b2dbd89)
  • experimental-utils: expose ast utility functions (#1670) (3eb5d45)
Commits

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

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

mismatch between `build_and_test` vs `linter_cpplint`

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?

Allow build/test all packages by default

Description

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.

Original ticket for context

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.

Pull request hook fails to find pathspec

Description

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)

Expected Behavior

PR branch is pulled in and tested.

Actual Behavior

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

An in-range update of ts-jest is breaking the build 🚨


☝️ 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


The devDependency ts-jest was updated from 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.

Status Details
  • βœ… ROS 2 Test Suite (rosdep, Dashing binary): null
  • βœ… ROS 2 Test Suite (Docker, Eloquent): null
  • βœ… ROS 2 Test Suite (Docker, Dashing): null
  • ❌ ROS 2 Test Suite (windows-latest): There are 10 failures, 10 warnings, and 0 notices.
  • βœ… ROS 2 Test Suite (ubuntu-18.04): null
  • βœ… ROS 2 Test Suite (macOS-latest): null
  • ❌ ROS Test Suite: There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS Test Suite (Docker, Melodic): There are 1 failures, 0 warnings, and 0 notices.
  • βœ… ROS Test Suite (Docker, Kinetic): null

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Action required: Greenkeeper could not be activated 🚨

🚨 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.

An in-range update of husky is breaking the build 🚨

The devDependency husky was updated from 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.

Status Details
  • ❌ ROS 2 Test Suite (Docker, Eloquent): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS 2 Test Suite (Docker, Dashing): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS Test Suite: There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS 2 Test Suite (windows-latest): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS 2 Test Suite (ubuntu-18.04): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS 2 Test Suite (macOS-latest): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS Test Suite (Docker, Kinetic): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS Test Suite (Docker, Melodic): There are 1 failures, 0 warnings, and 0 notices.

Release Notes for v4.1.0
  • Improve speed and refactor hooks
Commits

The new version differs by 9 commits.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Support building and testing on WIndows

Description

As a GH action user, I can build and run tests on Windows for my packages.

Test Plan

  • End to end integration test

Documentation Plan

  • README.md update

Release Plan

  • Release the impacted packages again, and update the workflows as needed.

Acceptance Criteria

  • Code has been implemented, reviewed and merged.
  • Test plan has been completed
  • Release plan has been completed

Once all above items are checked, this story can be moved to done.

ament_flake8 tests fail incorrectly due to wrong import order

https://github.com/ubuntu-robotics/nodl/pull/4/checks?check_run_id=430372431

File Hierarchy

.
β”œβ”€β”€ .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

test_nodl_parse.py imports

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

Test output

  [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'

An in-range update of @types/node is breaking the build 🚨

The devDependency @types/node was updated from 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.

Status Details
  • ❌ test (ubuntu-18.04): There are 2 failures, 0 warnings, and 0 notices.
  • βœ… test (macOS-10.14): null

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Add support for ament_lint_cmake

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]

An in-range update of @typescript-eslint/eslint-plugin is breaking the build 🚨


☝️ 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


The devDependency @typescript-eslint/eslint-plugin was updated from 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.

Status Details
  • βœ… ROS 2 Test Suite (rosdep, Dashing binary): null
  • βœ… ROS 2 Test Suite (Docker, Dashing): null
  • βœ… ROS 2 Test Suite (Docker, Eloquent): null
  • βœ… ROS Test Suite (Docker, Kinetic): null
  • ❌ ROS Test Suite (Docker, Melodic): There are 1 failures, 0 warnings, and 0 notices.
  • ❌ ROS Test Suite: There are 1 failures, 0 warnings, and 0 notices.
  • βœ… ROS 2 Test Suite (windows-latest): null
  • βœ… ROS 2 Test Suite (ubuntu-18.04): null
  • βœ… ROS 2 Test Suite (macOS-latest): null

Release Notes for v2.25.0

2.25.0 (2020-03-23)

Bug Fixes

Features

  • eslint-plugin: [no-unnec-type-assertion] allow const assertions (#1741) (f76a1b3)
  • eslint-plugin: [no-unnecessary-condition] ignore basic array indexing false positives (#1534) (2b9603d)
  • eslint-plugin: add class-literal-property-style rule (#1582) (b2dbd89)
  • experimental-utils: expose ast utility functions (#1670) (3eb5d45)
Commits

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

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

[Feature Request] Onboard to the GitHub Starter Workflows

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?

An in-range update of @types/node is breaking the build 🚨

The devDependency @types/node was updated from 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.

Status Details
  • βœ… ROS Test Suite: null
  • ❌ ROS 2 Test Suite (windows-latest): There are 2 failures, 0 warnings, and 0 notices.
  • βœ… ROS 2 Test Suite (ubuntu-18.04): null
  • βœ… ROS 2 Test Suite (macOS-latest): null

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @typescript-eslint/parser is breaking the build 🚨

The devDependency @typescript-eslint/parser was updated from 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.

Status Details
  • βœ… ROS 2 Test Suite (Docker, Eloquent): null
  • βœ… ROS 2 Test Suite (Docker, Dashing): null
  • βœ… ROS 2 Test Suite (windows-latest): null
  • ❌ ROS 2 Test Suite (ubuntu-18.04): There are 2 failures, 0 warnings, and 0 notices.
  • βœ… ROS 2 Test Suite (macOS-latest): null
  • βœ… ROS Test Suite (Docker, Kinetic): null
  • βœ… ROS Test Suite (Docker, Melodic): null
  • βœ… ROS Test Suite: null

Release Notes for v2.19.0

2.19.0 (2020-02-03)

Bug Fixes

  • eslint-plugin: [embt] fix allowTypedFunctionExpressions (#1553) (9e7d161)
  • eslint-plugin: [require-await] improve performance (#1536) (45ae0b9)
  • typescript-estree: fix regression introduced in #1525 (#1543) (bec4572)
  • typescript-estree: persisted parse and module none (#1516) (7c70323)

Features

  • eslint-plugin: [no-extra-non-null-assert] add fixer (#1468) (54201ab)
  • eslint-plugin: [no-float-prom] fixer + msg for ignoreVoid (#1473) (159b16e)
  • eslint-plugin: [unbound-method] support bound builtins (#1526) (0a110eb)
  • eslint-plugin: add extension [no-dupe-class-members] (#1492) (b22424e)
  • eslint-plugin: add no-unnecessary-boolean-literal-compare (#242) (6bebb1d)
  • eslint-plugin: add switch-exhaustiveness-check rule (#972) (9e0f6dd)
  • eslint-plugin: support negative matches for filter (#1517) (b24fbe8)
Commits

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

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

[macos] unable to compile poco_vendor

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.

rosdep always installs binaries for Eloquent

Description

If we want to run CI for a different ROS distribution using a binary installation, rosdep will only install binary dependencies for Eloquent.

Expected Behavior

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).

Actual Behavior

rosdep always uses Eloquent regardless of what binary ROS installation is required.

To Reproduce

  1. See https://github.com/jacobperron/ros2_java/runs/485607460?check_suite_focus=true
  2. Click on 'Run ros-tooling/action-ros-ci'
  3. See L95: we source '/opt/ros/dashing/setup.bash' but use the flag --rosdistro eloquent

I believe this is causing the subsequent build failure since it cannot find the required package in Dashing.

System (please complete the following information)

  • OS: Ubuntu Bionic
  • ROS 2 Distro: Dashing

Running Actions in forked repos

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.

Add support for building and testing more than one package

Description

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

Test Plan

  • End to end integration test

Documentation Plan

  • README.md update

Release Plan

  • Release the impacted packages again, and update the workflows as needed.

Acceptance Criteria

  • Code has been implemented, reviewed and merged.
  • Test plan has been completed
  • Release plan has been completed

Once all above items are checked, this story can be moved to done.

[Feature Request] Options to use colcon user configuration override

Description

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

Related Issues

#89

Build Debian packages using Bloom and GitHub actions

Description

As a GH action user, I can run Bloom pre-release script to generate Debian packages for my software.

Test Plan

  • End to end integration test

Documentation Plan

  • README.md update

Release Plan

  • Release the impacted packages again, and update the workflows as needed.

Acceptance Criteria

  • Code has been implemented, reviewed and merged.
  • Test plan has been completed
  • Release plan has been completed

Once all above items are checked, this story can be moved to done.

Action required: Greenkeeper could not be activated 🚨

🚨 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.

action-ros2-ci reports success even though a cmake invocation failed

@zmichaels11 commented on Tue Nov 19 2019

Description

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.

Expected Behavior

The GitHub action should have reported a failure.

Actual Behavior

The GitHub action reported success.

To Reproduce

See the following rosbag2_bag_v2 CI run.

System

  • OS: Ubuntu Bionic
  • ROS2 Distro: from source

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.