Hello Marco, Your idea is very much in line how I was imaging it. I will try to come up with a prototype around this idea then we can continue the discussion about specifics.
Best, Istvan On Thu, Jan 3, 2019 at 11:43 AM Marco de Abreu <marco.g.ab...@gmail.com> wrote: > Hello István, > > thanks for your interest and for offering your assistance! This is > definitely a great idea and I think it has been mentioned a few times, but > nobody jumped on it yet. We would be very happy to assist you on these > efforts. > > As far as I can tell, it would boil down to having some kind of custom > groovy function that we could call within our Jenkinsfile pipelines. This > function would then determine whether that specific job/node should run or > not. This could have two granularity levels: > 1. Run or skip whole Jenkins job > 2. Run or skip Jenkins node > > To clarify the terminology: Each entry (e.g. windows-cpu) at [1] (sourced > from [2]) is a Jenkins job. Each Jenkins job can contain multiple stages > (irrelevant here) and each stage contains one or more nodes. One green > circle here [3] (e.g. Python 3: CPU Win) represents a node. > > #1 would be your example use case. In case of a doc change, we would skip > our unit test pipelines while the website pipeline would still be executed. > #2 would be language specific changes, for example. Imagine a change to the > Scala code. This would require all Scala and Clojure jobs to re-run, but > there would be no need to run R, Julia or Python, for example. > > One thought how to do this would be to define a mapping that would contain > the "watched" directories for a particular Jenkins job or node. Before a > job or node is triggered, it could then evaluate the previously mentioned > function to determine whether any file within that mapping has changed. > > If you have any further questions or would like to discuss a design > proposal, please don't hesitate to reach out to us again :) > > Best regards, > Marco > > [1]: http://jenkins.mxnet-ci.amazon-ml.com/job/mxnet-validation/ > [2]: https://github.com/apache/incubator-mxnet/tree/master/ci/jenkins > [3]: > > http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Fwindows-cpu/detail/master/150/ > > On Thu, Jan 3, 2019 at 7:22 PM István Fehérvári <goo...@gmail.com> wrote: > > > Hello developers, > > > > I recently opened a PR about a very small documentation change ( > > https://github.com/apache/incubator-mxnet/pull/13766) and I see it > > triggered the whole CI pipeline which is as far as I know very expensive > > and obviously unnecessary. > > > > Are there any efforts to script this behavior in a way to avoid > triggering > > CI when there is no code change in the PR? I am happy to help if there is > > interest. > > > > Best, > > Istvan > > >
