Build from jenkins with multiple repos

Question

0.00/5 (No votes)

See more:

Hi all,
I have a large set of POCO classes which are used by multiple projects and I would like to place them into a seperate project and just reference the assembly from the other projects.

This is normally straightforward. The problem I have is, I automate my builds using Jenkins. Currently for all my projects I include all the classes code in every project which is obviously not ideal. What I would like to do is, get Jenkins to pull the common class code ( which would be in it's own repo ) and include it in all the builds
I currently use a Jenkinsfile for all the builds which works very well but I have to remember to change the multiple versions of the classes. I hope this makes sense.

This is all using net core

What I have tried:

Adding git clones to my pipelines to try and pull in the POCO classes

Posted 18-May-20 7:55am

pkfox

Updated 19-May-20 3:28am

Add a Solution

Comments

Sander Rossel 18-May-20 15:45pm

Sounds like you could use a private NuGet repository with your own package that contains the POCO classes and reference that in all projects?
You wouldn't have to change your Jenkins builds because it's just another package in NuGet.
Is that a possibility?

pkfox 18-May-20 17:16pm

How could I do that Sander ?

Sander Rossel 19-May-20 6:42am

Hi pk, didn't see your comment because you replied to yourself instead of me :)
Anyway, I'm not sure how to set up a private NuGet feed on your own server, but I know you can host NuGet packages in Azure DevOps (https://docs.microsoft.com/en-us/azure/devops/artifacts/get-started-nuget?view=azure-devops).

Another option, by the way, one that I've used in the past, is to always check out two repositories in the same folders.
So let's say you have a folder myprojects.
Inside that folder you have your repositories.
projectA, projectB, projectC and sharedProject.
A, B and C reference sharedProject at /../../sharedProject/sharedProject.csproj (or something like that).
Of course A, B and C won't build unless shared is at that exact location.
However, if you check them out like that in Jenkins, which should be possible, it will build and updating sharedProject could trigger the builds of A, B and C.
Whether you'd want that is up to you.

pkfox 19-May-20 8:12am

Hi Sander,I'm such a fool ( replying to myself ) what you suggest is roughly what I had in mind. In my current state I'm just trying to get a successful build with two projects let's call them EntityConsumer and Entities, if I read you correctly you are saying build Entities and then trigger a build of EntityConsumer which has a dependency on Entities ? ( what could possibly go wrong :-) ? ) I'll give it a go - thanks very much for your help and patience

Sander Rossel 19-May-20 8:51am

Yeah, it's been a while since I did that and I don't have Jenkins right now, but this should give you an idea on how to do that: https://stackoverflow.com/a/40225216
At least I know it's possible.

One other consideration.
I've worked with such setups like you describe, one model to rule them all.
Also named a canonical data model.
I'm not a fan of them myself.
It basically tightly couples all your services to each other.
I'm a fan of each service having its own model.
It gives you complete control over each service and it's hardly extra work since you have to change every service every time anyway.
Maybe you need it, maybe you don't, but it's too much work to change it now, but ask yourself if you really need it and if you have any alternatives.

pkfox 19-May-20 12:01pm

Success !!! albeit in a not pretty fashion - I created a new Jenkins pipeline item which pulls the two repos in ( you can't do what you sugested into the same folder as it gets overwritten by the second ) then build the common repo first followed by the second ( here comes the orrible bit ) the caveat is I had to put

/home/pjk/Jenkins/Linux-ARM64/Common/Common.dll

in the Consumer.csproj file in github as a ItemGroup Reference - I perform a dotnet build in the script which outputs Common.dll to this folder - it's a start though - thoughts ?

Sander Rossel 19-May-20 13:24pm

Well, if it looks stupid and it works then it ain't stupid :D

BillWoodruff 19-May-20 2:08am

PKFox: I know you are a very bright guy, isn't this a question Jenkins community forums can provide help with ? https://www.jenkins.io/chat/

pkfox 19-May-20 5:08am

Hi Bill, thanks for the compliment - most of the jenkins link I've found are IRC rooms - not keen on them

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Pete O'Hanlon · Answer 1 · 2020-05-19T03:29:00

Solution 1

The way that I have accomplished this in the past is to use a private NuGet server (or a source such as Artifactory). If you want to use a private NuGet server, you could host your own using GitHub - NuGet/NuGetGallery: NuGet Gallery is a package repository that powers https://www.nuget.org[^] or, even better, Baget[^]. Whichever solution you choose (and there are other private NuGet offerings), you would separate these other classes into their own NuGet entries, which would be built separately by different Jenkins jobs.

Now, when you build, set your Jenkins NuGet repositories to be both nuget.org (for the general purpose NuGet packages) and your local NuGet server to pick up your local files.

Posted 19-May-20 3:29am

Pete O'Hanlon

Comments

pkfox 19-May-20 11:53am

That's food for thought Pete thanks - I've used Jenkins to build and publish nuget packages before ( that was on Windows though ) my current need is net core on Linux ARM64

Pete O'Hanlon 20-May-20 3:02am

This works equally well on Linux solutions (I do this myself). When you publish, just set Linux ARM64 as your target.

pkfox 21-May-20 17:28pm

Hi Pete have you setup a nuget repository on Linux ?

Pete O'Hanlon 21-May-20 17:36pm

I have indeed. It's pretty straightforward.

pkfox 24-May-20 10:37am

Hi Pete, just a heads up - on your recommendation I installed BaGet on a Linux box and it works beautifully , it was the last part of the jigsaw to my automating my deployment process - one thing I had to do to get it building with Jenkins was to create a nuget.config file and add the url of the BaGet server and I was away. Thanks very much for your advice.

Pete O'Hanlon 24-May-20 16:45pm

Nice.