Setup CI

[odeimaiz]

• Check merged w/o conflict (this is already in place by GitHub)
• CI is triggered (via travis)
• Use ctest to have a test scheduler (done as toplevel test-only cmake project)
• Check repo rules in demos folder (checking readme.md and Makefile's target right now ... extendable via Python file)
• Check Python file's PEP8 compatibility (done for Python files in ./tools)
• C++ test coverage test (concept proof in demos/cpp-ci)
• Building with a build-container and having a (possibly smaller) deploy container (demonstrated in demos/cpp-ci)
• C++ coding guidelines (check and implement clang-format tool)
• .js linter case (e.g., check and implement via clang-format tool)
• Merge is blocked when CI fails (not to spread test failures across forks)
• Adapt Makefile based demos
• Run tests (those registered in top-level ctest environment)
• triggered total/partially using a keyword in the review chat always triggered automatically via travis and a commit to the fork's feature branch
• nice to have: monitor build times (partial and total)?
• Add hint documents/comments when a coding guideline, linter, ... fails to have it fixed as automatic as possible

Original introduction text

The goal is to support reviews (in terms of quality & speed) of pull-requests. Therefore CI should NOT be a complete no-go as we had in pulse. Instead we should think of it as a way to evaluate (kind of a metric) and then a human can take a final informed decision. For that we would need to explore the possibility to

• triggered total/partially using a keyword in the review chat
• define a metric for each item
• set optional items when triggered a revision of a pull-request

[odeimaiz]

Add Lint to Continuous Integration

[oetiker]

I would suggest to set it up such that whenever creates a PR, ALL the test are run and merging is blocked until all tests succeed

[pcrespov]

Yep!