Is there any plug-in or configuration that I add to jenkins server and make me able to select my favorite destination server for deployment ?
I could add configuration to jenkins which makes me able to select "the branch" that I want to build. with a cascade menu . I want some thing the same , for destination server.
There is an option called "Restrict where this project can be run" where you can specify which servers the job should be run. For that you have to label your servers. You can do that under Manage nodes section of Jenkins.
To make the choice at run time, you can launch the jobs via Jenkins cli and populate the Label parameter with desired value. I am looking for the site where I picked up this info but have not been able to find it till now.
Check if these two sites help:
http://michael-prokop.at/blog/2014/03/01/jenkins-on-demand-slave-selection-through-labels/
https://developer.cloudbees.com/bin/view/DEV/On-Premise+Executors
I found the solution. It is actually combination of this two articles :
first step-> https://wiki.jenkins-ci.org/display/JENKINS/Step+by+step+guide+to+set+up+master+and+slave+machines
Second-> https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin
if you follow this two articles. you would have a selective menu when you want to build the software. You can select your destination server to build.
Thanks all of you for your hints.
Related
I need some help to ingrate Jenkins with jira my user case is this one : i would like to feed urls of builds related to a Jira fix version. This is important for us ( audit & compliance purposes )
How can i do that ?
Think you in advance.
regards,
This is how we handled it:
Add a custom text field to every jira issue type. it can be 'build number' or 'build url' or whatever information you need to display regarding the jenkins build
Create a python script that receives as parameters a list of jira issues and a build number.
Using the JIRA python module (pip install jira), the script creates a connection to jira, goes over the list of issues and updates the custom field above to the given build number.
if the list of issues is not known in advance, then instead of parameter you can provide (or hard-code) a JQL query which the script can use to obtain the list of issues.
Depending on your needs, you may want to skip updating issues who already has a build
number set (either manually or by a previous build)
(Sorry, i can't share exact code but it shouldn't be complicated.)
In your Jenkins build, add a 'batch command' item which runs that python script with the appropriate parameters.
I'm trying to create a branch builder job. Our build servers are usually busy running nightly master builds, so I was thinking I could set people's personal machines up as slaves to Jenkins, and have them run the branch builder locally, kicked off from Jenkins
When I try and put a parameter in the machine restriction list, I get and error:
(pending—There are no nodes with the label ‘${BuildMachine}’)
Where BuildMachine was a selection of which machine to build on.
Is this possible, or is the list supposed to be restricted to all available machines only?
Sounds like you're talking about "traditional" jobs, like Freestyle, Maven, or Multijob (as opposed to Pipeline or Multibranch Pipeline). Please let me know if that's not the case, as the answer will likely be very different.
The restriction list does not allow you to use a parameter/variable (or even a wildcard or regex). Instead, you should take a look at the Node and Label parameter plugin:
This plugin adds two new parameter types to job configuration - node and label, this allows to dynamically select the node where a job/project should be executed.
Once installed:
Go to the job configuration and check This project is parameterized.
From the Add Parameter dropdown, select Node.
You can set the parameter name, choose a default node, and optionally allow all or a subset of nodes to be selected.
When you next run the job, you'll be able to select the node from a dropdown.
Caveat: Once a node/label parameter is added, the "Restrict where this project can be run" entry will be ignored; probably best to uncheck the selection to avoid confusion.
I need to pull from a specific label in TFS and then build it in TeamCity. Is there any way to do this? I've done it before in SVN with custom steps, I was trying to avoid this. I assume a custom step like the below would work, but wanted to avoid it if possible.
Any ideas? Maybe a way through the fetch URL or appended to the collection URL that I don't know about.
tf get * /r /version:Lyourlabelname
See https://youtrack.jetbrains.com/issue/TW-7370
You can run a build on a specified change[set] manually using Run
Custom Build dialog.
Edit:
Another way is to run tf.exe using the Get command.
See https://msdn.microsoft.com/en-us/library/fx7sdeyf.aspx
Synchronize a workspace to match a labeled version of the team’s codebase
c:\code\SiteApp\Main>tf get /v:LLastKnownGood
Synchronizes the workspace to match the items in the codebase that are labeled LastKnownGood
Edit 2
Also see https://teamcity-support.jetbrains.com/hc/en-us/community/posts/207091635-Checkout-TFS-Label
TeamCity does not support getting labeled sources at this time. The feature request is addressed by TW-5061, please vote for it.
In Jenkins, I want to create a job with two parameters. The first one gives a choice of environments (like DEV, TEST, PROD). Once the environment is selected I want the second parameter to show the list of servers from the selected environment. So the user can select ALL or a particular server to install. Is it possible to do this in Jenkins or any of its plugins? Basically I want the second choice box to be updated when the first choice box is selected.
This is not possible using the default parameterized build option in Jenkins. There may be another plugin written that does this (there are many many community contributed plugins) but I'm not aware of one.
However I have written several custom Jenkins plugins to essentially customize the build page UI for needs that are specific to my company. Writing a Jenkins plugin seems intimidating at first, but it actually isn't too hard if you know Java and Maven. If you don't know either of those, then you will need to find someone who does. https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial
Here is a similar question with a similar answer: Hudson or Jenkins Parameterized Builds using dynamic choices
I don't think that much dynamic choice parameters are available through plugins also. But you can try out this plugin to get what you want. Extended Choice Parameter Plugin to achieve what you want. But not exactly you want. Hope this helps.
Our team is sharing a Jenkins server with other teams, and this currently means that we are sharing the same OS-level build-user account. The different teams' OS-level build-user settings (Maven settings, bash settings, user-level Ant libraries, etc...) have collided a few times--"fixing" the settings for one team's jobs inadvertently "breaks" another team's jobs. The easiest sol'n that occurs to me is giving each team its own OS-level build-user account with which to execute its Jenkins jobs--but I cannot find a way to do this.
I have checked with Google, and also here
https://wiki.jenkins-ci.org/display/JENKINS/Use+Jenkins
and here
https://wiki.jenkins-ci.org/display/JENKINS/Plugins
to no avail.
Is there a way to do this? If not, can you recommend any best practices for segregating sets of builds from one another?
Maven Specific
You have two options that come to mind,
Add additional installations of Maven into your Jenkins global configuration, each using their own Home directory, and thus settings files. This will allow you to use totally different version of Maven, and selected based on Job requirements (You are given the option to select which "version" of maven you wish to use on the job itself.
Similar to (1), but specify specific settings configurations using Maven command line arguments. Its a little less "obvious" but may be quicker to implement
Multi-slave
You could possibly make use of multiple slaves on each machine. It increases the overheads of the builds quite significantly, and the implementation is such that you'd have multiple user accounts on a machine, each setup as needed, and then one slave instance for each user.
I'm not sure these solutions will totally answer your problem, I'll have a think and see if anything else pops into mind, but it might give some starting points
Key builds to a specific team directory that contains that team's settings. For example, provide a parameter 'TEAM' to every build, set its default value to the appropriate team name, and use that parameter as a key to a directory that contains the team's settings (so instead of using ${HOME} as in what you want to do, you'll use something like ${TEAM_SETTINGS}/${TEAM}).
You can set per-job users (who has access to/can build a particular job).
Under "Manage Jenkins" > "Configure System" >
Click on Enable Security
Check Project-based Matrix Authorization Strategy
However, I do not think there is a "per-build" option for a single job.
If you have the same project that you are sharing between teams, you could (and probably should) create two jobs for this project, and have different libraries/scripts be used in each.
You could also parametrize the build (On the Job Page, "Configure" > This build is parametrized) and supply the library versions, etc via string parameters.
You could also use a parameter to be the team's name, and in your build script change libraries based on the parameter:
For example, have a parameter called "TEAM", with choices: TEAM_A and TEAM_B, and in your script, have
if [ $TEAM == "TEAM_A" ]
then
ANT_HOME=/opt/ant/libA
else
ANT_HOME=/opt/ant/libB
fi
======================================================================
Have you considered sourcing your settings? In Linux, you could do this by saving your OS settings in a script file (for example paths, etc), and using source /path/to/settings/file, in Windows it would be call /path/to/settings/batch/file.
Can you give examples of OS level settings that you would require and per-build user for?
You problem is a common one.
Whenever something nonstandard is installed on a build server, something will break for someone.
The only solutions I know are
Set up a separate build slave for each team or product. Then they can install whatever they want on the build slave and any mess they create is all their own fault.
Any dependencies required by a job need to come with the job. This is my preferred way of working. For example: If a job needs a library or a tool, the library or tool is not installed on the build server but in the source tree and the build uses it from the source tree.
Sometimes the latter way is more work. You need to set up the tools or library so it works when it is installed in the source tree. Some tools have hard-coded paths and they do not work. In that case you can install the source of the tool and compile the tool during the build.
An even better solution is to set up separate Jenkins jobs for all the tools and libraries and the jobs that need a library or tool will download them from the Jenkins jobs.
This way you can control all your dependencies and different jobs do not conflict when e.g. one needs an older version of a library and one a newer version. And if someone upgrades the library, it is immediately visible in the version control who did what.