On Fri, Mar 10, 2017, at 03:31 AM, Marek Skalický wrote:
Brian Stinson píše v Čt 09. 03. 2017 v 07:24 -0600:
- One job that normally do CI for every PR (job scripts are tested and
works good - so the results should be visible for users)
- And I would like to have a second job for the same repository, where
I want to "test" new versions of job scripts (that should do the same, but do it in new, for example more efficient, way). And I would like to test them first without showing possible wrong results to user (I will check results directly in Jenkins).
This is a problem that we solved with https://github.com/jlebon/redhat-ci which does it in the same way Travis does: your job definition lives in the git repository, and when you do a pull request, the job definition from the pull request is used.
This lets you test changes naturally.
See for example:
https://github.com/ostreedev/ostree/pull/630
There's some open discussion about having this project be an optional frontend "happy path" for Github PR testing using CentOS CI as a backend.