My project is large, encompassing many sub projects on git.
I have a Jenkins job running when there is a merge request in the project.
However, whenever there is a change, it builds the whole project, which is a waste of time. I separated many sub jobs for each sub project. The question is, how could I only run the specific sub job based on the change addressed in that sub project from each merge request instead of running the whole build every time?
Thanks guys!
Related
I have a "SOA" styled application, with a single solution containing almost 100 individual projects (which are a solution within them, i.e. they can be run independently). I have created a build and release definition in TFS 2018 and everything works perfectly.
The issue is if I make changes to a single service (out of 100), and check-in my code, the build definition is triggered which builds the entire application and then the release definition deploys the entire thing(100+) each time.
I don't want it. I need it to be specific to the service in which changes are made. Is there any way to do it?
Creating multiple build/release definition which is tied to the specific path of each service should solve it but I don't want to go down that road, because I will end up creating 100's of definitions.
Is there any other way to do it?
This is for a .Net application, hosted in TFS 2018 (On-premise).
The solution structure is as below:
AllWCFService.sln
|_Service1.csproj
|_Service2.csproj
|..
|..
|_Service100.csproj
Each Service can also be run and hosted independently.
This is my first question here. I apologize for any confusion.
As you have mentioned, by using Path filters on the Build definition should be the easiest solution.
With the proper path to the project in the Path filter only the proper Builds spin up, and any projects untouched do not trigger a build. Each build has it's own release which then deploys the specified app to it's own destination. As a ugly workaround, you could set up a group each with 5 services which will reduce 100's of definitions to 20's.
Otherwise, you have to customize your build definition/pipeline. Use some scripts to determine or judge which part of your Servicex.csproj changed base on your name.
Then call msbuild with /t option to build a single or multiple projects.
msbuild test.sln /t:project;project2 /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false
specify project file of a solution using msbuild
It will only build specified changed project and generated corresponding artifacts. Then add scripts in release to specify path according build generated artifacts to deploy each service.
Hope this helps.
In our previous Jenkins setup we used a combination of the Build Monitor Plugin and the View Job Filters Plugin to create a screen showing our last 18 builds.
With our new setup we decided to break the builds into multiple folders, some of which are just simple folders, one is a dynamic folder pointing to Bitbucket. We would now like to re-create the same kind of view: show the 18 most recent builds across all of our builds.
If I just select the top folders in the configuration of the build monitor view, then no builds appear - no matter if I set the "Recurse in subfolders" option or not. I need to manually select individual jobs, which is not something we want to maintain in the long run.
If I use a regular expression match, then it includes jobs from other folders that are not selected.
There is also nothing I can find in the "Add Job Filter" menu that seems to allow me to filter jobs to come from within a selection of folders.
I can create multiple build monitor views, one for each folder - but that doesn't give me the last 18 builds over all.
Is there a way to create a build monitor with a number of most recent builds across multiple folders?
I figured out that you can use a regular expression to include jobs, assuming that all the jobs are contained in a single subfolder, my-jobs, you can do:
my-jobs/.*
to include only jobs within those folders.
Further, you can restrict this more by adding job filter matches which let you exclude other jobs if it starts including more jobs than you wanted.
For me on the latest version of Jenkins at time of writing (2.240), for the view to pick up jobs in subfolders, I had to tick Recurse in subfolders else the regular expressions would not match any jobs in folders.
Combined with Use a regular expression to include jobs into the view and a regular expression such as the one below, I was able to get the view to show jobs within a folder:
/MyFolder/.*
I suspect that if you wanted to include jobs from multiple folders, you could do so with a regular expression such as:
(/MyFolder/.*)|(OtherFolder/.*)
I have a primary Jenkins multijob project that works beautifully to build a test environment. It contains nicely-organized multiphase steps that do a variety of things.
In order to make changes to this without impacting ongoing tests, I created a copy of the primary Jenkins project that is treated as a Dev copy.
However, I have no idea how to merge the changes from the Dev build down to my Main build.
Specifically, there are a few parts that have changed between the two MultiJob projects:
Parameters - I've added a number of parameters to the overall MultiJob project.
New multiphase jobs - I created a couple new multiphase jobs, these should transfer easy enough.
Is there any way to merge these changes that will save me from having to just reconstruct the parameters and such?
I can think of 2 possible ways:
You can rename the old job to a new name and then rename the new one to the old name, so you'll actually replace the old one with the new one.
Merge the config.xml files of those 2 jobs.
I have two projects in Jenkins that are not linked to each other in any way (database build, and application build/test build). The two may never build at the same time in Jenkins, because tests access the database and it may not be building while tests run on the other build. Is it possible to make sure that the two projects never build at the same time? Apparently it is possible to do this for child/parent builds, but these two have no formal relation to each other. Thanks.
I would recommend using the Throttle Concurrent Builds plugin. If you use that plugin, then create a category and assign both jobs that category, you can be assured that the two jobs will never build at the same time.
I have a build area (BuildArea) checked in, which contains shared scripts and wrappers and whatnot that I use to build a project.
This is rarely updated.
Separately, I have various projects (Proj1, Proj2, Proj3...) under development which update regularly.
Standard flow is to checkout the latest source files from a project (e.g. Proj1), and then build the project in my build area (BuildArea).
The next day there's an update to Proj1 and also a Proj2, which I also want to build in my build area.
All these builds only read the files in BuildArea; no modifications are made except to create a unique results directory.
So, my questions are:
1. Can I create a Jenkins job that maintains a build area (BuildArea) and updates daily for example.
2. Can I then kick off independent Jenkins jobs that run within that build area and dump their results there?
The main reason I want to do this is that there are many projects run during the week and the build area is enormous, so checking out a local build area for each project is a big waste of resource.
Yes, this should be possible. Set your primary job with a custom workspace and have it store the files in a networked location, and then set up the scripts from your smaller jobs to access those files directly. We use clearcase and i had set up something similar with snapshot views. Your first job will just have the scm step, and your smaller jobs will only pull the files for your project.