The dependency @actions/io was updated from 1.0.1 to 1.0.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@actions/io is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

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

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.

Your Greenkeeper Bot 🌴

Description

General problem: OpenSSL libraries are not available on GitHub hosted runners for Windows. They are also not installed by the setup-ros action.

Specific problem: I'm trying to build an overlay workspace for generating messages with a custom IDL generator. This requires rosidl_default_generators which ultimately pulls in rosidl_typesupport_fastrtps_cConfig.cmake and fastrtps-config.cmake which, for the binary distribution, has a hard dependency on SSL.

Expected Behavior

OpenSSL is a ROS2 dependency, so I would expect this action to properly install and configure OpenSSL and required environment variables.

Actual Behavior

Output such as:

CMake Error at C:/Program Files/CMake/share/cmake-3.14/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
  system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY
  OPENSSL_INCLUDE_DIR)

To Reproduce

I've attached an overlay repos file (ros2_message_overlay.txt) which fails to build in a GitHub Action due to missing OpenSSL.

Alternatively, I've also produced a similar output building an overlay workspace which contains nothing but the unique_identifier_msgs package.

ros2_message_overlay.txt

System (please complete the following information)

• OS: Windows 10
• ROS 2 Distro: Eloquent

Description

A minimal invocation of the action fails on Ubuntu 16.04 / Kinetic with a Python syntax error. It succeeds on newer versions of Ubuntu and ROS. In the past, version 0.1 worked for this configuration. Now neither 0.1 nor 0.1.1 work.

Expected Behavior

The action should install ROS.
Here is a full log from a non-minimal project that worked in the past using version 0.1:
https://github.com/USC-ACTLab/crazyswarm/runs/1474716845

Actual Behavior

In a minimal example, we get the error log:
https://github.com/uscresl/gh-actions-ros-test/runs/1775400275
The last error message is:

Traceback (most recent call last):
  File "/usr/local/bin/pip3", line 7, in <module>
    from pip._internal.cli.main import main
  File "/usr/local/lib/python3.5/dist-packages/pip/_internal/cli/main.py", line 60
    sys.stderr.write(f"ERROR: {exc}")
                                 ^
SyntaxError: invalid syntax

We also a different python syntax error in new CI runs of Crazyswarm non-minimal example that worked before (see "Expected Behavior"):
https://github.com/USC-ACTLab/crazyswarm/runs/1775473914
The different error could be because of different dependencies, or because I disabled ROS_PARALLEL_JOBS to make the minimal example more deterministic.

I both cases, I believe the action is trying to execute some Python 3 code with a Python 2 interpreter.

To Reproduce

create a Github Action containing:

name: Test ROS CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-16.04
    steps:
    - name: Checkout
      uses: actions/checkout@v2      
    - name: Install ROS
      uses: ros-tooling/[email protected]
      with:
        required-ros-distributions: kinetic

System (please complete the following information)

• OS: Ubuntu 16.04
• ROS Distro: Kinetic

Description

setup-ros and action-ros-ci are frequently used together as part of the same workflow. It would be good to have an integration test workflow with action-ros-ci to verify that any changes in setup-ros don't break the action-ros-ci workflow.

Completion Criteria

• A workflow that sets up and builds ROS1 and ROS2 LTS distros
• The workflow is considered successful if it completes.

Implementation Notes / Suggestions

See other packages for examples:

• rosbag2
• cross_compile

Testing Notes / Suggestions

This feature is a test.

Description

apt-key can cause setup to fail.

Expected Behavior

ROS setup succeeds

Actual Behavior

ROS setup fails with the below log.

Invoking "sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654"
  sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654
  Warning: apt-key output should not be parsed (stdout is not a terminal)
  Executing: /tmp/apt-key-gpghome.w9Df9769Y0/gpg.1.sh --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654
  gpg: connecting dirmngr at '/tmp/apt-key-gpghome.w9Df9769Y0/S.dirmngr' failed: IPC connect call failed
  gpg: keyserver receive failed: No dirmngr
##[error]The process 'sudo' failed with exit code 2

To Reproduce

Not sure how common this is, but I've observed it at least twice:

https://github.com/ros2/rmw_cyclonedds/runs/555651315
https://github.com/ros2/rmw_cyclonedds/runs/565850574

System (please complete the following information)

• OS: Ubuntu Bionic
• ROS 2 Distro: N/A

Additional context

It is probably sufficient to use apt-key add with a local key file instead of apt-key adv.

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

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

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.

Description

