mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco de Abreu <>
Subject Re: Running CI for doc changes
Date Thu, 03 Jan 2019 19:42:31 GMT
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

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,


On Thu, Jan 3, 2019 at 7:22 PM István Fehérvári <> wrote:

> Hello developers,
> I recently opened a PR about a very small documentation change (
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message