Prevent unnecessary double-builds

[phako]

Sine the merge modifies the source repository, but Jenkins does not recognize it has already built that change, it will trigger another build for the component directly afterwards.

Either Jenkins should somehow know that it does not have to rebuild or if the job merged it should stop after that.

[mhier]

But how should it end? With success or failure? In case of a success, the dependencies will be triggered. A failure will confuse us.

[mhier]

Maybe merging the project template should be moved to a separate job which does this for all projects and gets triggered when the project template is changed.

[phako]

But how should it end? With success or failure? In case of a success, the dependencies will be triggered. A failure will confuse us.

Hm true. Maybe we could cancel the job then, but I agree, we would need some method to mark the reason properly and clearly visible

[killenb]

If it fails the message could be:
"Project template merged. Stopping the job because the source code has changed. It will be re-scheduled automatically."

[killenb]

If the run after that is green I see no problem.

[mhier]

I don't know. There are so many other reasons which indicate actual problems why this happens. Those issues will be completely hidden.

Moving the merging into a separate job also would allows us to use a squash merge (which helps a lot when making releases of "quite" projects after a long time). The only problem to solve is where to get a reliably list of projects.

Suggestion: We make a separate job which has a manually updated list of projects to run on. To avoid new projects not being added to the list staying unnoticed, we change the current mechanism to merge the project template inside the project job into a mere check whether the latest project template commit is already in. If not, it raises a warning. This will raise our attention eventually.

[killenb]

Moving the merging into a separate job also would allows us to use a squash merge (which helps a lot when making releases of "quite" projects after a long time). The only problem to solve is where to get a reliably list of projects.

No squash merge! It failed once on us badly and we manually had to recover many projects. We were lucky that Jenkins was in a bad shape and many projects were not even triggered.

In addition: If you do a separate job which reacts on changes in the project template you don't gain much. OK, without squash you have a merge commit and the change commit, but with squash you lose the information what has changed in the project template.