Setuptools 60 has switched back to their version of distutils(pypa/setuptools#2896). Therefore running python setup.py install with the argument --install-layout=deb fails. Because the setuptools version of distutils doesn't have the --install-layout argument.

python setup.py install is trigger in https://github.com/ros/catkin/blob/noetic-devel/cmake/templates/python_distutils_install.sh.in, which is trigger by colcon build --event-handlers console_cohesion+ --symlink-install

Expected Behavior

Just performing the install procedure

Actual Behavior

/usr/bin/env PYTHONPATH=/home/runner/work/rosbridge_suite/rosbridge_suite/ros_ws/install/rosbridge_library/lib/python3/dist-packages:/home/runner/work/rosbridge_suite/rosbridge_suite/ros_ws/build/rosbridge_library/lib/python3/dist-packages:/opt/ros/noetic/lib/python3/dist-packages CATKIN_BINARY_DIR=/home/runner/work/rosbridge_suite/rosbridge_suite/ros_ws/build/rosbridge_library /usr/bin/python3 /home/runner/work/rosbridge_suite/rosbridge_suite/ros_ws/src/04qw58xlp1nu/rosbridge_suite/rosbridge_library/setup.py build --build-base /home/runner/work/rosbridge_suite/rosbridge_suite/ros_ws/build/rosbridge_library install --root=/ --install-layout=deb --prefix=/home/runner/work/rosbridge_suite/rosbridge_suite/ros_ws/install/rosbridge_library --install-scripts=/home/runner/work/rosbridge_suite/rosbridge_suite/ros_ws/install/rosbridge_library/bin
  usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: setup.py --help [cmd1 cmd2 ...]
     or: setup.py --help-commands
     or: setup.py cmd --help
  
  error: option --install-layout not recognized
  CMake Error at catkin_generated/safe_execute_install.cmake:4 (message):
    
    execute_process(/home/runner/work/rosbridge_suite/rosbridge_suite/ros_ws/build/rosbridge_library/catkin_generated/python_distutils_install.sh)
    returned error code

System (please complete the following information)

• OS: Ubuntu 20.04
• ROS Distro: Noetic

Additional context

I have created the issue here. As this action installs setuptools. You also chose to especially install setuptools with pip with --upgrade to overrule the debian version.

Description

setup-ros uses chocolatey to install some dependencies, including cppcheck.

Expected Behavior

cppcheck is installed correctly, the action keeps going.

Actual Behavior

Job fails at the chocolatey install step: https://github.com/ros-tooling/action-ros-ci/runs/6579049120?check_suite_focus=true#step:5:29

To Reproduce

Run action on Windows.

System (please complete the following information)

• OS: Windows
• ROS 2 Distro: any

Additional context

This worked fine yesterday for ros-tooling/action-ros-ci#749, but it was installing cppcheck 2.7

  cppcheck v2.7 [Approved]
  cppcheck package files install completed. Performing other installation steps.
  Downloading cppcheck 64 bit
    from 'https://github.com/danmar/cppcheck/releases/download/2.7/cppcheck-2.7-x64-Setup.msi'
  
  Download of cppcheck-2.7-x64-Setup.msi (21.55 MB) completed.
  Hashes match.
  Installing cppcheck...
  cppcheck has been installed.
  PATH environment variable does not have C:\Program Files\Cppcheck in it. Adding...
    cppcheck may be able to be automatically uninstalled.
  Environment Vars (like PATH) have changed. Close/reopen your shell to
   see the changes (or in powershell/cmd.exe just type `refreshenv`).
   The install of cppcheck was successful.
    Software installed as 'MSI', install location is likely default.

https://github.com/ros-tooling/action-ros-ci/runs/6562956458?check_suite_focus=true#step:5:29

It's now trying to install cppcheck 2.8 and failing:

  cppcheck v2.8 [Approved]
  cppcheck package files install completed. Performing other installation steps.
  Downloading cppcheck 64 bit
    from 'https://github.com/danmar/cppcheck/releases/download/2.8/cppcheck-2.8-x64-Setup.msi'
  
  Download of cppcheck-2.8-x64-Setup.msi (16.49 MB) completed.
  Hashes match.
  Installing cppcheck...
  ERROR: Running ["C:\Windows\System32\msiexec.exe" /i "C:\Users\runneradmin\AppData\Local\Temp\chocolatey\cppcheck\2.8\cppcheck-2.8-x64-Setup.msi" /quiet ADDLOCAL=CppcheckCore,CLI,GUI,Translations,ConfigFiles,PlatformFiles,PythonAddons,CRT /norestart ] was not successful. Exit code was '3010'. See log for possible error messages.
    cppcheck may be able to be automatically uninstalled.
   The install of cppcheck was successful.
    Software installed as 'MSI', install location is likely default.

https://github.com/ros-tooling/action-ros-ci/runs/6579049120?check_suite_focus=true#step:5:29

Exit code 3010 seems to mean that the system should be rebooted:

  Packages requiring reboot:
   - cppcheck (exit code 3010)
  
  The recent package changes indicate a reboot is necessary.
   Please reboot at your earliest convenience.

https://github.com/ros-tooling/action-ros-ci/runs/6579049120?check_suite_focus=true#step:5:94

Not sure why it's now happening with version 2.8, but we could probably pin cppcheck to 2.7.

Description

Completion Criteria

Users can install ROS 2 Galactic (through required-ros-distributions).

Implementation Notes / Suggestions

Galactic isn't currently "released," so it is not currently available through the normal apt repository. However, for now users can use the testing repo (through use-ros2-testing). See: https://discourse.ros.org/t/ros-2-galactic-beta-and-call-for-testing/20234

Testing Notes / Suggestions

Just add galactic to a test matrix.

Description

Expected Behavior

Compilation failure should not occur from the base libraries (pluginlib in this case) installed in the setting.

Actual Behavior

Compilation crash with the following error code.

--- stderr: plugin_example
In file included from /root/target_ws/src/ros2_tutorial/plugin_example/src/plugin_loader.cpp:21:
/opt/ros/foxy/include/pluginlib/class_loader.hpp:55:10: fatal error: boost/shared_ptr.hpp: No such file or directory
55 | #include <boost/shared_ptr.hpp>
| ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

To Reproduce

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

1. Use the below and test CI
   • uses: ros-tooling/[email protected]
   • uses: ros-tooling/[email protected]
2. Logs print error
   --- stderr: plugin_example
   In file included from /root/target_ws/src/ros2_tutorial/plugin_example/src/plugin_loader.cpp:21:
   /opt/ros/foxy/include/pluginlib/class_loader.hpp:55:10: fatal error: boost/shared_ptr.hpp: No such file or directory
   55 | #include <boost/shared_ptr.hpp>
   | ^~~~~~~~~~~~~~~~~~~~~~
   compilation terminated.

System (please complete the following information)

• OS: ubuntu-20.04
• ROS 2 Distro: foxy

Description

setup-ros fails on apt-get install with many 404 errors. I saw this yesterday in a few runs on the bionic docker image, and it seems to be no longer affected so it may have been a transient bug.

Expected Behavior

Setup-ros runs cleanly.

Actual Behavior

Setup-ros fails with many 404 errors like:

  Err:4 http://packages.ros.org/ros2/ubuntu bionic/main amd64 ros-dashing-ament-cmake-core amd64 0.7.5-1bionic.20200711.043737
    404  Not Found [IP: 64.50.236.52 80]
  Err:5 http://packages.ros.org/ros2/ubuntu bionic/main amd64 ros-dashing-ros-workspace amd64 0.7.2-1bionic.20200711.043848
    404  Not Found [IP: 64.50.236.52 80]
  Err:6 http://packages.ros.org/ros2/ubuntu bionic/main amd64 ros-dashing-ament-cmake-export-definitions amd64 0.7.5-1bionic.20200711.044202
    404  Not Found [IP: 64.50.236.52 80]
  Err:7 http://packages.ros.org/ros2/ubuntu bionic/main amd64 ros-dashing-ament-cmake-libraries amd64 0.7.5-1bionic.20200711.044210
    404  Not Found [IP: 64.50.236.52 80]
  Err:8 http://packages.ros.org/ros2/ubuntu bionic/main amd64 ros-dashing-ament-cmake-export-dependencies amd64 0.7.5-1bionic.20200711.044333
    404  Not Found [IP: 64.50.236.52 80]
  Err:9 http://packages.ros.org/ros2/ubuntu bionic/main amd64 ros-dashing-ament-cmake-export-include-directories amd64 0.7.5-1bionic.20200711.044217
    404  Not Found [IP: 64.50.236.52 80]

https://github.com/RoverRobotics/openrover-ros2/runs/903437204#step:3:2302

To Reproduce

https://github.com/RoverRobotics/openrover-ros2/runs/903437204#step:3:2302

System (please complete the following information)

• OS: Ubuntu Bionic
• ROS 2 Distro: Dashing

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.

Your Greenkeeper Bot 🌴

Description

Both the scheduled tests for xenial and kinetic are failing.

Expected Behavior

These tests should pass.

Actual Behavior

Xenial

      Complete output from command python setup.py egg_info:
      Traceback (most recent call last):
        File "<string>", line 1, in <module>
        File "/tmp/pip-build-k5hdlbcq/numpy/setup.py", line 30, in <module>
          raise RuntimeError("Python version >= 3.6 required.")
      RuntimeError: Python version >= 3.6 required.
      
      ----------------------------------------
  Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-k5hdlbcq/numpy/
  You are using pip version 8.1.1, however version 20.1.1 is available.
  You should consider upgrading via the 'pip install --upgrade pip' command.
##[error]The process '/usr/bin/sudo' failed with exit code 1

Kinetic

      Complete output from command python setup.py egg_info:
      Traceback (most recent call last):
        File "<string>", line 1, in <module>
        File "/tmp/pip-build-70vtrzws/numpy/setup.py", line 30, in <module>
          raise RuntimeError("Python version >= 3.6 required.")
      RuntimeError: Python version >= 3.6 required.
      
      ----------------------------------------
  Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-70vtrzws/numpy/
  You are using pip version 8.1.1, however version 20.1.1 is available.
  You should consider upgrading via the 'pip install --upgrade pip' command.
##[error]The process '/usr/bin/sudo' failed with exit code 1

To Reproduce

1. Go to https://github.com/ros-tooling/setup-ros/actions?query=event%3Aschedule
2. View Failed Tests

Description

As the ROS2 GPG key has recently expired, the current version of this action fails with an error:

  W: GPG error: http://packages.ros.org/ros/ubuntu focal InRelease: The following signatures were invalid: EXPKEYSIG F42ED6FBAB17C654 Open Robotics <[email protected]>
  E: The repository 'http://packages.ros.org/ros/ubuntu focal InRelease' is not signed.
  W: GPG error: http://packages.ros.org/ros2/ubuntu focal InRelease: The following signatures were invalid: EXPKEYSIG F42ED6FBAB17C654 Open Robotics <[email protected]>
  E: The repository 'http://packages.ros.org/ros2/ubuntu focal InRelease' is not signed.

Expected Behavior

The action should complete without issues.

To Reproduce

I believe every build with this action will fail for now.

  name: ROS 2 CI Action new release
  
  on:
  pull_request:
  push:
    branches:
      - master
      
  jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
    - name: Setup ROS 2
      uses: ros-tooling/[email protected]
      with:
        required-ros-distributions: foxy

    - name: Run Tests
      uses: ros-tooling/[email protected]
      with:
        package-name: umrr_ros2_driver
        import-token: ${{ secrets.REPO_TOKEN }}
        target-ros2-distro: foxy

Description

For ROS Kinetic, running [email protected] with [email protected] I see the following error during colcon test:

  ERROR:colcon.colcon_core.plugin_system:Exception instantiating extension 'colcon_core.python_testing.pytest': invalid syntax (compat.py, line 39)
  Traceback (most recent call last):
    File "/usr/local/lib/python3.5/dist-packages/colcon_core/plugin_system.py", line 60, in _instantiate_extension
      extension_instance = extension_class()
    File "/usr/local/lib/python3.5/dist-packages/colcon_core/task/python/test/pytest.py", line 32, in __init__
      import pytest  # noqa: F401
    File "/usr/local/lib/python3.5/dist-packages/pytest/__init__.py", line 3, in <module>
      from . import collect
    File "/usr/local/lib/python3.5/dist-packages/pytest/collect.py", line 8, in <module>
      from _pytest.deprecated import PYTEST_COLLECT_MODULE
    File "/usr/local/lib/python3.5/dist-packages/_pytest/deprecated.py", line 13, in <module>
      from _pytest.warning_types import PytestDeprecationWarning
    File "/usr/local/lib/python3.5/dist-packages/_pytest/warning_types.py", line 8, in <module>
      from _pytest.compat import final
    File "/usr/local/lib/python3.5/dist-packages/_pytest/compat.py", line 39
      NOTSET: "Final" = NotSetType.token  # noqa: E305
            ^
  SyntaxError: invalid syntax

To Reproduce

See https://github.com/AutonomyLab/create_robot/runs/1619916143?check_suite_focus=true

System (please complete the following information)

• OS: Ubuntu Xenial
• ROS Distro: Kinetic

Additional context

Trying to reproduce locally, I ran into an separate issue due to pip3 not being up-to-date. On a hunch, I added a step to the workflow file that upgrades pip3 and the issue disappeared (for example). I've opened up the ticket here instead of action-ros-ci, since it seems like we should probably be upgrading pip3 as part of this action (though I'm not 100% sure).

