I am working on some automation and I need to update the view programmatically.
UseCase: I have a jenkins view where I add all the jobs based on the release number and I do that by giving regular expression here-
I want to update this regular expression through script.
Is it possible to do the same through a groovy script?
Here is how you can update the regex filters from Groovy. I have come up with the following with the limited information you have given. You may have to improve it based on the options you have enabled in your view.
def viewObj = Jenkins.instance.getView("VIEWNAME")
List<hudson.views.ViewJobFilter> jobFilters = new ArrayList<>()
jobFilters.add(new hudson.views.RegExJobFilter('.*NEWREGEX', "includeMatched", "NAME"))
viewObj.setJobFilters(jobFilters)
Related
I have created a Global choice Parameter using Extensible Choice Parameter plugin.
I am using this parameter list in one of my parametrized jenkins job.
Is there a way in jenkins, where I can execute the job with each of the parameters in the Global choice Parameter list?
I have had a look on Build Flow job in jenkins, as suggested in this answer, but it seems it accepts hardcoded parameters only, and not dynamic.
I finally managed to resolve this using the following steps (with great help from this post) -
As my parameters list is dynamic in nature, it could be added or modified according to other jobs, we have managed it in a text file.
Next, We have used Extensible Choice Parameter plugin to display the parameters, using the groovy script -
def list = [];
File file = new File("D:/JenkinJob/parameterList.txt")
file.eachLine { line ->
list.add("$line")
}
return list
Now I want to call this jenkins job for each of the parameter.
For this, I have installed, BuildFlow plugin, and crated a new jenkins job of BuildFlow type -
Next, get the Extended Choice Parameter plugin, and configure it as follows -
Now in the flow step of this job, write this script, where "Feature" is the parameter, that is just created above, and within call to "build" parameter, pass in the name of job which we want to call for each parameter -
def features = params['Features'].split(',')
for (feature in features ) {
build("JobYouWantToCall", JobParameter: feature,)
}
I've got a Jenkins build with a choice box for build prefixes by release. It helps trigger a job based off the value of whatever specific build the person wanted.
I wanted to take the value of that choice box and transform the variable into the correct prefix based off the naming conventions typically used on this server for triggering the job based off its name.
So let's say I've got build prefix choices specifically for,
ReleaseOne
ReleaseTwo
none
For none, meaning the parameters used won't try to access or set any specific release-based info by triggering the non-release-specified build.
I wanted to take the value of Release_Prefix and transform it, if needed, for the job that I trigger later. I was hoping to accomplish this with a dynamic parameter or similar mechanism. I'm not sure if my script is bugged, or something fundamental is not working to my intent. This might be the case, based off some alluded feedback from a similar question.
Can I do something like this snippet below? If not with Dynamic Parameter plugin + GroovyScript, what would you suggest? This currently seems to return nothing, regardless of my choice.
Formatted_Prefix parameter, Dynamic Parameter
switch(binding.getVariables().get("Release_Prefix"))
{
case "none":
return "";
case "ReleaseOne":
return "ReleaseOne_";
case "ReleaseTwo":
return "ReleaseTwo_";
default:
def prefix = binding.getVariables().get("Release_Prefix")
return "$prefix_";
}
There's multiple ways I can overcome this, but if I can do it at the initial parameter stage, that would be best for me.
You can use EnvInject Plugin for this.
check the checkbox Prepare an environment for the run and
write your script inside Evaluated Groovy script text box
def prefix1 = Release_Prefix + "mydata"
return[prefix:prefix1]
Does jenkins have any way to set global properties from a job? We have many such needs for this - but specifically - we have a number of slaves, across unix and windows, and various different permissions locations - so it's not easy to have a connected file system. We have various levels of maturity that we promote through - so for instance, we want to promote some build number to UAT - and then promote whatever number is in UAT to training and so on. So - really, in the "release to uat" - we want to store some idea of which build number was released - and read that from the "release to training" job. At the moment we are hacking it by restricting them to run from the same slave, and writing it to a file, which is very much not ideal.
I may not have totally understood your question but you can perform a lot of work with the built in groovy scripting function in jenkins, including reading parameters from other jobs, and rewriting or initializing the parameters in the current job. You can use parameters like this to record information that can be retrieved on demand by other jobs
For instance you can find the build number of the last successful build of a certain project:
import hudson.model.*
def hif = Hudson.instance
def a = hif.getItems(hudson.model.Project).find{it.displayName.toUpperCase()=='MY_PROJECTNAME'}.getBuilds().findAll{it.result==Result.SUCCESS }.first()
out.println a.number //build number
out.println a.buildVariableResolver.resolve('someVariable')// some parameter used to call a
(you could include any other criteria at this point)
If you want to save information to a parameter that can later be read by another bulid step or another job then you first create the parameter in the job config, then write to it in code like so:
import hudson.model.*
def hif = Hudson.instance
def buildMap = build.getBuildVariables()
buildMap['MySpecialVar']='SomeValue'
setBuildParameters(buildMap)
def setBuildParameters(map) {
def npl = new ArrayList<StringParameterValue>()
for (e in map) {
npl.add(new StringParameterValue(e.key.toString(), e.value.toString()))
}
def newPa = null
def oldPa = build.getAction(ParametersAction.class)
if (oldPa != null) {
build.actions.remove(oldPa)
newPa = oldPa.createUpdated(npl)
} else {
newPa = new ParametersAction(npl)
}
build.actions.add(newPa)
}
Combining these techniques you could for instance:
Save a bunch of information as 'output parameters' in job one
Find the most recent successful instance of job one and read its parameters
If necessary save those parameters to job2's parameter list so they are accessible from other build steps.
OR
If you are happy to use files then you may be able to use the archive plugin, where you would write to a file and then archive it as a post build action. The file would be saved to the master, and you could use the 'copy artifacts from another project' option in the second build to retrieve the file. You can use parameter filters and the techniques above to pick the right build.
Setting an environment variable permanently is entirely dependent on the underlying Operating System.
For example on Windows, the SetX command can be used, however note that SetX only takes affect after the next process is created by the system the inherits from global configuration. So, if you run SetX, and then run another job, it will not notice the change. However if you run SetX, and then restart Jenkins process (from which all child jobs inherit variables), then the other job will notice the change.
Not sure how to set permanent variables in Linux, but a quick Google search returns this answer: https://unix.stackexchange.com/questions/117467/how-to-permanently-set-environmental-variables
I have a web-app (grails 2.3.5, quartz plugin) with multiple users. Now I want that my users can schedule jobs using quartz. I wonder what the best approach is to separate Triggers from one user from the triggers from another user.
e.g. provide a list of all scheduled tasks for a given user
Are there any recommendations how to make this differentiation?
Implementing some scheme for naming your triggers would likely be the best approach here. That way you can query the triggers for a job and filter them by some type of matching pattern.
It's really up to you to decide how you want to manage the visibility and management of the triggers. Using the trigger name seems to be the most logical approach in my own opinion.
Alternatively, you could build a framework (e.g. Domain model) that relates the triggers to a user.
Update
In light of the content of your comment I'd like to offer you a glimpse into how you can dynamically add a trigger to an existing job. This is only an example to help you get further down the path of accomplishing the goal you have.
import org.quartz.CronScheduleBuilder
import org.quartz.Trigger
import org.quartz.TriggerBuilder
...
def jobManagerService
String cronExpression = ... // whatever the expression is
Trigger trigger = TriggerBuilder.newTrigger()
.withIdentity("UniqueNameOfYourTriggerHere-UserId")
.withPriority(6)
.forJob("com.example.package.JobClassNameJob", "groupName")
.withSchedule(CronScheduleBuilder.cronSchedule(cronExpression))
.build()
// if you need job parameters
trigger.jobDataMap.putAll([param1: 'example'])
jobManagerService.getQuartzScheduler().scheduleJob(trigger)
Need some help regarding jenkins job view;
I need to have one Jenkins view which matches two conditions
Specific Job name (ex: all the jobs which has trunk as one of the string in job name)
and Job Status;
Basically i need to list all the jobs which has job name containing trunk and which is failed under one view.
I know there is sectioned view and list view where we can list the jobs based any one of the condition above but i need to match both the condition.. is there a way to do this using any of the Jenkins Plugins?
Appreciate your help in this regard.
Regrds,
Raju.
You can use the View Job Filters plugin for this - it lets you build views which chain together filters to create the custom views, and the filter options include:
Job name, including regular expression filters (i.e. you could filter by ^.*trunk.*$)
Job status
I think that should allow you to build the list view you need. The image below shows an example taken from the build system I manage, where we were able to create a view with the same characteristics as you require (naturally exchange labos for trunk).