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.
Related
I have a significant amount of pre-configuration that I want to automate for Jenkins. E.g. Pre configuring gerrit for the gerrit trigger plugins, pre configuring saml, libraries etc
I'm aware of two methods typically used to do similar tasks:
Configuration as code plugin + yaml configuration
Groovy scripts to execute from the init.groovy.d directory of jenkins home on Jenkins startup
My users want to be able to update Jenkins configuration from the UI without needing to update yaml, suggesting the config as code plugin isn't fit for our purpose as I believe it reapplies the config when the Jenkins container is restarted.
My hunch is to use groovy scripts that remove themselves after the first execution so that they don't reapply themselves on restart.
Is there a more standard way of pre configuring Jenkins? or is groovy my best bet?
TL;DR: Use the file system
Why? There is no "standard" way to achieve what you intend; the two approaches that you suggest are viable options for sure.
From operational point of view, however, it will be good to select a solution which is
generic (so it can cover all aspects of Jenkins configuration) and
"simple" to use
Now,
"Configuration as code" makes you depend on the corresponding plugin -- it may or may not support a specific configuration option
With groovy, it is sometimes quite difficult to find out how to set a Jenkins configuration option (and how to store the setting permanently).
Since all Jenkins configuration data is stored on-disk, another option for bootstrapping Jenkins with a well-defined configuration is to pre-fill those configuration files with proper content right away:
You can be sure that this works in all cases, including all border cases (like, secret/encrypyted data)
Users can change the data later on as needed
Usually, it's quite easy to find the proper configuration file
On the downside, there is a risk that the configuration file format might change with newer versions of the core or of some plugin. However, a similar risk exists for the two other solutions that you suggested.
Tip: for rolling out such pre-configured Jenkins setups, it is helpful to disable the Jenkins setup wizard by setting jenkins.install.runSetupWizard to false.
When you combine words like : pre-configuring Jenkins, init.groovy.d, jenkins home, jenkins startup, etc, it sounds confusing o_O
When Jenkins is ready to use, usual folks just need to create jobs or pipelines. If you need to create a job or pipeline, you just need to install and configure some plugins. Very few of them need groovy, because the goal is "Easy to use".
Advanced user are able to create its own plugins, with java. But almost all is available as plugins.
You can use groovy in a pipeline scripts or declarative pipelines.
So if your question is more like "What is the best way to create and configure jobs or pipelines", I can advise you:
Try much as possible to use pipeline scripts or declarative pipelines.
Use just verified and supported plugins.
Stop call shell scripts in hard drive.
Stop using complicated configurations. Almost all of requirements are already implemented and documented.
If you have a requirement and no one plugin seems to help you, ask here in stackoverflow or develop your own plugin focused in configurability, so you can release it, for the benefit of Jenkins Community.
I'm planning to reuse the same set of build parameters (like 10 of them) across dozens of jobs.
One way is to create a job, and clone it. But what if I want to change the build parameters at the later time when I have already hundred of similar jobs. Editing all of them one by one could be a nightmare.
Is there any way of managing parameterized projects?
As solution to this problem I would imaging some option or plugin where I can define global set of parameters and reuse them across my jobs.
You could try using Configuration Slicing Plugin. This plugin allows you to perform mass configuration (including parameters) for a group of jobs.
Alternatively you could try writing a groovy management script to set the group of parameters to all those jobs at once. A good starting point would be this, note that this is just printing the current jobs parameters, you would have to alter that script to do want you want.
Unfortunately mentioned Inheritance Plugin is not maintained anymore, it's buggy and it has some limitation such as Trigger Parameterized Builds cannot be implemented in Parent Projects, it's also difficult to override specific configuration and does not play well with Folders plugin.
Alternative ways are:
Job DSL Plugin which allows process jobs with DSLs which can be used as templates (a "seed" job), then run these DSL scripts into your jobs (read the tutorial). It's actively maintained on GitHub. For more advanced solutions you may use Pipelines instead.
Template Project Plugin which allows to set up a template project which has all the settings you want to share across your other jobs (by selecting use all the publishers from this project and pick the template project.
How about EZ Templates Plugin (check also GitHub page)?
Just remember that when you create a template, that job shouldn't actually do anything else then being a template (meaning: you should not run that job) and put only the minimum common configs there, nothing else or things can get messy. That way you shouldn't have any problems.
Using Parameterized Trigger Plugin you can save the properties in a property file and pass them across jobs. Then in you can override or use as is in the subsequent jobs.
Also this would help: Retrieve parameters from properties file.
You could also consider using Pipeline Global Library.
This plugin adds that functionality by creating a "shared library script" Git repository inside Jenkins. Every Pipeline script in your Jenkins see these shared library scripts in their classpath.
Try Inheritence-Plugin which can help to solve the problem. We can read from plugin description:
Instead of having to define the same property multiple times across as many projects; it should be possible for many projects to refer to the same property that is defined only once. In other words, everything that is defined multiple times, but used in the same way, should be defined only once and simply referred to many times.
So to define the property only once across multiple jobs, you need to:
Create a new job as Inheritance Project.
You may set it as abstract project choose This build is parameterized.
Add Inheritable Parameter and set it as Overwritable.
After saving, set this project as parent, so parameters can be inherited.
Check the Jenkins Inheritance Plugin Tutorial Video for overview of the main features. See also GitHub page.
Unfortunately the plugin is not well maintained and it can be buggy when using with the latest Jenkins (e.g. #22885).
You may manage this using single property file which can be injected in all the jobs
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?
Hi im using jenkins but i need to ask if it is a code ispector ?
Or does it has more functions that I can use because I cant find them and its important ?
Jenkins itself is not a code inspector. It is more of a Continuous Integration server that provides a plugin API so that it can be expanded to do different things. There are alot of plugins available, so it really depends on your language and what you want your inspector to do ( static analysis, code coverage, etc )
A quick search provided this page Jenkins Plugins
I have Jenkins installed ( I do not have network access to it at the moment ) and it has a plugins page you can go to to see the available plugins. That would probably be the most up to date list.
We currently use Jenkins with a number of plugins to do builds and analysis on every commit. If you want to just run an analysis, you may want a standalone analysis tool.
I am using Jenkins for a project and would like to know if the following is possible. I have four separate SVN modules which are checked out as part of the job. Each SVN module is added to a separate directory. Depending on which module is updated during the SCM polling, I would like to only build certain directories.
With Cruise Control, I was able to set a variable for each module that was updated and passed those variables to the ant build script to control the build.
Has anyone done anything similar or have any ideas?
Thanks,
Sean
This Question is pretty complex. You are touching too much different parts of CI builserver and some tasks out of it.
Basically ... providing job / project in Jenkins with information that controls behavior of build itself is not best way, but if you have no other option, well, then you have no other option.
Build itself should be enough agnostic and it should contain all the parameters enabling build to be successful both in CI, and in Workstation ( from cmd.exe, for example ).
Depending on which module is updated during the SCM polling, I would
like to only build certain directories.
So basically you want Maven build system, which provides model/module based conditional build, not building one single Project, like Ant does.
With Cruise Control, I was able to set a variable for each module that
was updated and passed those variables to the ant build script to
control the build.
Here you want to have some kind of similar Build Triggering capability. Here comes place where without more detailed explanation of requirements only thing I can suggest is to check out Pramatreized Build Trigger plugin, which would allow to trigger build by parameters you set.
Has anyone done anything similar or have any ideas?
Finally, here you can also check out this plugin: https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin
In the conclusion, some features are provided by Jenkins out-of-the-box, so if you use Ant, you can easily use Environment variables and start building your needed behavior. Usually after investing some time by thinking how to do something without help from tons of Jenkins plugins it somehow makes you really understand, what is the key of thing you want to achieve.
Hope I helped somewhat. Cheers, mate.