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.