@thomas-moulard commented on Fri Oct 18 2019

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.

The devDependency eslint was updated from 6.7.1 to 6.7.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

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

Your Greenkeeper Bot 🌴

Description

setup-ros sometimes fails to fetch its Windows dependencies

Expected Behavior

I expect setup-ros to install its Windows dependencies reliably.

Actual Behavior

  ERROR: The remote file either doesn't exist, is unauthorized, or is forbidden for url 'https://github.com/danmar/cppcheck/releases/download/1.90/cppcheck-1.90-x64-Setup.msi'. Exception calling "GetResponse" with "0" argument(s): "The remote server returned an error: (403) Forbidden." 

https://github.com/ros2/rmw_cyclonedds/runs/654673318?check_suite_focus=true#step:3:53

  ERROR: The remote file either doesn't exist, is unauthorized, or is forbidden for url 'https://sourceforge.net/projects/gnuwin32/files/patch/2.5.9-7/patch-2.5.9-7-bin.zip'. Exception calling "GetResponse" with "0" argument(s): "Unable to connect to the remote server" 

https://github.com/ros2/rmw_cyclonedds/runs/653633315?check_suite_focus=true#step:3:20

To Reproduce

Run as a Github Action.

System (please complete the following information)

• OS: Windows

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

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

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.

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

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

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.

