Multiple packages found with the same name

[dave992]

I run in the following error during the install_target_dependencies step when running the CI:

$ ( source /builds/ros_meta_pkg/workspaces/upstream_ws/install/setup.bash && rosdep install --from-paths /builds/ros_meta_pkg/workspaces/target_ws --ignore-src -y | grep -E '(executing command)|(Setting up)' ; )
ERROR: Rosdep experienced an error: Multiple packages found with the same name "ros_pkg_1":
- ros_pkg_1
- workspaces/target_ws/src/ros_meta_pkg/ros_pkg_1
Multiple packages found with the same name "ros_pkg_2":
- ros_pkg_2
- workspaces/target_ws/src/ros_meta_pkg/ros_pkg_2

CI Configuration

The GitLab CI settings I use:

# Source: https://github.com/ros-industrial/industrial_ci/issues/627
ros_industrial_ci:
  image: ros:humble
  before_script:
    - apt-get -qq update && apt-get -qq install bash coreutils git grep # install industrial_ci dependencies
    - git config --add --global "url.${CI_SERVER_PROTOCOL}://gitlab-ci-token:${CI_JOB_TOKEN}@${CI_SERVER_HOST}:${CI_SERVER_PORT}/.insteadOf" "${CI_SERVER_URL}"
    - git config --add --global "url.${CI_SERVER_PROTOCOL}://gitlab-ci-token:${CI_JOB_TOKEN}@${CI_SERVER_HOST}:${CI_SERVER_PORT}/.insteadOf" "ssh://git@${CI_SERVER_HOST}:"
    - git config --add --global "url.${CI_SERVER_PROTOCOL}://gitlab-ci-token:${CI_JOB_TOKEN}@${CI_SERVER_HOST}:${CI_SERVER_PORT}/.insteadOf" "ssh://git@${CI_SERVER_HOST}/"
    - git clone --quiet --depth 1 https://github.com/sam-xl/industrial_ci .industrial_ci -b fix/rosdep_multiple_pkgs_found
  script: .industrial_ci/gitlab.sh
  variables:
    BASEDIR: "${CI_PROJECT_DIR}/workspaces"
    CCACHE_DIR: "${CI_PROJECT_DIR}/ccache"
    ISOLATION: "shell"
  cache:
    # https://docs.gitlab.com/ee/ci/caching/#sharing-caches-across-different-branches
    key: "${CI_JOB_NAME}"
    paths:
      - ccache

I took this config from #627

Observations

I only run into this error when I set $BASEDIR inside of $CI_PROJECT_DIR. Using $BASEDIR: /workspaces does not result in this error.

Interestingly enough, if I manually log into the container created by the CI job (by keeping it alive after the failure) and run the same command and from the same directory, I do not get any errors.

The command:

$ ( source /builds/ros_meta_pkg/workspaces/upstream_ws/install/setup.bash && rosdep install --from-paths /builds/ros_meta_pkg/workspaces/target_ws --ignore-src -y | grep -E '(executing command)|(Setting up)' ; )

The only way to replicate the same error is to run:

$ rosdep install --from-paths /builds/ros_meta_pkg --ignore-src -y

or

$ rosdep install --from-paths . --ignore-src -y

I do not understand why this behaves like this. Even printing the $ROS_PACKAGE_PATH shows no unexpected folders.

Folder structure

The folder structure looks like this:

ros_meta_pkg (repository)
- ros_pkg_1
- ros_pkg_2
- workspaces (created by industrial ci)
  - upstream_ws  
  - target_ws

Commands get executed from the ros_meta_pkg folder.

Possible solution

If I run the rosdep command from the target_ws I no longer run into any issues.

Looking at the source code this can be achieved by removing the /src from the following line. This step can probably be skipped.

industrial_ci/industrial_ci/src/workspace.sh

Line 396 in d23b9ad

ici_step "install_${name}_dependencies" ici_install_dependencies "$extend" "$ROSDEP_SKIP_KEYS" "$ws/src"

And replacing ici_exec_in_workspace "$extend" "." with ici_exec_in_workspace "$extend" "$@" so the command switches to the target_ws folder before executing the rosdep command

industrial_ci/industrial_ci/src/workspace.sh

Line 376 in d23b9ad

ROS_PACKAGE_PATH="$cmake_prefix_path${ROS_PACKAGE_PATH:-}" ici_cmd ici_quiet ici_filter "(executing command)|(Setting up)" ici_exec_in_workspace "$extend" "." rosdep install "${rosdep_opts[@]}"

[mathias-luedtke]

Thanks for reporting!

Unfortunately, I have not found any proper solution for this issue yet.
The recommended work-around is to set

industrial_ci/.gitlab-ci.yml

Line 81 in 53cd3f1

BASEDIR: ${CI_PROJECT_DIR}/.workspaces

This is not be documented properly, though.