Manage lib dependencies as compilation or link time dependencies?

[Matt Klein]

Hi folks,

Newbie here looking to use jenkins to manage our build process. I'm attempting to follow jenkins best practices. One specific thing I'm wondering is how to set up my build dependencies or pipeline. We have a layered architecture which consists of many libraries (around 20) and a couple of executables. So we have layers of compilation dependencies but really at link time i just have two stages, libraries and binaries. My question is should my jenkins job dependencies reflect the compile time dependencies or just the link time dependencies?

The source is a mix of c and c++.

Thanks

[Ginga, Dick]

Matt, compile and link time "dependencies" are typically in your make file, visual studio, eclipse, other IDEs. So the first steps in your build will be to run these. You don't need multiple jobs. For a simple approach you would just create a free-style project that 1. Pulls the sources from your SCM, 2. Execute whatever steps are needed to compile and link your software, 3. Archive the binaries for distribution

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/c3990d21-02a1-4ca9-a602-d844b45a2074%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Simon Richter]

Hi,

> Newbie here looking to use jenkins to manage our build process. I'm attempting to follow jenkins best practices. One specific thing I'm wondering is how to set up my build dependencies or pipeline. We have a layered architecture which consists of many libraries (around 20) and a couple of executables. So we have layers of compilation dependencies but really at link time i just have two stages, libraries and binaries. My question is should my jenkins job dependencies reflect the compile time dependencies or just the link time dependencies?

> The source is a mix of c and c++.

Typically I don't declare any job dependencies there. Each project can
be built and tested on its own, and the projects using the libraries
would use the results from the last successful build, so you still get
the maximum coverage if a library breaks.

Simon

[John Mellor]

Matt asked:

> My question is should my jenkins job dependencies reflect the compile time dependencies or just the link time dependencies?

Simon responded:

> Typically I don't declare any job dependencies there. Each project can be built and tested on its own, and the projects using the libraries would use the results from the last successful build, so you still get the maximum coverage if a library breaks.

I strongly disagree. Always specify the compile-time dependencies. I assume that you are not just cherry-picking product versions that happen to mostly work, and actually need the work that is current to be the UUT. The library that you just built should be the one you test with, not some old version. Testing old libraries that are not going to be shipped may occasionally get you nice coverage numbers, but so what? It not representative of the work just done.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5648AF4E.3090605%40hogyros.de.

For more options, visit https://groups.google.com/d/optout.

--pSBoGibPG6WvFkClxNaj9nmcMx1NIsfbc
Content-Type: application/pgp-signature; name=ignature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=ignature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWSK9OAAoJEH69OHuwmQgROlMIAIzG2Dlg9xUQOjBhNf4Xp7jK
YxceKTOzNwEsGWHQa5S+8SbTzijwZtfk0KGRFfJJy3ifo4pnMmUT+HWPSPfiYMGo
D5z82XqujavpisqCwukMF/vSfFHricEK6jdGrq3joIH7oBtLRd3w+I81LVeQad8p
YTcSl9EcugnSB3GbLfXAq5khDhGFxpzoSL6FAv6WonxWd27GrGSr3gvpKIrZIAgJ
+HWzzzi6R3b2+Qeh54E9Qe8o8o/DMWBjhYUpCc1sfelCcOM0E1g53M1+aZ3mKxNI
waYCU4M6DviewH8Y+lO15YBRcJ5VmBUpTD8bEF+phy6oPqEK0Ehb2FyCkvMDtTU=cT
-----END PGP SIGNATURE-----

--pSBoGibPG6WvFkClxNaj9nmcMx1NIsfbc--

[Simon Richter]

Hi,

Am 17.11.2015 um 15:14 schrieb John Mellor:

>> Typically I don't declare any job dependencies there. Each project can be built and tested on its own, and the projects using the libraries would use the results from the last successful build, so you still get the maximum coverage if a library breaks.

> I strongly disagree. Always specify the compile-time dependencies. I assume that you are not just cherry-picking product versions that happen to mostly work, and actually need the work that is current to be the UUT. The library that you just built should be the one you test with, not some old version. Testing old libraries that are not going to be shipped may occasionally get you nice coverage numbers, but so what? It not representative of the work just done.

My point is that if a library fails to compile, that should not stop the
dependent projects from getting any work done, and it should not show up
as build failures for them.

Jenkins keeps track of dependent libraries pulled in as artifacts, so
simply triggering a rebuild of dependent projects after a library
changed is a good way to get the latest version of the library fully
tested (and failures show up with an empty project changelog and a note
that it was an artifact change that led to the failure).

However a "build library projects first" dependency is too strong.

Simon