Description

This is a very useful action step for setting up a workflow that compiles packages in a colcon workspace. Since colcon is a tool that can be used in non-ROS contexts, I wanted to see if there is interest in using this action without installing DDS packages.

cc @stonier

Related Issues

N/A

Completion Criteria

Add a parameter for skipping installation of DDS packages.

Implementation Notes / Suggestions

It looks like the logic for installing DDS implementations is intermingled with the logic for installing compilers and development tools in the package_manager/apt.ts file.

DDS-specific lines:

• https://github.com/ros-tooling/setup-ros/blob/39f9fe76c8bf5baaa/src/package_manager/apt.ts#L7
• https://github.com/ros-tooling/setup-ros/blob/39f9fe76c8bf5baaa/src/package_manager/apt.ts#L30-L34
• https://github.com/ros-tooling/setup-ros/blob/39f9fe76c8bf5baaa/src/package_manager/apt.ts#L39-L40
• https://github.com/ros-tooling/setup-ros/blob/39f9fe76c8bf5baaa/src/package_manager/apt.ts#L52-L53

Perhaps the DDS-specific lines could be split into a separate file to more easily enable or disable the DDS packages.

Testing Notes / Suggestions

Test a typical ROS workflow with DDS installed and a workflow without DDS installed and confirm that the setup time is reduced without the extra packages.

Description

On this line the path to python3.7 is hard coded to version 3.7.6.

The GitHub Windows runner was recently updated such that the default python version is now 3.7.7. This causes errors with the ROS setup step.

This can be worked around by using the actions/setup-python action to configure Python 3.7.6 prior to running the ros-tooling/setup-ros action as follows:

    - uses: actions/setup-python@v2
      with:
        python-version: '3.7.6'

    - uses: ros-tooling/[email protected]

But I think ideally the system python version/path ought to be queried instead of hardcoded -- not really sure.

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 should have reported success.

To Reproduce

See the following rosbag2 CI run.

System

• OS: Ubuntu Bionic
• ROS2 Distro: from source

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.

Your Greenkeeper Bot 🌴

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

Your Greenkeeper Bot 🌴

Description

i think im seeing this right but it looks like this action is hanging after "rosdep init" for windows and never actually installs ROS2 binaries.

Expected Behavior

install ROS2 binaries

Actual Behavior

hangs (awaits) on rosdep init step.

To Reproduce

see it in action here

System (please complete the following information)

• OS: Windows 10
• ROS 2 Distro: Any

Additional context

looking at the ts for this action it looks like the windows part awaits setting up the ROS2 dependencies before actually installing the ROS2 binaries. I am no expert in TS but i would guess this is where the issue is.

Description

Hey : trying to setup CI for a driver package using your Github Actions toolbox. During the setup step, the process failed, supposedly due to unmet dependency to install ros-melodic-desktop.

name: ROS Continuous Integration

on:
  pull_request:
  push:
    branches:
      - master

