Open stertingen opened 3 years ago
Very nice!
The extra mount seems a little bit hacky to me
It is not too hacky.. just one of the downside of using Docker (or containers in general). With https://github.com/ros-industrial/industrial_ci/pull/572, you can even avoid the mount :)
I thought that others might profit from this, so this could be added to the README or the example config.
Definitely! I will add it to https://gitlab.com/ipa-mdl/industrial_ci Anyway, the example config is a little bit outdated now and needs some overhaul (like most of the documentation..).
I have now added support for mounting the workspaces automatically (https://github.com/ros-industrial/industrial_ci/pull/572).
test_junit:
script: .industrial_ci/gitlab.sh
variables:
ROS_DISTRO: noetic
BASEDIR: ${CI_PROJECT_DIR}/.build
artifacts:
when: always
reports:
junit: ${BASEDIR}/**/test_results/**/*.xml
(results: https://gitlab.com/ipa-mdl/industrial_ci/-/pipelines/240764976/test_report)
I have now added support for mounting the workspaces automatically (#572).
test_junit: script: .industrial_ci/gitlab.sh variables: ROS_DISTRO: noetic BASEDIR: ${CI_PROJECT_DIR}/.build artifacts: when: always reports: junit: ${BASEDIR}/**/test_results/**/*.xml
(results: https://gitlab.com/ipa-mdl/industrial_ci/-/pipelines/240764976/test_report)
Very nice! Looking forward to see this in master
.
Currently your changes are available on GitLab only. Is that intended?
(P.S.: I find .build
as name for the base directory rather distracting since it does not refer to a single build space.)
Currently your changes are available on GitLab only. Is that intended?
BASEDIR
will be available everywhere..
Other CI services might not have the same mount issue, though.
(P.S.: I find .build as name for the base directory rather distracting since it does not refer to a single build space.)
".build" is meant in the sense of CI build Any better idea? ;)
(P.S.: I find .build as name for the base directory rather distracting since it does not refer to a single build space.)
".build" is meant in the sense of CI build Any better idea? ;)
workspaces
, so the paths would be $HOME/workspaces/target_ws/
, $HOME/workspaces/upstream_ws
and so on.
@stertingen: It turned out that I forgot to push it to Github ;)
The feature is now contained in #572 and is using BASEDIR: ${CI_PROJECT_DIR}/.workspaces
.
BASEDIR
support is now merged, I will keep this issue open, because it still needs to be documented.
BASEDIR: ${CI_PROJECT_DIR}/...
does not work when the target workspace is in the repository, because then the CI script tries to copy the ${CI_PROJECT_DIR}
into ${BASEDIR}/target_ws/src
, i.e. into itself. Unfortunately, artifacts have to be stored inside of ${CI_PROJECT_DIR}
, so setting BASEDIR
to something like /basedir
does also not work.
BASEDIR: ${CI_PROJECT_DIR}/... does not work when the target workspace is in the repository
I did not consider this in the first place.. Please test #595
BASEDIR: ${CI_PROJECT_DIR}/... does not work when the target workspace is in the repository
I did not consider this in the first place.. Please test #595
Works like a charm, thank you!
I don't know if you read this in the other issue: Setting BASEDIR
currently only works for ISOLATION=docker
, unfortunately not for ISOLATION=shell
. It's the same issue: The CI script tries to copy a directory into itself.
I don't know if you read this in the other issue
I read it, but I interpreted "relevant" differently ;) I will try to come up with a solution (test case: https://gitlab.com/ipa-mdl/industrial_ci/-/jobs/1037122328).
GitLab has a feature to collect JUnit XML test results and display them in the Pipeline UI: https://docs.gitlab.com/ee/ci/unit_test_reports.html
Currently, this is not directly supported/documented by the CI, but the following
.gitlab-ci.yml
does the job:It places the build space for the target workspaces in the outer docker container and mounts it into the inner container. The extra mount seems a little bit hacky to me, but it works fine.
I thought that others might profit from this, so this could be added to the README or the example config.