Investigate skipping build if no changes

[akurtakov]

Today's build https://download.eclipse.org/eclipse/downloads/drops4/I20221119-1800/ contains no changes as per https://download.eclipse.org/eclipse/downloads/drops4/I20221119-1800/gitLog.php :

Git log from I20221119-0600 (previous) to I20221119-1800 (current)
The tagging, and this report, were done at about 20221119-1806

It would be nice to investigate whether such builds can be skipped with "No changes thus no I20221119-1800 build" mail sent.

[akurtakov]

@SDawley take a look and evaluate how much that would cost. If not too costy it's worth saving some effort.

[sravanlakkimsetti]

This is actually a very good idea. There are couple of places where we can deduce the changes

1. eclipse.platform.releng.aggregator/cje-production/mbscripts/mb110_tagBuildInputs.sh

   Line 52 in efe2e6c

   git commit -m "Build input for build $BUILD_ID"

   at this place if there is no new commit created that means there are no changes in any of the source repositories

2. eclipse.platform.releng.aggregator/cje-production/mbscripts/mb110_tagBuildInputs.sh

   Line 73 in efe2e6c

   if [[ -n "$lastTag" ]]; then

   this is the place we create gitLog. If we detect no changes we can exit from here.

[HannesWell]

This is actually a very good idea. There are couple of places where we can deduce the changes

That's right. But at the same time it should be considered if the previous build succeeded or not.
E.g. imagine a case where the infrastructure is flaky and an I-build failed for an external reason. If one then just restarts the build, it's not desired that exits early because no code changes happened in the meantime.

[laeubi]

Maybe one can just have one Job that check if something has changed once a day and then triggers the actual ibuild (and let the ibuild only be triggered manually or by this job)

[HannesWell]

Maybe one can just have one Job that check if something has changed once a day and then triggers the actual ibuild (and let the ibuild only be triggered manually or by this job)

Sounds good to me. In general this should be easily achievable using the pollSCM trigger:
https://www.jenkins.io/doc/book/pipeline/syntax/#triggers

But I fear that doesn't consider submodules, does it?

[HannesWell]

This is actually a very good idea. There are couple of places where we can deduce the changes

That's right. But at the same time it should be considered if the previous build succeeded or not. E.g. imagine a case where the infrastructure is flaky and an I-build failed for an external reason. If one then just restarts the build, it's not desired that exits early because no code changes happened in the meantime.

Actually the build could only be aborted on no changes, if the build was triggered by the cron-trigger, which can be checked for example as suggested in: https://stackoverflow.com/a/56151318
There is even a built-in triggeredBy condition for when{ }: https://www.jenkins.io/doc/book/pipeline/syntax/#when

With that combination I think everything should be as desired. I can have a look in implementing it accordingly.