I have been using Jenkins for a couple of months now, and have been able to set up a simple CI system.
I currently have a build tab - that will build and deploy 25 different components successfully, based on building from an SVN trunk.
I'm now taking my first branch - some people will develop on the trunk and some will develop fixes on the branch.
I would now like to have CI up and running for both branch and trunk - so would create a second tab - with a repeat of the jobs from the first tab, but this time changing the SVN path to check out from the branch.
As I have rather a lot of jobs and the task is quite repetitive, is there an easy way to do this ? I'm hoping that each job tab might be a single xml that I can edit / rename to give me a second tab ?
Yes, each job is as single xml file, located under $JENKINS_HOME/jobs/$JOB_NAME/config.xml. However there are a number of places in the config.xml that reference it's location, so simply copy-pasting the actual file isn't the best option.
Jenkins UI itself has "copy job" function.
Click "New Item" where you want it
Select "Copy existing Item"
Specify the name of existing item to copy
Specify the name for the new job
Then go to configure the new job and change what you need.
Another tip: may not apply to your setup, but more often than not, there is a "unifying difference" between multiple similar jobs, most often a branch name, or project name, or similar. The value would be that only one that needs to change between otherwise identical jobs, however that changed value may appear several times within the job configuration.
I usually make a "choice" parameter, with a single choice, and put that different value there. The rest of the job references the choice param as a variable. So when I copy identical jobs, I just need to change that 1 value at the top of job configuration page. Everything else falls into place.
Related
I have a job to maven build our project, we now have one job per release version. As the number of releases grows, there are too many jobs and very hard to find the one we need.
I wonder if there is a way to launch the same job with different parameters? The problem is one job only has one workspace, so I'm not sure if it's possible?
Thanks.
Use This build is Parameterized option to build the jobs. Using this you can build the same job for different parameters. You will be asked to enter the parameter before building or you can also give a default parameter and you can have multiple parameters.
It is good the archive the artifacts which you need later.
You can also have the option keep build forever, this will keep the builds permanently Ir-respective of the number of builds to keep.
To use above option you should enable Discard old build option.
You can also link your repository directly to Jenkins which will trigger the job whenever a new commit is made to master or a new tag is created.
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 number of multi-config jobs and all have to run on the same machines, one after another.
For example:
Build on all platforms.
Do some automated testing.
Do some automated benchmarking.
These are all happening on the same machines, in that order, but they are different jobs.
The problem is that if I want to add another platform or remove one of them, I will have to do it for every single multi-config job. What I would like is to have a way of defining those platforms in one place and then have the jobs point to that template and run.
I am quite sure I'm not the first one to hit this problem and that there should be some plugin out there, but I haven't been able to find it.
So, is there any simple way of doing this?
We create temaplte jobs in jenkins which helps us to create all the set of jobs reqired for a platform, we just pass the platform / component name as input pareamter for the template job. We us the job copy plugin https://wiki.jenkins-ci.org/display/JENKINS/Jobcopy+Builder+plugin
But for a deleting the jobs we have another job where again the component name is the input parameter and we use something similar to the answer given here Is it possible to delete a hudson job programmatically via REST API?
My team uses a per-release and per-sprint branching approach. So we typically have a fresh branch off of Main (integration) for the current sprint and a branch off of Main for each release.
Main Branch
|
-- Development Folder
| |
| -- Sprint 2.10_1 Branch
| -- Sprint 2.10_2 Branch *current*
|
-- Release Folder
| |
| -- Release 2.8.0 Branch
| -- Release 2.9.0 Branch *current*
There are two build definitions. One points at the current dev branch and the other points at the current release branch.
This setup is working well, except that it has become a bit time-consuming and error-prone to update all the branch paths in the builds every time we branch for a new sprint and branch for a new release. Each build has branch paths in these places:
Source Settings > source control folders (multiple active and cloaked paths)
Process parameters > Build > projects to build (paths to multiple
projects)
A build only ever points to one branch location in tfs, and the only part of that branch path that changes each time is the number associated with the current sprint or release. So for instance a build might switch from pointing from /developement/2.10_1/ to /developement/2.10_2/.
Is there a way to define a base-path once in your build definition and then use it throughout the definition? That way each time we switch branches we only have to specify the branch path in one place? Even better, could that variable's value be managed outside of the build definition so that it could be used by several build definitions? Could the variable value possibly be dynamic based on the active Iteration for the project?
Or can the path entries in the build definition be defined in such a way that they are relative to the branch?
Any suggestions? Thanks!
I've set up our builds so that they use a custom $(BranchToBuild) parameter which is inserted into all the build paths within the build. This eliminates the problem you have in the 'projects to build' section of the definition.
This parameter can then be passed into the build by adding a /p:BranchToBuild=2.10_2 to the build parameters in the Queue Build dialog, so you can manually select any branch to build from with every build you queue up.
You can also set the default parameters within your build definition so that it defaults to /p:BranchToBuild=2.10_2 for every build - each time you make a new branch the "current" one you can just change this default and all subsequent builds will automatically use the correct branch (but you can still go back and do a build off any previous branch easily, for example if you have to merge a bug fix back into a previous release)
The only hassle with this is (as you've spotted) that you have to also map the code for the branch onto the build server for it to be got from source control. There is a shortcut for this though - in the build definition, select all the mappings for your old branch (10.1_1) and copy them. Paste into a text editor and you'll see that each just becomes a simple line of text. Now you can globally search and replace 10.1_1 with 10.1_2, then copy and paste the entire set of mappings back to the build definition. Miles faster and less error prone than manually editing every line in the mappings.
All the above means that setting up a new branch takes me about 30 seconds.
The caveat is that the build definition points at the vcproj file that controls the build, and it gets this file before it runs the build itself. It is therefore problematic to put your build definition inside the branch. Generally this is not a problem, but occasionally when you need to update the build definition it can therefore break your branches unless you also manually point the build definition at the correct variant of the vcproj. Generally I get around this by avoiding breaking changes in the build, so it has only bitten me once in the last 7 years.
I have a project that has 3-5 different mercurial branches going at all times. I want to schedule a weekly Jenkins test to run our tests on all relevant branches.
What I want, I think, is a parameterized build, with the branch name as the parameter, and then to have a list of branches, and once a week, run the parameterized build with each of the parameters in the list.
However, I see that you can't send parameters into a triggered build. I assume that there is a plugin for this. Is job Generator the correct plugin? Is there something better?
I should mention that currently, we are doing this with multiple SCMs, and having the body of the build have a sh loop that runs through each directory and runs the tests. This is really inefficient, and a pain to maintain...
I can suggest one solution but it couldn't be called elegant.
Firstly, you need create multi-configuration project (aka Matrix project).
In this project you need declare one node (it can be already existed master node)
And one type of axis (for example BRANCH - be careful don't use Jenkins Set Environment Variables variables) with values corresponding for each branch (for example default, testing, devel, etc).
After you need add in your project build action in which you need check environment variable (previously declared $BRANCH) and discover for which branch this build was launched (the main idea is illustrated by example with using bash).
And finally you need manually get sources from corresponding branch.
Next build steps can be the same for all branches.
This approach have set of drawbacks:
1. You can not triggered this project by changes in repository (you can check using Mercurial plugin only one branch).
2. All subprojects will be rebuilt even if they have not changed.
3. Appropriate only for statically defined branches.
4. Not elegant.
But it has one advantage versus parameterized build:
1. All artifacts (and build logs) of branches is stored in separated directories (because they are separate subprojects).