-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[doc] Cleanup, update, elaborate #234
Conversation
👍 I will review it later! |
105ef1b
to
b8ad0e8
Compare
Updated (a lot). @ipa-mdl please review. |
doc/index.rst
Outdated
Note-1. This disables the handling of `ROS_REPOSITORY_PATH` and `ROS_DISTRO` as ROS needs already to be installed in the image. | ||
Some more notes: | ||
- Specifying Docker image disables the handling of `ROS_REPO` (and non-recommended `ROS_REPOSITORY_PATH`), and `ROS_DISTRO` as ROS needs to be installed in the image. | ||
- For some images, `ROS_DISTRO` variable still needs to be set. This holds for `ROS official Docker images <https://hub.docker.com/_/ros/>`_ as of Sept. 2017. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if these 2 lines hold true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a little bit tricky:
Specifying
DOCKER_IMAGE
disables the set-up of ROS based onROS_REPO
(or non-recommendedROS_REPOSITORY_PATH
), andROS_DISTRO
, butROS_DISTRO
still needs to be set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the the section above this note:
You can pull any
Docker
image by specifying inDOCKER_IMAGE
variable, as long as the following requirement is met:
- sources.list set up (
example <http://wiki.ros.org/kinetic/Installation/Ubuntu#Installation.2BAC8-Ubuntu.2BAC8-> Sources.Setup_your_sources.list>
_).python-catkin-tools
,python-pip
,python-rosdep
,python-wstool
,ros-$ROS_DISTRO_catkin
If the image does not contain these packages, they can get installed by including them inADDITIONAL_DEBS
, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall 👍, except for the ci_main.sh
issue, this script should never get called directly.
doc/index.rst
Outdated
|
||
:: | ||
|
||
before_config: | ||
- git clone https://github.com/ros-industrial/industrial_ci.git .ci_config | ||
script: | ||
- .ci_config/travis.sh | ||
- .ci_config/ci_main.sh (Travis CI with GitHub) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still .ci_config/travis.sh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is even the generic .ci_config/ci.sh
script that can be used with other CI systems or custom solutions like Jenkins.
doc/index.rst
Outdated
@@ -11,7 +11,7 @@ Introduction | |||
|
|||
This repository contains `CI (Continuous Integration) <https://en.wikipedia.org/wiki/Continuous_integration>`_ configuration that can be commonly used by the repositories in `ros-industrial <https://github.com/ros-industrial>`_ organization. Non ros-industrial repositories in other organizations can utilize the CI config here too, as long as they are ROS-powered. | |||
|
|||
As of December 2015, this repo provides configuration for `Travis CI`. The CI config in this repository is intended to be obtained by `git clone` feature. In client repos you can define custom, repository-specific checks, in addition to the generic configs stored in this repo. | |||
As of Novemeber 2017, this repo provides configuration for `Travis CI` and `Gitlab CI`. The CI configs in this repository are intended to be obtained by `git clone` feature. In client repos you can define custom, repository-specific checks, in addition to the generic configs stored in this repo. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Novemeber"
12a7bb0
to
b316cd0
Compare
All feedback addressed. @ipa-mdl please review again. I've squashed as much as I think reasonable but there are still a dozen. Personally I'd keep these as they are but do not mind squashing. |
f0dc22e
to
7c8dd44
Compare
doc/index.rst
Outdated
(Gitlab CI) Access to private repositories | ||
------------------------------------------ | ||
|
||
Every one who opens PRs/MRs (merge requests, that's what Gitlab calls pull requests) to repositories where CI jobs access private Gitlab repos are now required to add ssh private keys on their repos, including the forks (the following steps are cumbersome workaround, hopefully only temporary). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instructions should be addressed to any repo where CI jobs need to access private upstream packages. What about:
Repositories where CI jobs access private Gitlab repos are required to add ssh private keys on their CI settings. Matching public keys must be set as deploy keys on the private repos that need to be accessed.
Furthermore, the specific setup for a fork of some other repo should either use the same private key or be able to add the new public key to the upstream repos, shouldn't it? Not sure how/where to add this, maybe some note for setting up CI for forks at the end of the section?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Furthermore, the specific setup for a fork of some other repo should either use the same private key or be able to add the new public key to the upstream repos, shouldn't it? Not sure how/where to add this, maybe some note for setting up CI for forks at the end of the section?
That sounds even more advanced. Not sure if we need information for that in industrial_ci
's doc. In this PR, I've already gone far to walk through steps of how to add private and pub keys, which is not this package-specific and may be too much. You think that should be included here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. I just mention it because you were mentioning PRs/MRs and forks in the original paragraph.
doc/index.rst
Outdated
#. Open your fork with your account filled in in the repo's URLs below (the rest of the steps need to be done for these URLs). `%YOUR_GITLAB_DOMAIN%` can be `gitlab.com` if you're using the hosted version of Gitlab. | ||
|
||
#. https://%YOUR_GITLAB_DOMAIN%/%YOUR_ACCOUNT%/%REPO_YOUR_BRANCH_RESIDES%/settings/ci_cd | ||
#. https://%YOUR_GITLAB_DOMAIN%/%YOUR_ACCOUNT%/%REPO_YOUR_BRANCH_RESIDES%_test/settings/ci_cd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the _test
repo?
# gitlab.com:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 | ||
gitlab.com ecdsa-sha2-nistp256 RandomKeySequenceRandomKeySequenceRandomKeySequenceRandomKeySequenceRandomKeySequenceRandomKeySequenceRandomKeySequence | ||
# gitlab.com:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing instructions on setting up the public key as deploy key.
Maybe also add here something about forks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing instructions on setting up the public key as deploy key.
Addressed in this line.
doc/index.rst
Outdated
|
||
2. In `CI config <#terminology>`_ file in your client repo, add in `before_config` section a sentence `git clone https://github.com/ros-industrial/industrial_ci.git .ci_config`, like below: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, there is no before_config
section
doc/index.rst
Outdated
:: | ||
|
||
before_config: | ||
- git clone https://github.com/ros-industrial/industrial_ci.git .ci_config | ||
script: | ||
- .ci_config/travis.sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is confusing. Don't mix non-travis scripts with travis(-like) config.
I would suggest to don't touch this section for now and to improve it in another PR.
I guess we should have an extended quickstart for all supported CI systems.
On CI platform usually some variables are available for the convenience. Since all checks using `industrial_ci` are NOT running directly on the operating system running on CI, but instead running on `Docker` where those variables are not defined, dozens of them are already passed for you (you can see `the list of those variables <https://github.com/ros-industrial/industrial_ci/blob/master/industrial_ci/src/docker.env>`_). | ||
|
||
Still, you may want to pass some other vars. `DOCKER_RUN_OPTS='-e MY_VARIABLE_VALUE'` should do the trick. | ||
You can even set it to a specific value: `DOCKER_RUN_OPTS='-e MY_VARIABLE_VALUE=42'` (format varies per CI platform. These are Gitlab CI example). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the Travis format.
The Gitlab format (proper YAML!) would be: DOCKER_RUN_OPTS: '-e MY_VARIABLE_VALUE'
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In 38db36e I added a disclaimer in the new supported CI system section that the format in this doc is by default for Travis CI.
doc/index.rst
Outdated
------------------------------------------ | ||
|
||
Every one who opens PRs/MRs (merge requests, that's what Gitlab calls pull requests) to repositories where CI jobs access private Gitlab repos are now required to add ssh private keys on their repos, including the forks (the following steps are cumbersome workaround, hopefully only temporary). | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is no (temporary) workaround, but the officially documented way.
doc/index.rst
Outdated
@@ -257,7 +309,7 @@ The jobs that run Prerelease Test may usually take longer than the tests defined | |||
- ROS_DISTRO=indigo PRERELEASE=true | |||
: | |||
|
|||
Then open a pull request using this branch against the branch that the change is subject to be merged. You do not want to actually merge this branch no matter what the Travis result is. This branch is solely for Prerelease Test purpose. | |||
Then open a pull request using this branch against the branch that the change is subject to be merged. You do not want to actually merge this branch no matter what the CI result is. This branch is solely for Prerelease Test purpose. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
double whitespace
doc/index.rst
Outdated
- .ci_config/travis.sh | ||
- .ci_config/ci.sh | ||
|
||
Multiple commands can be passed, as in a general `bash` manner. Using semi-colon as a delimitter,:: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not recommend semi-colons, these are error-prone in this context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's better if you want to pass multiple commands? &&
and/or ||
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the limited scope of BEFORE_SCRIPT
using &&
should be enough.
More complicated things should go into a script file.
doc/index.rst
Outdated
|
||
For more complicated cases the commands should go into a dedicated script:: | ||
|
||
- BEFORE_SCRIPT='./my_before_script.sh' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be the recommendation for multiple commands.
Thanks @ipa-mdl @miguelprada. Could you have a look again? Commits are separated for the sake of easier review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still find the instructions on setting up Gitlab CI for accessing private repos a bit confusing/misleading.
Find some suggestions in 85f6cec
doc/index.rst
Outdated
|
||
If your Docker image is missing any of the above libraries, then you can still pass their name by `ADDITIONAL_DEBS` (see `variables section <./index.rst#optional-environment-variables>`_). | ||
To open PRs/MRs (merge requests, that's what Gitlab calls pull requests) that access private Gitlab repos, additional setting is needed both on: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instructions should not be limited to opening PRs/MRs. Any repo using GitLab CI where industrial_ci
needs to access private repositories (anywhere), needs to setup authentication to do so.
doc/index.rst
Outdated
gitlab.com ecdsa-sha2-nistp256 RandomKeySequenceRandomKeySequenceRandomKeySequenceRandomKeySequenceRandomKeySequenceRandomKeySequenceRandomKeySequence | ||
# gitlab.com:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 | ||
|
||
#. (Optional) If you're an admin of the private repos, add a public key (`refrence <https://docs.gitlab.com/ce/ssh/README.html#deploy-keys>`_). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not optional. If the private repositories your CI jobs need to access don't have the matching public key as deploy key (or somehow grant access to the private key you set up in your repo), all of the above won't work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My previous comments have been addressed 👍 , but I took another look ;)
As a general remark: If "Travis config" refers to a specific Travis example (or feature), we should not change it to "CI config"
doc/index.rst
Outdated
@@ -11,14 +11,17 @@ Introduction | |||
|
|||
This repository contains `CI (Continuous Integration) <https://en.wikipedia.org/wiki/Continuous_integration>`_ configuration that can be commonly used by the repositories in `ros-industrial <https://github.com/ros-industrial>`_ organization. Non ros-industrial repositories in other organizations can utilize the CI config here too, as long as they are ROS-powered. | |||
|
|||
As of December 2015, this repo provides configuration for `Travis CI`. The CI config in this repository is intended to be obtained by `git clone` feature. In client repos you can define custom, repository-specific checks, in addition to the generic configs stored in this repo. | |||
As of November 2017, this repo provides configuration for `Travis CI` and `Gitlab CI`. The CI configs in this repository are intended to be obtained by `git clone` feature. In client repos you can define custom, repository-specific checks, in addition to the generic configs stored in this repo. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would subsitute "CI configs" with "CI scripts", the use here does not match the definition in the glossary.
doc/index.rst
Outdated
@@ -91,7 +108,7 @@ Prerequisite | |||
In order for your repository to get checked with configurations in `industrial_ci`, it needs: | |||
|
|||
* To be a `Catkin package <http://wiki.ros.org/ROS/Tutorials/catkin/CreatingPackage>`_ (uses CMake for build configuration), since many checks are triggered by the `Catkin`-based commands. | |||
* Build-able on Linux (as of Dec 2015, Ubuntu 14.04/Trusty is used). Although your repository is not necessarilly intended for Linux, checks are run on Linux. | |||
* Docker image for the targeted operating system is available on a Docker registry (e.g. http://hub.docker.com, Gitlab registry) either publicly or privately. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this might confuse users if they are not used to Docker.
It is a requirement, but there is no special action to take for the ROS-supported linux systems.
doc/index.rst
Outdated
@@ -101,18 +118,19 @@ Here are some operations in your client repositories. | |||
To start using CI config stored in this repo | |||
-------------------------------------------------- | |||
|
|||
With the following few short steps, you can start in your client repository using CI confiurations stored in here (`industrial_ci` repository). | |||
With the following few short steps, you can start in your client repository using CI configurations stored in here (`industrial_ci` repository). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
again, we don't use the configurations, but the scripts.
doc/index.rst
Outdated
:: | ||
|
||
before_config: | ||
install: | ||
- git clone https://github.com/ros-industrial/industrial_ci.git .ci_config |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: We should change this to .industrial_ci
in the future. (new template in #105)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: We should change this to .industrial_ci in the future. (new template in #105)
Why is that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it's no configuration at all ;)
doc/index.rst
Outdated
- git clone https://github.com/ros-industrial/industrial_ci.git .ci_config | ||
script: | ||
- .ci_config/travis.sh | ||
- .ci_config/travis.sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whitespace
I couldn't find your suggested change in that commit. If you could open a PR to my fork I'm happy to review that. |
It seems you changed some stuff and force pushed to your branch since I did that commit, so it no longer applies cleanly. I tried to replicate what I was suggesting in 130s#17. The main points of confusion for me are summarized in the PR comments. In any case, it's just my opinion, so feel free to ignore my suggestions altogether 😄 |
- Passing multiple {script/command}(s) are missing. - Link to detail missing. [doc] More sample for BEFORE/AFTER_SCRIPT. Not using double quote. [doc] Clarify the timing BEFORE_SCRIPT gets called.
…#236 (comment) [doc] More elaboration about specific Docker image passing.
…but undocumented)
[doc] Add a template for Travis CI 9to address ros-industrial#105)
[doc] Accordance with glossary https://github.com/ros-industrial/industrial_ci/pull/234/files#r160664100
@ipa-mdl @miguelprada All of your feedback should be addressed. Please review. This PR has sit here for half an year (my bad). I'd like to rather go ahead merge and tag a new ticket for additions if any. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the few comments below, looks good to me.
doc/index.rst
Outdated
|
||
* Note that `.ci_config` is the required name of the cloned folder; it is hardcoded so you need to use this name. | ||
* Note that `.industrial_ci` is the required name of the cloned folder; it is hardcoded so you need to use this name. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
README.rst
claims the opposite. Whichever is wrong should be corrected.
doc/index.rst
Outdated
* **CATKIN_PARALLEL_JOBS** (default: -p4): Maximum number of packages to be built in parallel that is passed to underlining build tool. As of Jan 2016, this is only enabled with `catkin_tools`. See for more detail about `number of build jobs <http://catkin-tools.readthedocs.org/en/latest/verbs/catkin_build.html#controlling-the-number-of-build-jobs>`_ and `documentation of catkin_tools <https://catkin-tools.readthedocs.org/en/latest/verbs/catkin_build.html#full-command-line-interface>`_ that this env variable is passed to internally in `catkin-tools`. | ||
* **CATKIN_PARALLEL_TEST_JOBS** (default: -p4): Maximum number of packages which could be examined in parallel during the test run. If not set it's filled by `ROS_PARALLEL_JOBS`. | ||
* **CCACHE_DIR** (default: not set): If set, `ccache <https://en.wikipedia.org/wiki/Ccache>`_ gets enabled for your build to speed up the subsequent builds in the same job if anything. See `detail. <https://github.com/ros-industrial/industrial_ci/blob/master/doc/index.rst#cache-build-artifacts-to-speed-up-the-subsequent-builds-if-any>`_ | ||
* **CI_PARENT_DIR** (default: .industrial_ci): (NOT recommended to specify) This is the folder name that is used in downstream repositories in order to point to this repo. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like this is no longer used. Shouldn't it be removed from the list?
doc/index.rst
Outdated
- https://docs.gitlab.com/ce/ssh/README.html | ||
- https://docs.gitlab.com/ee/ci/ssh_keys/README.html | ||
|
||
Pass custom variables to Docker |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplicated above (Gitlab CI) Access to private repositories section.
doc/index.rst
Outdated
|
||
NOTE: If you specify scripts in `script` section without using aforementioned variables, those will be run directly on CI, not on the `Docker` where `.ci_config/travis.sh` runs on.:: | ||
NOTE: In general the scripts are run as root in a Docker container. If you configures a different (base) Docker image, the user could be changed to non-root. But since we need to install packages the (base) image should set-up `sudo` for this user. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: ... If you configure a different (base)...
…(feedback ros-industrial#234 (comment)). [doc] Fix contradicting folder name practice (addressing ros-industrial#234 (comment))).
@miguelprada Thanks, could you give a (hopefully one last) look? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for not having caught this one before. The "Quick Start" instructions for Gitlab CI need a bit of tweaking. I suggested some rewording below.
README.rst
Outdated
|
||
- `industrial_core/.travis.yml <https://github.com/ros-industrial/industrial_core/blob/eeb6a470e05233d0efaaf8c32a9e4133cdcbb80b/.travis.yml>`_: Indigo and Jade compatible. | ||
- `leap_motion/.travis.yml <https://github.com/ros-drivers/leap_motion/blob/954924befd2a6755f9d310f4a8b57aa526056a80/.travis.yml>`_: Indigo, Jade, Kinetic compatible. Also runs `ROS Prerelease Test <http://wiki.ros.org/bloom/Tutorials/PrereleaseTest>`_. | ||
1. In `.gitlab-ci.yml` file in your client repo, add in "`install`" section a sentence `git clone https://github.com/ros-industrial/industrial_ci.git .industrial_ci`, like below: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You also need to enable CI for your repo by assigning a suitable runner to it, which can be done in Settings > CI/CD > Runners settings.
There is probably more than one way to set up the runner. The .gitlab-ci.yml
in this repo is set up to use a runner configured with the Docker executor (i.e. implicit by its use of image
and services
keywords). I do, however, think that step-by-step instructions on how to set this up are probably beyond the scope of this README.
Also, .gitlab-ci.yml
should use before_script
instead of install
for cloning industrial_ci
, and the following line should be a minimal job configuration.
I would propose something like:
- Enable a runner for your Gitlab project which uses the Docker executor. See instructions on how to install and register such a runner with your Gitlab instance if you haven't done so yet.
- In
.gitlab-ci.yml
file in your client repo, add the following minimal configuration, replacing indigo for your chosen distro:
image: docker:git
services:
- docker:dind
before_script:
- apk add --update bash coreutils tar
- git clone https://github.com/ros-industrial/industrial_ci .industrial_ci
indigo:
script: .industrial_ci/gitlab.sh ROS_DISTRO=indigo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I agree to just briefly mention the need for setting up Pipeline and rely on the external source for the detail. I've basically applied your suggestion in the updated commit, with a minor change to give a hint about unclarity of gitlab.com version and your-own-server version that I find not clear for the most of the times in the docs on Gitlab.
- `example 1 <https://github.com/ros-industrial/industrial_core/blob/eeb6a470e05233d0efaaf8c32a9e4133cdcbb80b/.travis.yml>`_ (Indigo and Jade compatible). | ||
- `example 2 <https://github.com/ros-drivers/leap_motion/blob/954924befd2a6755f9d310f4a8b57aa526056a80/.travis.yml>`_ (Indigo, Jade, Kinetic compatible. Also runs `ROS Prerelease Test <http://wiki.ros.org/bloom/Tutorials/PrereleaseTest>`_). | ||
- For development branch intended for ROS Kinetic: `industrial_core <https://github.com/ros-industrial/industrial_core/blob/a07f9089b0f6c8a931bab80b7fca959dd6bba05b/.travis.yml>`_ | ||
- For more complexed example: `.travis.yml <https://github.com/ros-industrial/industrial_ci/blob/d09b8dd40d7f1fa1ad5b62323a1d6b2ca836e558/.travis.yml>`_ from the same repo. You can see how options are used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Link to .gitlab-ci.yml
in industrial_ci
as well?
Great. Looks good to me now 👍 |
Thanks @miguelprada I'll dismiss "requested changes" and merge, as this sits unmerged for while as I said #234 (comment). For any new concern please feel free to open new tickets. |
It's stale, and see #234 (comment)
See message and diff in each commit.