Multi level Multi select extended choice parameter properties file - jenkins

I want to use "Multi level Multi select" feature in "extended choice parameter" in Jenkins configuration. But my properties file is in gitlab. How can I use it?
Is there any other alternative way apart from placing my properties file in Jenkins server?
My purpose is to create a small file with list of deployment objects and control which objects to deploy and which objects not to at different levels. Could you please help.

Related

jenkins pipeline groovy - list box dependent on another listbox

I am alowed to define Jenkins pipeline just by editing a Jenkinsfile (stored in Git) and a predefinied shared library, written in Groovy.
For such a build I can use more datasets what are dependent on each other. Dataset A contains items what can be used as filter parameters from dataset B and so on. A parent-child relation.
So, it would be nice to have N listboxes (choices), already after hiting the "Build with Parameters" link and those listboxes to depend on each other. In the backgroud, a dedicated groovy script (from a shared library) would collect items for each corresponding listbox based on its parent item.
Is it possible?
Jenkins was not built with that level of interactivity in mind, but you still can achieve that with two options.
One is to make your own front-end to the job that can change itself however you want. Once the final parameters are determined, you can trigger your job on Jenkins with "webhook trigger".
The other is to use ActiveChoice plugin.
Sometimes, to handle complex dependencies, your page would need to use JavaScript, and you would have to put that JavaScript in your page. For that, you need to write Groovy that generates that JavaScript. This is notoriously hard to write and to debug.

How to reuse Build Parameters across multiple Jenkins jobs?

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

Displaying in Jenkins content from workspace text file in build screen

I have a Jenkins job that stores artifacts as a post-build action. Within these artifacts is a text file that tells which version of the software has been built. Is it somehow possible in a Jenkins project to get access to this text file and displaying its contents somewhere on the Jenkins build page somehow? This way the build manager would instantly see what software version this archived artifact contains. Thanks!
There are more advanced ways with GroovyScript, but I can suggest something like this:
Use Description Setter plugin. It uses RegEx to look at the console output (build log) for a pattern and sets the description (as seen in screenshot) accordingly.
If you don't have the version already printed in console log, you can print it out with either
cat filename (Linux) or type filename (Windows). No need to store a version text file as an artifact (unless you need it for other purposes)
To answer your question directly, in order to add text to actual build page, you can use Groovy Postbuild plugin, something like this:
def workspace = manager.build.getEnvVars()["WORKSPACE"]
String fileContents = new File('${workspace}/filename.txt').text
manager.createSummary("folder.gif").appendText("${fileContents }")
The plugin page has a lot of examples.
I got a revised proposal. Since all you really want is to include a semantic versioning information in your displayed build name and/or description, there is a simpler way to do this.
First of all I have stumbled upon a plugin that does the extraction of your version from the Maven or SBT build process quite nicely - the Semantic Versioning Plugin. This does what is advertised - extracting the version from POM or whatever and including this as a file and a variable in your build process. So you have the freedom to use both, either include the file in your build process and do what you heart wishes AND/OR use the variable to affect the build flow in Jenkins. Now, because this plugin still have couple of bugs I would like to point you for now to my own build of this plugin with fixes already in that can be obtained from here. I will take my own version down the moment that all fixes will be merged to the official plugin...
Then let's start with the name. As suggested previously the best way to do so is to use the Build Name Setter plugin. In order to use both plugins to set up a name for your build navigate to the configuration of the project and find an option named "Determine Semantic Version for project" in there, activate it and either use the default name of the variable or provide your own. When you're down scroll down a little bit to the option named "Set Build Name" and activate it. By default you will see the regular build naming convention there - #${BUILD_NUMBER}. You can use that variable as well as any other provided by any plugin, but in this specific case you need to use the environment variable that you have named above, i.e.:
#${BUILD_NUMBER} - ${ENV,var="SEMANTIC_VERSION"}
This will set the name of every build to something more meaningful, so in this case it may result in #76 - 0.0.76-SNAPSHOT. Obviously you're free to experiment on your own to tailor the name of the build to specific format you desire. Keep in mind that it might break your page flow a little bit since the name will be longer than usually, therefore it will push that table with latest builds on the left side of the screen as well it will affect your dashboard.
Now, in order to customize your build information further you might want to take a look at Description Setter Plugin as well. Personally, since I have started to investigate this case further, I use the combination of both at this time. You can use the same token expansion as the one listed above, the big difference is that you will need to create/maintain a file that will be used to create the description. What you will include in this description is only limited by all the variables or token published by Jenkins itself or any of the installed plugins (take a look here). Personally I am listing some information gathered from different places as well as some additional stuff created/provided by Maven during the build process. So it's pretty handy.
Both plugins mentioned above (Build Name Setter and Description Setter) can use other sources of information to build the name and description - it can be properties files, etc. For example one can use Job Exporter Plugin to drop a properties files to read all possible information about the build itself in the form of, as example:
${PROPFILE,file="hudsonBuild.properties",property="build.user.name"}
In this case this will resolve to user name of the user who have triggered the build.
Again, any variable visible to Token Macro plugin can be used.

