How to handle project dependencies?

[Kenneth]

I'm trying to setup jenkins to monitor a solution with C++ and C# in multiple solutions, but in one repository.

(VS 2005 and .NET 2.0)

 

How should I configure jenkins to build and test it?

 

my suggested alternatives are:

a) one job for each solution? - rather large jobs

b) one job for each project? - many jobs. How do I handle the project interdependencies?

 

I've been looking at this for quite a while...

I prefer b, but have been stuck on msbuild v.2.n and cannot figure out how to handle references between projects..

(There must be someone outthere that know how to build 2 c# projects with jenkins, one that uses the other)

 

thanks.

[Larry Shatzer, Jr.]

I use one job per project, and use NuGet (http://nuget.org/) to store artifacts and depend on them. There is no auto dependency feature for triggering dependency jobs. I've manually set them up.

[Todd Greer]

Kenneth wrote:

> I'm trying to setup jenkins to monitor a solution with C++ and C# in multiple solutions, but in one repository.
> (VS 2005 and .NET 2.0)
>  
> How should I configure jenkins to build and test it?
>  
> my suggested alternatives are:
> a) one job for each solution? - rather large jobs
> b) one job for each project? - many jobs. How do I handle the project interdependencies?

[snip]

We use one job per solution, and it's working fine for us. It does mean we can't treat the components as independent entities, but that isn't currently an issue for us. Were I in your shoes, I'd ask myself what the benefit of going to a job per project would be, and whether it would be worth it.

If I were to decide to go with a job per project, I'd probably have one job to check out the source*, and one job per project, with those jobs ordered by hand using post-build job triggers and the join plugin. They'd all have to use the same working directory.

* In my case, the first job would also run cmake to generate the project files, but it doesn't sound like that applies to you.

--
Todd Greer
Director of Development, Affinegy, Inc.

[Kenneth]

It sounds good, but appearntly NuGet doesn't support Visual Studio 2005. ;-(

[Larry Shatzer, Jr.]

http://stackoverflow.com/questions/7555883/using-nuget-with-visual-studio-2005 looks like someone got it to work, kinda.

Before I had NuGet implemented, I use the artifact copy plugin to copy the dll's to the right directories for it to compile. (bin/Debug or something like that).

[Deeps]

I'm a beginner so just putting my opinion out there. You could use a single job if all the code repository is the same. This way you won't have to move artifacts around much.

OR

Whichever projects are directly interdependent (those that require the other's binarys) - combine them in one job, keep the rest in separate jobs and use something like buildresulttrigger plugin or x-trigger plugin to set appropriate dependencies.

[SimonS]

I'm also new here - but possibly facing similar problems (C#). I'm not sure how exactly you expect the dependencies to be "handled", but I thought I would post my opinion.

I am going for your option B "one job for each project?"

My current plan is to add "build other project" "post build tasks" to jobs that are depended upon. If I understand correctly, by doing this I can "Block build when upstream project is building", and "Block build when downstream project is building". Since I want immediate feedback, regardless of what is happening elsewhere, I'm NOT going to use these. Maybe you want to...

I will also use the Copy artifacts plugin for projects that have dependencies to use the last successfull build from the upstream project.

Below is a sample setup with some possible problems.

Job A (triggered by a code checkin to repo somerepo/A,with with post build task to to run Job B)
Job B (triggered by a code checkin to repo someotherrepo/B AND has a dependency on Job A)

Problem 1
Scenario A
Two different developers check in changes simultanuously to the two different repo's.
Since the changes do not depend on one another, both jobs should be allowed to run simultanuously (job B can use the last successful build of job A's artefacts). When Job A is done, the post build task will run Job B a second time.

Scenario B
A single developer checks in changes to both repos at the same time - the changes depend on each other.
The jobs will be run as described in Scenario A - which causes Job B to fail. The second run of Job B should fix this.

I think scenario B will not happen often - and I can accept a failed build in this case.

Is this the type of "handling" you are asking about?

[SimonS]

Another problem caused by not using the "Block build when upstream project is building" or "Block build when downstream project is building" in my post setup is that Job A and Job B could end up running on the same slave. This would be problematic (for me at least) since the artefacts of Job A would replace the dependency of Job B.

To get around this I have to ensure that a slave can only run one job at a time. I think this is the number of executors of a slave.

I don't think this is a big problem, slaves are pret

[SimonS]

*pretty cheap

[SimonS]

I also think using the fingerprint plugin (https://wiki.jenkins-ci.org/display/JENKINS/Fingerprint) will be very useful to track dependencies - i.e. this build failed because these dependencies are not compatible...