jobs:
  build-and-test:
    runs-on: ubuntu-18.04
    steps:
    - name: Setup ROS Melodic
      uses: ros-tooling/[email protected]
      with:
        required-ros-distributions: melodic

Expected Behavior

Clean installation of ros melodic on the environment. ( tested the same script with eloquent, it went smoothly. )
Also tested the same script with kinetic, installation failed

EDIT : Kinetic installation failure is normal, as it's not supported with ubuntu 18.04. Kinetic setup works fine with 16.04.

Actual Behavior

Invoking "sudo DEBIAN_FRONTEND=noninteractive RTI_NC_LICENSE_ACCEPTED=yes apt-get install --no-install-recommends --quiet --yes ros-melodic-desktop"
  sudo DEBIAN_FRONTEND=noninteractive RTI_NC_LICENSE_ACCEPTED=yes apt-get install --no-install-recommends --quiet --yes ros-melodic-desktop
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:
  
  The following packages have unmet dependencies:
   ros-melodic-desktop : Depends: ros-melodic-common-tutorials but it is not going to be installed
                         Depends: ros-melodic-geometry-tutorials but it is not going to be installed
                         Depends: ros-melodic-robot but it is not going to be installed
                         Depends: ros-melodic-ros-tutorials but it is not going to be installed
                         Depends: ros-melodic-urdf-tutorial but it is not going to be installed
                         Depends: ros-melodic-visualization-tutorials but it is not going to be installed
                         Depends: ros-melodic-viz but it is not going to be installed
  E: Unable to correct problems, you have held broken packages.
##[error]The process 'sudo' failed with exit code 100

To Reproduce

Error occured for this repo. Just use the rosci.yml file in .github/workflows to reproduce the error.

System (please complete the following information)

• OS: Ubuntu 18.04
• ROS Distro : Melodic

Additional context

Just trying to figure out your tool for later projects.

Description

We currently hardcode paths to Windows binary release archives and have to update the paths manually when new distros/distro patches are released:

setup-ros could try to automatically detect and use the latest binary release for a given distro.

Related Issues

This feature request includes macOS assuming that this related feature is implemented: #107

Completion Criteria

• latest binary releases are automatically fetched and used

Implementation Notes / Suggestions

See #450 (comment)

We could fetch releases using the GitHub API and check the tags. The tag format is always release-$DISTRO-YYYYMMDD. Then we check the assets and pick the one for a given platform. This part might be a bit trickier, but it should work.

Testing Notes / Suggestions

Description

As a GH action user, my pipelines infrequently fail due to infrastructure connectivity issues.

We should evaluate whether all parts currently requiring internet connectivity could be cached, including:

• pip
• apt
• choco
• ccache (?)

Test Plan

• FIXME

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.

Description

When using osrf:ros2/devel , rosdep init returns an error as it is already initialized, crashing the whole action

Expected Behavior

Error handling is needed on the rosdep init command to attempt to continue if it already has run

To Reproduce

• Use container: image: osrf:ros2/devel
• Include setup-ros@master

System (please complete the following information)

• OS: Ubuntu Focal
• ROS 2 Distro: devel/Foxy

Additional context

Using commit 2c05014:
https://github.com/Arnatious/nodl/runs/675769690?check_suite_focus=true#step:3:661

Description

This would allow users to use a specific snapshot (i.e. a specific distro at a specific datestamp, or the "final" sync for EOL distros).

See:

• https://discourse.ros.org/t/announcing-ros-snapshot-repositories/7705
• http://wiki.ros.org/SnapshotRepository

Related Issues

-

Completion Criteria

Users can configure the action to use distros x & y at sync datestamps X & Y from the snapshots repository.

Implementation Notes / Suggestions

Add a new snapshots input which is empty by default (current behaviour). Ignore the input/value if not on Ubuntu/Linux (or fail in that case?).

