Skip shared lib build / deploy if commits did not change

[clemensutschig]

During testing of the MRO lib - we figured out that the shared lib will rebuild the component even if neither the shared lib commit or the component commit changed.

This should be changed, if nothing changed, just return, and don't build

@metmajer fyi

[michaelsauter]

As I see it there are two options:

1. Compare with previous Jenkins build
2. Compare with latest image in OpenShift

(2) assumes that we are actually building an image in OpenShift, which me might not do ...

As a side note, this might also be helpful for scenarios where we have multiple pipelines within one repository. This is possible since a few weeks (by adding more webhooks to a repo, and adjusting the component name of each). In that case, we probably only want to build each pipeline if the folder in which the pipeline is has changed compared to the previous commit.

[michaelsauter]

@clemensutschig Regarding the target: I would take this off from 1.2.0, and put it into the next release ...

[michaelsauter]

I think this is related to #155.

I'm doubtful this will be make it into v2. @clemensutschig @metmajer Objections to move it to 3? Or do you have anyone that could work on this?

[michaelsauter]

Taking this out of ODS 2 ... let's consider again when we prioritise for ODS 3.

[clemensutschig]

OMG .. @metmajer - you gave me the enlighting thought ...

in the MRO we can check before calling MROPipelineUtil:executeODSComponent - if the image is available and deployed (commit sha/# link ods.build.source.repo.commit.sha) as current (based on the exported metadata/deployments json) - in case it is - the image contains (thanks ods) - the build id from jenkins (ods.build.jenkins.job.url) that deployed it - which would allow us to find the right docs on nexus - for TIR and DTR ... and voila, we would not even need to start the component pipeline ...

The tricky part is the export metadata commit from the finalize stage.. which is build commit +1 ... here i need to think more.. git log -2?

io.openshift.build.name=golang-28
io.openshift.build.namespace=odsst-dev
ods.build.jenkins.job.url=https://......../job/odsst-cd/job/odsst-cd-odsst-mro-pipeline-master/17/
ods.build.lib.version=feature/add_mono_repo_support
ods.build.source.repo.branch=master
ods.build.source.repo.commit.author=MRO System User (undefined)
ods.build.source.repo.commit.msg=ODS: Export OpenShift configuration [ci skip]
ods.build.source.repo.commit.sha=4f4d10256e13951132c415579b328f185ed14219

And we only do all this on the currently deployed version.. so no (rocket-) science... this will improve mro performance hugely..

@michaelsauter thoughts?

[michaelsauter]

Makes we wonder ... if you "build the same commit again" - aren't we actually building a new SHA? Say we run the orchestration pipeline for the first time, we build SHA abc, then there's an image which points to commit abc. However, in the finalize stage, we create a new commit, def. Next time we run the orchestration pipeline, Jenkins will look at def, so the SHA is not the same as the one recorded in the image ... right?

Maybe we should link the commit that is created in the finalize stage to the build commit ... basically: if the orchestration pipeline finds HEAD to be a commit that the orchestration pipeline itself created in a previous pipeline, then one can check the commit that was built originally.

[clemensutschig]

I have a first prototype running.. which takes the latest committed deployments.json as master state and applies all sorts of checks.. the next piece is the docs.. here i need to play with an approach - currently my idea is to get the docs /namely single DTR/ TIR and SCRR from nexus

[clemensutschig]

ok - this will ONLY work for Dev .. w/o changing @michaelsauter 's implementation too much - we only commt the state of dev - so I don't have any place to store a Q build identifier ... which imho is not a big deal, because on dev - you want to try over and over again