automatic up/downstream relationship and fingerprinting

[Marco Sacchetto]

Hi, I'm trying to create a new set of pipeline builds for a number of modules.
The modules are built with gradle and have dependencies between themselves.

I'd like to leverage the fingerprinting feature in Jenkins to obtain upstream and

downstream relationship created automatically, but I'm not clear about how it

woud exactly work. My issue is with the fingerprint function not indicating to

Jenkins if an artifact is an actual dependency or a product the build.

For example, in a simple case:

Build 1 builds artifact A using two external dependencies X and Y.
So, build 1 fingerprints A, X and Y.

Build 2 builds artifact B using A, and it transitively dependends on X and Y.
I understand that by fingerprinting A, B, X and Y Jenkins will set this as a downstream

build of build 1.

Build 3 builds an artifact C totally unrelated to builds 1 and 2, but it still depends

on X and Y. But, since X and Y have been fingerprinted in builds 1 and 2, won't

Jenkins record this as a downstream job of both build 1 and 2? Or am I missing

something here? I expected there would be a way to tell to Jenkins that

artifacts X and Y have not been created by build 1 and 2, but the fingerprint

function doesn't seem to be accepting any option.

[Martin Jost]

I'm not using pipeline jobs, but the "normal" configuration. There I can tell Jenkins, what to fingerprint (paths and wildcards)

You need to be (very) careful what you fingerprint. If I understood that correctly, the algorithm used is

- fingerprint whatever the user asks CI t  fingerprint (MD5 checksum)

- Search through all fingerprints recorded for the up/downstream related jobs

- Note a link between all combinations, where any fingerprint matches

We once shot ourself in the foot, by having a "much helps much" approach and fingerprinted about every artifact - creating totally misleading links between runs.

Martin

[Marco Sacchetto]

So, do you mean that we should accurately select only the artifacts

that we create ourselves? That indeed makes sense. I still wonder

how the maven plugin works though since it does that automatically,

it can definitely fingerprint the build products by checking the pom

file, but I wonder about how it can distinguish between internal and

external dependencies. Personally with gradle I guess I could define

a function with a whitelist that checks in the gradle cache folder for

all the known artifacts we produce. But besides being bothersome

to create, it's also not particularly safe. Extra artifacts introduced

by developers would make the whole thing unreliable without giving

you any hint of that breakage.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/Q6xPM6Cszzo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/7dcbea10-ad71-4f7f-8e81-c0a6b2471a2d%40googlegroups.com.