If the value is not empty, use the snapshots repository (http://snapshots.ros.org/${ROS_DISTRO}/${INPUT_SNAPSHOTS}/ubuntu) instead of the usual one (http://packages.ros.org/ros2/ubuntu).

If only one distro is declared with required-ros-distributions, use that value:

  with:
    required-ros-distributions: foxy
    snapshots: 2021-01-07

If multiple distros are declared with required-ros-distributions, expect a JSON object/dictionary:

  with:
    required-ros-distributions: noetic foxy
    snapshots: |
      {
        "foxy": "2021-01-07",
        "noetic": "2021-01-22"
      }

This will require some input validation.

Testing Notes / Suggestions

A job that uses the snapshots input once for a single distro and once for multiple distros/sync datestamps.

Unit tests for the snapshots input validation.

Description

Install binary arbitrary ROS 2 distributions on OS X using Open Robotics archives: https://github.com/ros2/ros2/releases

Completion Criteria

• required-ros-distributions flag is supported on OS X

Implementation Notes / Suggestions

The approach we're relying on on Windows can just be adapted in the action.

Testing Notes / Suggestions

Need an e2e test.

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

Description

The setup-ros2 action installs the default version of clang, which is very helpful, but we have some software that requires a newer version of clang, so it would be nice if we could pass the major version of clang as a parameter to the setup-ros2 action.

Related Issues

N/A

Completion Criteria

Expose an parameter that takes an integer and attempts to install clang packages that match that major version and calls update-alternatives to ensure that those versions are called with unversioned commands like clang and clang++.

Implementation Notes / Suggestions

The bash code we currently use for this is given below:

#######################################
# Installs clang suite packages.
# Arguments:
#   Version of the clang suite package.
# Returns:
#   0 if no error was detected, non-zero otherwise.
#######################################
function install_clang_suite() {
  local version=$1

  apt install -y \
              clang-${version} \
              lldb-${version} \
              lld-${version} \
              clang-format-${version} \
              clang-tidy-${version} \
              libc++-${version}-dev \
              libc++abi-${version}-dev
}

#######################################
# Setups alternatives for clang suite.
# Arguments:
#   Version of the clang suite package.
# Returns:
#   0 if no error was detected, 2 otherwise.
#######################################
function update_clang_suite_alternatives() {
  local version=$1
  local priority=$2

  update-alternatives \
    --install /usr/bin/clang                 clang                 /usr/bin/clang-${version}  ${priority}\
    --slave   /usr/bin/clang++               clang++               /usr/bin/clang++-${version}  \
    --slave   /usr/bin/asan_symbolize        asan_symbolize        /usr/bin/asan_symbolize-${version} \
    --slave   /usr/bin/c-index-test          c-index-test          /usr/bin/c-index-test-${version} \
    --slave   /usr/bin/clang-check           clang-check           /usr/bin/clang-check-${version} \
    --slave   /usr/bin/clang-cl              clang-cl              /usr/bin/clang-cl-${version} \
    --slave   /usr/bin/clang-cpp             clang-cpp             /usr/bin/clang-cpp-${version} \
    --slave   /usr/bin/clang-format          clang-format          /usr/bin/clang-format-${version} \
    --slave   /usr/bin/clang-format-diff     clang-format-diff     /usr/bin/clang-format-diff-${version} \
    --slave   /usr/bin/clang-import-test     clang-import-test     /usr/bin/clang-import-test-${version} \
    --slave   /usr/bin/clang-include-fixer   clang-include-fixer   /usr/bin/clang-include-fixer-${version} \
    --slave   /usr/bin/clang-offload-bundler clang-offload-bundler /usr/bin/clang-offload-bundler-${version} \
    --slave   /usr/bin/clang-query           clang-query           /usr/bin/clang-query-${version} \
    --slave   /usr/bin/clang-rename          clang-rename          /usr/bin/clang-rename-${version} \
    --slave   /usr/bin/clang-reorder-fields  clang-reorder-fields  /usr/bin/clang-reorder-fields-${version} \
    --slave   /usr/bin/clang-tidy            clang-tidy            /usr/bin/clang-tidy-${version} \
    --slave   /usr/bin/lldb                  lldb                  /usr/bin/lldb-${version} \
    --slave   /usr/bin/lldb-server           lldb-server           /usr/bin/lldb-server-${version}
}

# example for using these bash functions to install clang8:
CLANG_SUITE_VERSION=8
CLANG_SUITE_ALTERNATIVE_PRIORITY=10
apt update
install_clang_suite ${CLANG_SUITE_VERSION}
update_clang_suite_alternatives ${CLANG_SUITE_VERSION} ${CLANG_SUITE_ALTERNATIVE_PRIORITY}

Testing Notes / Suggestions

Run the action with different values of the clang version and evaluate the output of clang --version, clang++ --version, etc. to confirm that the correct version has been installed.

The devDependency @types/node was updated from 13.5.2 to 13.5.3.

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

Your Greenkeeper Bot 🌴

Description

⚠️ Before starting, we need to understand if this is needed. If rosdep can properly pull dependencies, action-ros2-ci rosdep run may provide this to us "for free".

As a GH action user, I want to install a specific version of ROS1 using OSRF Debian packages.

This should be implemented by executing commands on the host machines, not through Docker (to keep the ROS1/ROS2 codepath similar for now, this can be re-evaluated down the road).

This requires splitting the current logic into multiple modules to prevent code duplication.

The API could look like this:

- uses: ros-tooling/[email protected]
  with:
    - version: ros1-melodic
    - variant: desktop
    # etc.

Allowed values for version be: ros-melodic, ros-source, ros2-dashing, ros2-source, etc.
We would default to ros2-source to avoid breaking compatibility.

Test Plan

• Unit test for new classes
• End to end integration test

Documentation Plan

• README.md update

Release Plan

• setup-ros2 should be re-released

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.

References

• Minimal ROS2 installation

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.

Your Greenkeeper Bot 🌴

Description

Setup fails to call rosdep

https://github.com/ros2/rmw_cyclonedds/runs/565850604?check_suite_focus=true

Expected Behavior

Rosdep succeeds.

Actual Behavior

Rosdep fails.

   Installing collected packages: distro, rospkg, rosdistro, rosdep, vcstool
  Successfully installed distro-1.5.0 rosdep-0.19.0 rosdistro-0.8.0 rospkg-1.2.4 vcstool-0.2.7
Invoking "python c:\python37\scripts\rosdep init"
  python c:\python37\scripts\rosdep init
  python: can't open file 'c:\python37\scripts\rosdep': [Errno 2] No such file or directory
##[error]The process 'python' failed with exit code 2

Additional context

I expect this is caused by ros-infrastructure/rosdep#656, and that calling rosdep as an executable will now work, instead of having to call python <path/to/script>.

Description

Windows builds seem to miss the file sys/wait.h, resulting in builds of the package osrf_testing_tools_cpp (see, this PR for example) to fail. osrf_testing_tools_cpp builds without this issue in my local Windows 10 setup.

Expected Behavior

Setup provides all required files to build ROS 2 packages on Windows 10.

Actual Behavior

Build of ROS 2 package osrf_testing_tools_cpp fails on Windows 10 with:

fatal error C1083: Cannot open include file: 'sys/wait.h': No such file or directory [D:\a\system_modes\system_modes\ros_ws\build\osrf_testing_tools_cpp\src\test_runner\test_runner.vcxproj]
  ---Failed   <<< osrf_testing_tools_cpp

To Reproduce

1. Enable ros-tooling actions for a ROS 2 package that depends on osrf_testing_tools_cpp
2. Add ros-tooling/setup-ros and ros-tooling/action-ros-ci (ros-tooling/[email protected] and ros-tooling/[email protected] in my repo)
3. Enable build for OS windows-latest

System

• OS: windows-latest
• ROS 2 Distro: foxy
• find a complete setup that reproduces this error in the system modes repository.

Description

This action is very slow, it often takes 3-4 minutes to run (example). Have you considered or tried simply running action-ros-ci inside a ros:*-ros-core container? Is that a supported workflow? (at least on Linux, I don't think Github Actions supports Windows containers yet).

Alternatively, I notice this action installs ros-distrib-desktop. Is that a necessary default? I would have though that most libraries could get away with installing only core or base to run CI.

Completion Criteria

I think it would be nice if this action could run in under 1 minute, or be bypassed entirely on linux if the container path is feasible.

Implementation Notes / Suggestions

See above

Description

As a ROS2 user, I should be able to run CI on packages depending on ros1_bridge.

ros1_bridge is a corner case because it depends on ROS1 and ROS2.

We need also to iron out what are the combinations of distros we want to support (kinetic, melodic, src) x (dashing, eloquent, source)...

Test Plan

• End to end integration test

Documentation Plan

• README.md update

Release Plan

• Re-release the impact packages

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.

Resources

• ros1_bridge

Description

By installing the "ros-{distro}-desktop" variant in this action, CI will not correctly verify whether package.xml files are written properly. This action should set up the package manager environment, and install no packages whatsoever, requiring rosdep to run based on the package.xml in the target environment, which would actually validate that its dependencies are set up correctly.

Expected Behavior

If I do not specify a dependency on rclcpp in my package.xml, but I use it in CMake, my build should fail

Actual Behavior

My build succeeds because the entire desktop variant is installed by default.

To Reproduce

System (please complete the following information)

• OS: Ubuntu [any]
• ROS 2 Distro: any

Additional context

** Add any other context about the problem here **

Description

The default runners in Github actions use pretty bad apt sources, causing unnecessary CI failures.

For example this pull request, which updates just a readme causes build failures because azure's Ubuntu mirror is flaky: https://github.com/ros-tooling/action-ros-ci/pull/129/checks?check_run_id=553125397.

I work around this in ros2/rmw_cyclonedds#134 but this repo is probably a better place to solve the problem so all downstream CI workflows don't have the same reliability problems.

2020-04-01T20:20:23.8861478Z ##[group]Invoking "sudo apt-get update"
2020-04-01T20:20:23.8867344Z [command]sudo apt-get update
...
2020-04-01T20:20:54.7635136Z Err:39 http://azure.archive.ubuntu.com/ubuntu bionic InRelease
2020-04-01T20:20:54.7635929Z   Could not connect to azure.archive.ubuntu.com:80 (52.177.174.250), connection timed out
...
2020-04-01T20:22:12.2857474Z [command]sudo DEBIAN_FRONTEND=noninteractive RTI_NC_LICENSE_ACCEPTED=yes apt-get install --no-install-recommends --quiet --yes libssl-dev python3-dev build-essential clang cmake git lcov libc++-dev libc++abi-dev python3-catkin-pkg-modules python3-pip python3-vcstool wget libasio-dev libtinyxml2-dev libopensplice69 rti-connext-dds-5.3.1 python-rosdep
...
2020-04-01T20:22:43.1336618Z E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/s/sgml-base/sgml-base_1.29_all.deb  Could not connect to azure.archive.ubuntu.com:80 (52.177.174.250), connection timed out

Description

Humble will be released in May 2022: https://docs.ros.org/en/rolling/Releases/Release-Humble-Hawksbill.html#release-timeline

setup-ros should support it.

Note that we can still support Humble before its actual release. Users can test the binaries by using the testing repository, but we need to support it as a valid distro.

Related Issues

Completion Criteria

Humble is supported by setup-ros

Implementation Notes / Suggestions

Add to list of valid distros. Check distro-related conditions.

Testing Notes / Suggestions

See existing tests.

Description

For some reason, the colcon is not found after the setup-ros action

Expected Behavior

colcon is found and can be used to compile and run tests with`

Actual Behavior

I get the error: colcon: command not found
As seen in:

• https://github.com/LoyVanBeek/telegram_ros2/runs/532825694?check_suite_focus=true#step:4:2652
• https://github.com/LoyVanBeek/telegram_ros2/runs/537690031?check_suite_focus=true#step:6:6

To Reproduce

Nothing special, just the canonical, simplest use of setup-ros, as used in eg. https://github.com/LoyVanBeek/telegram_ros2/actions/runs/64102949/workflow

System (please complete the following information)

• OS: Ubuntu 18.04 on GitHub Actions
• ROS 2 Distro: Eloquent

Additional context

I'm new to ROS2 and GitHub actions, just trying to learn.

rosbag2_bag_v2 is failing to build, reporting catkin_pkg as missing.
Logs

Proposed solution: add python3-catkin-pkg-modules to apt dependencies.
I think something changed in upstream dependencies that no longer requires this module since this used to be a flaky build issue and now it consistently happens.

Description

setup-ros OSX has System Integrity Protection (SIP) enabled.

Expected Behavior

SIP should be disabled per the ROS2 Installation Wiki

Actual Behavior

SIP is enabled.

To Reproduce

1. Rerun the build at ros-tooling/libstatistics_collector#9
2. Use the tmate session to SSH to the runner
3. Verify SIP is enabled with csrutil status

System (please complete the following information)

• OS: OSX using [email protected]
• ROS 2 Distro: master

Additional context

See ros-tooling/libstatistics_collector#7 for more context.

Description

The importlib-metadata python package had a major release yesterday, which is incompatible with the latest release of argcomplete (kislyuk/argcomplete#321) for certain versions of python. I believe it is not a problem for python3.8, but I have noticed extra console spam when invoking colcon with python3.6 and ROS dashing on 18.04. I believe this would be fixed by a new release of argcomplete, but I wanted to report this here in case you want to make a workaround until the new release is made.

Expected Behavior

When using this action in an ubuntu:18.04 container with ROS dashing, I expect colcon to work without excessive console spam. For example, the colcon test-result step from this workflow should have the following output:

$ colcon test-result --verbose

Summary: 0 tests, 0 errors, 0 failures, 0 skipped

Actual Behavior

It actually has a bunch of console spam, though it does run properly and eventually print the desired information:

https://github.com/scpeters/ament_cmake_doxygen/runs/1156364551?check_suite_focus=true

$ colcon test-result --verbose
ERROR:colcon.colcon_core.entry_point:Exception loading extension 'colcon_core.environment_variable.argcomplete_timing': (importlib-metadata 2.0.0 (/usr/local/lib/python3.6/dist-packages), Requirement.parse('importlib-metadata<2,>=0.23; python_version == "3.6"'), {'argcomplete'})
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/colcon_core/entry_point.py", line 101, in load_entry_points
    extension_type = load_entry_point(entry_point)
  File "/usr/local/lib/python3.6/dist-packages/colcon_core/entry_point.py", line 143, in load_entry_point
    return entry_point.load()
  File "/usr/local/lib/python3.6/dist-packages/pkg_resources/__init__.py", line 2446, in load
    self.require(*args, **kwargs)
  File "/usr/local/lib/python3.6/dist-packages/pkg_resources/__init__.py", line 2469, in require
    items = working_set.resolve(reqs, env, installer, extras=self.extras)
  File "/usr/local/lib/python3.6/dist-packages/pkg_resources/__init__.py", line 775, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (importlib-metadata 2.0.0 (/usr/local/lib/python3.6/dist-packages), Requirement.parse('importlib-metadata<2,>=0.23; python_version == "3.6"'), {'argcomplete'})

ERROR:colcon.colcon_core.entry_point:Exception loading extension 'colcon_core.argument_parser.argcomplete': (importlib-metadata 2.0.0 (/usr/local/lib/python3.6/dist-packages), Requirement.parse('importlib-metadata<2,>=0.23; python_version == "3.6"'), {'argcomplete'})
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/colcon_core/entry_point.py", line 101, in load_entry_points
    extension_type = load_entry_point(entry_point)
  File "/usr/local/lib/python3.6/dist-packages/colcon_core/entry_point.py", line 143, in load_entry_point
    return entry_point.load()
  File "/usr/local/lib/python3.6/dist-packages/pkg_resources/__init__.py", line 2446, in load
    self.require(*args, **kwargs)
  File "/usr/local/lib/python3.6/dist-packages/pkg_resources/__init__.py", line 2469, in require
    items = working_set.resolve(reqs, env, installer, extras=self.extras)
  File "/usr/local/lib/python3.6/dist-packages/pkg_resources/__init__.py", line 775, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (importlib-metadata 2.0.0 (/usr/local/lib/python3.6/dist-packages), Requirement.parse('importlib-metadata<2,>=0.23; python_version == "3.6"'), {'argcomplete'})

Summary: 0 tests, 0 errors, 0 failures, 0 skipped

To Reproduce

1. Examine the console output from this workflow: https://github.com/scpeters/ament_cmake_doxygen/runs/1156364551?check_suite_focus=true
2. Click on colcon test
3. Scroll down to the bottom of the step.
4. Logs print error pkg_resources.ContextualVersionConflict: (importlib-metadata 2.0.0 (/usr/local/lib/python3.6/dist-packages), Requirement.parse('importlib-metadata<2,>=0.23; python_version == "3.6"'), {'argcomplete'})

System (please complete the following information)

• OS: ubuntu:18.04 docker container
• ROS 2 Distro: Dashing
• ros-tooling/[email protected]

Additional context

N/A

Description

Ubuntu 20.04 has retired python 2 packages, meaning the python-rosdep entry can't be installed.

Expected Behavior

The script on Ubuntu 20.04 uses python3-rosdep instead, and potentially removes python (which substitutes to the python-is-python2 package in focal/universe).

Actual Behavior

note the presence of python and python-rosdep

  /usr/bin/sudo DEBIAN_FRONTEND=noninteractive RTI_NC_LICENSE_ACCEPTED=yes apt-get install --no-install-recommends --quiet --yes libssl-dev python3-dev build-essential clang cmake git lcov libc++-dev libc++abi-dev python python3-catkin-pkg-modules python3-pip python3-vcstool wget libasio-dev libtinyxml2-dev libopensplice69 rti-connext-dds-5.3.1 python-rosdep
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Package python-rosdep is not available, but is referred to by another package.
  This may mean that the package is missing, has been obsoleted, or
  is only available from another source
  
  E: Unable to locate package libopensplice69
  E: Package 'python-rosdep' has no installation candidate
##[error]The process '/usr/bin/sudo' failed with exit code 100

To Reproduce

Use runs-on: ubuntu-latest and container: image: osrf/ros2:devel

System

• OS: Ubuntu Focal
• ROS 2 Distro: devel