Jenkins Ant and dynamic build.properties files

I have a single code based being used to build an application for multiple platforms.
Locally I have setup a main build-env.properties file, and a series of additional *.properties files that I use to switch settings for the different platforms I am publishing to.
Doing my build on the command line I simply use the command:
ant build -propertyfile dev-build.properties
How can I do this in Jenkins?
I currently use the "Invoke Ant" Build Step with the target set to build, but am at a loss for how to specify the secondary propertyfile?
Although not exactly the same, you can take the contents of those properties and put them into the Jenkins Invoke Ant build step, utilizing the properties advanced field.
The most basic way:
You will need to create a new task for each different set of sub properties you wish to utilize.
In your "Invoke Ant" build step, if you press Advanced..., this reveals a "Properties" field, you can copy the properties from one of your *.properties files into that field.
Repeat for each different properties file you wish to utilize.
Parametrized build plugin might help you. This is assuming the number of properties you are changing is one or two. So when you run a job, you get a drop-down to select you OS and go.
Though, as I have mentioned here , what goes against this plugin is that it makes the process manual
On this thread Hudson / Jenkins: share parameters between several jobs you can read the 2nd option in Anders's answer as an alternate approach.
A better approach for this is using a parameterised job with file parameter(refer to doc for creating the builds). Mentioning the file location as "propertyfile" would help. This would be better than reconfiguring the job again and again to run a build (To copy the properties file to the input location).

How to configure Jenkins in order to build project using ant and custom args

There's too much routine with building next project version using ant. The routine is in several properties files that must be edited before running ant task. I took a look at Jenkins as a system to make builds (including night ones) but I have a problem with changing properties.
Is it possible (if yes, how can I do it) to type parameters in Jenkins configuration before build in order they will be passed to ant?
What I really mean is the following schema (I used in manual builds):
there're 2 properties files that contain data about build version, src destination, emails to notify about new build and so on.
corresponding properties' keys are used in Ant tasks and these properties are changed manually before build.
some properties are read by Java util and used for their own part during build.
there're also 3 or 4 ant XMLs that a imported in build.xml, and these xmls also read properties from mentioned files.
What I want to do is:
change key properties in Jenkins
press build project
my data will overwrite data in properties files OR will be passed as ant vars values straight to the ant's task(s).
as a result I receive new build with corresponding notifications (they're made through ant)
Are there mechanisms that allow one to make such schema work via Jenkins?
Thank you in advance.
In Jenkins, you can use the parameterised build feature to specify those parameters you need to substitute into your build.
For example, if specify a parameter called server and, when clicking "Build Now", you enter test, the build will be executed with an environment variable you can access called ${server}.
Then, in your "Invoke Ant" build step, if you press Advanced..., this reveals a "Properties" field. Here you can enter my.ant.property=${server}.
That's equivalent to calling ant -Dmy.ant.property=${server}, and will be expanded to ant -Dmy.ant.property=test.
Another option : Set environment variables for the scope of the build using this Env plugin. So if the properties you are using are environment variables or can be set as them then you want to use this one. Though it might involve some effort in changing the build scripts, but it can be a good option :
Q : Why would I use this one as I already have parametrized build plugin
A : Because the parametrized build plugin requires human interaction if there is more than 1 choice. For example building for Release 1 or Release 2 or Test branch.
While in the Env plugin, you can set the property once for each choice and then create a respective job for each. Then just schedule the job(s) thereby eliminating the human factor.

Resources