I want to include a job with a declarative pipeline configuration into a job group in order to receive higher build priority. It works in scripted pipelines and also for conventional jobs, but it can't get it to work with a declarative pipeline.
The snippet generator suggests something like this
properties([[$class: 'JobInclusionJobProperty', jobGroupName: 'Release', useJobGroup: true]])
When I insert it on top of my pipeline, it will run, but it looks like the setting is ignored. What am I doing wrong? Is it even possible in declarative pipelines to use properties at all?
Related
I am new to the Cloudbees Enterprise of Jenkins and to the concept of "templates".
I am trying to define a new template and this template will be used by 20-30 number of jobs. The job is a basic build job. After the build, I would like to have code analysis plugin. How can I define it in the Jenkins Template.
I can define it while creating a direct job in "Post Build Actions" but not sure how to define the same in a template.
Do you have any solutions/ suggestions ?
Cloudbees templates plugin is very powerful but not easy to master. Creation and administration of templates is not as user-friendly as one wishes it to be. ;)
For an introduction I recommend reading the following resources:
Basic concept
Template documentation
Tutorial for simple job template
Make sure you understand the difference between builder template and job template. I assume you want to create a number of jobs using the job template. Follow these steps:
First of all create a normal job that contains all actions you want to perform by all templated jobs.
Make sure this job works as expected for one example configuration.
Now create a new job template:
You will need to decide, which parts of the job configuration need to be adapted to each jobs configuration (e.g. source code repository). Create an parameter for each configuration option.
You might want to do some pre-processing on the job templates parameters using some transformation script - but we skip that for now.
Now you need to add an XML description of what the generated job should do. I recommend copying this XML description from our example job created in step #1. You can access it via this URL: http://your-jenkins/job/this-job/config.xml. Simply copy&paste the XML code in the browser. Newer Jenkins versions also allow to read the jobs XML configuration via the user interface.
Finally you need to fill in the templates arguments within the XML configuration. Simply replace the specific (hard-coded) values by a reference to the name of the templates parameters created before: ${param_name}
Save the template
Now create a new job. On the job creation screen you should be able to select your newly created job template as job type. After creating a job of the templates type you can define all template parameters for this specific job.
Try to run the template-based job and make sure it works as expected.
Create more template-based jobs as needed.
All template-based jobs share the build steps defined by the job template. If you change the job template later on, all depending jobs are updated accordingly. This is a very efficient way to administrate a large number of similar jobs. It is very much worth the effort. Good luck!
I have a number of different projects, with Jenkins CI jobs configured for each of them to run tests. When I create a new release, I have a second job that coordinates between a number of different jobs that go over each of the modules in the projects and updates the versions and the dependencies in the pom.xml's. I would like to make the "update" job conditional on the status of all the CI jobs - meaning that if one of the CI jobs is not green, then the update job will not run at all.
I had a look at the Run Condition Plugin as well as the Conditional BuildStep Plugin, however it does not seem possible do configure them to be dependent on the status of another Jenkins job.
you could hit the other jobs via the API at [JOB_URL]/lastCompletedBuild/api/json and verify the result for each.
to mess around with this:
curl `[JOB_URL]/lastCompletedBuild/api/json` | jq '.result'
you probably want result to say SUCCESS.
this is not fancy, but you don't want fancy in CI; you want something that is not likely to break when you upgrade jenkins. :)
Have a [https://wiki.jenkins.io/display/JENKINS/Multijob+Plugin] ["Multijob Plugin"] ,
In your case, you can add a job in first step and configure in that step, at which result condition of first step, you want to run second step.
Again, in second step, you can configure one/many jobs and can also configure if you want to run them in parallel.
I would like my build job to not build on specific teamcity agents and there is no common pattern for the build agent names. Is there a way I can isolate multiple agents from getting picked up by a single job.
For example I can make sure that the build job does not pick up 1 agent using the following parameter.
teamcity.agent.name
does not match
agent-001
How can I similarly tell the teamcity job to not run on the following agents as well.
"123-agent"
"my_agent"
"test_agent"
"agent_do_not_use"
I cannot use the same parameter, teamcity.agent.name with does not match for multiple agents.
Can you all teamcity experts help me out here please on what is the best way to achieve this.
You can add agent requirement with "does not match" condition which accepts regular expression and set it to:
123-agent|my_agent|test_agent|agent_do_not_use
Using an agent requirement based on presence (or absence) of a specific property coming from agent's buildAgent.properties file would probably be a better solution to using agent names in the requirement.
Alternative means to manage agent's compatibility are: use agent pools and use agent's Compatible Configurations set to a limited set.
You can add a specific parameter inside the agent configuration on the local machine inside: C:\BuildAgent\conf\buildAgent.properties
Then, you can add something specific like: system.Is<MyFeature>Available=True
Then, in teamcity configuration, you will add an Agent Requirement with this parameter.
I am trying to build multiple Jenkins jobs, e.g. job1, job2 where jobs2 is downstream job1, each one needs to run on multiple platforms, e.g. Win, Mac, Unix
I need job2 on Mac to start once job1 on Mac has finished, same for others... but cannot find a simple way to do this simple thing!
I tried the Matrix configuration, parametrized trigger, extended trigger, NodeLabel, but non did the right job
This task looks simple but I could not achieve! Any help is really appreciated
Have you tried the Build Pipeline Plugin or Pipeline Plugin to help address this? You can also consider creating these pipeline dynamically depending on job dependency and then run.
Seems like a fit to me.
I have a job upstream that executes 4 downstream jobs.
If the upstream job finish successfully the downstream jobs start their execution.
The upstream job, since it finish successfully, gets a blue ball (build result=stable), but even tough the downstream jobs fail (red ball) or are unstable (yellow ball), the upstream job maintain its blue color.
Is there anyway to get the result of the upstream job dependent on the downstream jobs?, i mean, if three downstream jobs get a stable build but one of them get an unstable build, the upstream build result should be unstable.
I found the solution. There is a plugin called Groovy Postbuild pluging that let you execute a Groovy script in the post build phase.
Addind a simple code to the downstream jobs you can modify the upstream overall status.
This is the code you need to add:
upstreamBuilds = manager.build.getUpstreamBuilds();
upstreamJob = upstreamBuilds.keySet().iterator().next();
lastUpstreamBuild = upstreamJob.getLastBuild();
if(lastUpstreamBuild.getResult().isBetterThan(manager.build.result)) {
lastUpstreamBuild.setResult(manager.build.result);
}
You can find more info in the entry of my blog here.
Another option that might work for you is to use the parametrised build plugin. It allows you to have your 4 "downstream" builds as build steps. This means that your "parent" build can fail if any of the child builds do.
We do this when we want to hide complexity for the build-pipeline plugin view.
We had a similar sort of issue and haven't found a perfect solution. A partial solution is to use the Promoted Builds Plugin. Configure it for your upstream project to include some visual indicator when the downstream job finishes. It doesn't change the overall job status, but it does notify us when the downstream job fails.
Perhaps this plugin does what you are looking for?
Jenkins Prerequisite build step Plugin
the work around for my project is to create a new job, which is the down stream of the down streams. We set a post build step "Trigger parameterized build on other projects " in all three of the original downstream jobs. The parameter that parse into the new job depends on the three jobs' status and the parameter will causes the new job react accordingly.
1. Create new job which contains one simple class and one simple test. Both parameters dependens, i.e. class fail if parameter "status" = fail, class pass but test fail if parameter "status"=unstable, etc.
2. Set Trigger parameterized build on other projects for the three original downstream jobs with relevant configurations.
3. Set notification of the new job accordingly.