I have a Jenkins script with daysToKeepStr param .
options { buildDiscarder( logRotator(
numToKeepStr:'5',
daysToKeepStr: '7',
) )
daysToKeepStr: discard the builds after 7 days .
But I see in jenkins for every branch one build is still remaining after 7 days . Having 100+ branches consuming lot of storage due to the build being not discarded.
Can someone suggest How to discard all the builds after specific no of days
Related
I have two Jenkins multibranch pipeline projects.
1st must be triggered by the Github and by the 2nd one success build.
2nd must be triggered by the Github only.
I added Properties to Jenkinsfiles (no upstream for 2nd of course)
properties([
// Builds rotation
buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '', numToKeepStr: '10')),
disableConcurrentBuilds(),
// Git project
[$class: 'GithubProjectProperty', displayName: '', projectUrlStr: G_giturl],
// Trigger build from:
pipelineTriggers([upstream(G_artifactsource), githubPush()])
])
The new properties appeared at graphical interface and all worked fine, for awhile.
I do not know what i did, or maybe did nothing, but now all "Build Triggers" of all branches are empty. Github webhooks are still working, but not the upstream triggers. For testing purposes i made two new repos and did the same projects for them. New projects work good.
There is no "apply" buttons inside branches at the Multibranch projects, I can't add or delete build triggers by interface. Changing of Jenkinsfiles don't help too.
Is it bug or i missed something?
No "properties" for multibranch. Only "options" and "triggers"
Next code works fine.
pipeline {
agent none
triggers {
upstream G_artifactsource
}
options {
buildDiscarder logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '', numToKeepStr: '10')
disableConcurrentBuilds()
}
....
We have a multibranch pipeline for our Jenkins job configuration. We have three branches: develop, master and feature branch. Developers want to run feature branch periodically every day. We are using same Jenkinsfile for several projects.
For running periodically, I have added below lines to my feature branch.
properties([[$class: 'BuildDiscarderProperty', strategy: [$class: 'LogRotator', artifactDaysToKeepStr: '10',
artifactNumToKeepStr: '10', daysToKeepStr: '10', numToKeepStr: '10']], gitLabConnection('GitLab'), pipelineTriggers([[$class: 'TimerTrigger', spec: '0 5,12 * * *']])])
The problem is that we have 5 projects and all of them are being executed at the same time as they are using same Jenkinsfile. Is there any way that I can run those projects one by one?
You should try prefixing the trigger with 'H/' spec: spec: 'H 5,12 * * *' instead of spec: '0 5,12 * * *'
Jenkins evenly distributes the jobs when multiple jobs have same pattern that trigger at same time.
Meaning of H prefix is explained here.
I have Jenkins LTS 2.60.2 on Windows Server 2016 and using these plugins:
Folders plugin (6.1.0)
Copy Artifact plugin (1.38.1)
Pipeline plugin (2.5) + all dependent pipeline sub-plugins
Various other dependent plugins...
See Pipeline to use artifacts from 2 projects associated by the same git branch name for more details about my setup, but to sum it up I have these items:
playground (a folder created with the Folders plugin to group all these following items)
frontend (multibranch pipeline)
backend (multibranch pipeline)
configure (pipeline with a parameter called BRANCH_NAME)
The frontend and backend git repos, both have a branch called master and one called release/2017.2.
The idea is to call the configure pipeline automatically after each successful build, passing the git branch name. Automatically triggering the configure pipeline works.
What doesn't work and I need your help to fix, is the step inside the configure pipeline to copy the artifacts from a multibranchPipeline/specificBranch.
If for the BRANCH_NAME parameter (or the upstream pipeline) is master it works. If BRANCH_NAME is: release/2017.2 I get this error:
ERROR: Unable to find project for artifact copy:
playground/frontend/release%2f2017.2 This may be due to incorrect project
name or permission settings; see help for project name in job
configuration. Finished: FAILURE
The configure pipeline looks like this:
node {
stage('Prepare') {
def projectname = "playground/frontend/" + "${BRANCH_NAME}".replace("/", "%2f")
step([$class: 'CopyArtifact', projectName: "${projectname}", selector: [$class: 'StatusBuildSelector', stable: false]])
}
stage('Archive') {
archiveArtifacts '**'
}
}
As you can see I already replace / with %2f (it's needed).
If I don't use the "playground" folder (all my pipelines as is, not inside a folder item), it works. If I use the folder and use the master branch, it works. It doesn't work if I use the folder and a branch name like 2017.2. What am I doing wrong? Can you help making it work? Of well if it's a bug (I searched in https://issues.jenkins-ci.org and found some bugs where a similar setup with folder doesn't work, but they have been fixed... so I really wonder...) in the copy artifact plugin, please file the bug and share the link here, so we can all monitor its progress...
Thank you.
I finally found the issue. The configure pipeline was failing to find a branch with a slash because the encoding was incorrect.
So, in my question, in the configure pipeline:
this (replace / with %2f) is wrong and generates the error:
def projectname = "playground/frontend/" + "${BRANCH_NAME}".replace("/", "%2f")
this is the proper way to encode the slash, and it works:
def projectname = "playground/frontend/" + URLEncoder.encode("${BRANCH_NAME}", "UTF-8").replace("+", "%20")
Credits to: http://www.pipegrep.se/copy-artifacts-from-jenkins-pipeline-jobs.html
UPDATE: actually, I investigated a bit further and added echo "${projectname}" just before step, with the previous and fixed projectname, and I noticed that the difference was %2f lowercase.
Uppercase, like this: %2F works:
def projectname = "playground/frontend/" + "${BRANCH_NAME}".replace("/", "%2F")
So, the fixed configure pipeline looks like this (I kept my replace function, which was enough for my case):
node {
stage('Prepare') {
def projectname = "playground/frontend/" + "${BRANCH_NAME}".replace("/", "%2F")
step([$class: 'CopyArtifact', projectName: "${projectname}", selector: [$class: 'StatusBuildSelector', stable: false]])
}
stage('Archive') {
archiveArtifacts '**'
}
}
I created a sample project to try and recreate what you were seeing, and I was able to do so, after a fashion, except that the build that I was having trouble on was master instead of release/2017.2. Eventually, I realized that I was doing the build job incorrectly from the frontend project, and it was giving me the same error as you because I hadn't ever completed a successful build of the frontend/master branch (I had completed a successful build of the release/2017.2 branch because I didn't have it triggering the configure build initially, so it didn't give me the same error once I did configure it to trigger the configure build).
What worked was changing the build job in the frontend Jenkinsfile to this:
build job: 'playground/configure', parameters: [[$class: 'StringParameterValue', name: 'BRANCH_NAME', value: env.BRANCH_NAME]], quietPeriod: 2, wait: false
Adding in the quietPeriod gives a couple seconds of quiet time between completing the previous job (I'm not certain that this is critical, but it seems like it might be a nice fail-safe, to try and make sure there's enough time for the build to complete), but the important part is the wait: false, which instructs Jenkins that this build shouldn't wait for the triggered build to complete. Once I changed that, the frontend/master branch completed successfully, and the configure build that it triggered also completed successfully.
Hopefully this helps. I was able to get both my master and release/2017.2 branches to build properly, so I don't believe there's any intrinsic problem with the / in the project name. You can see my simple Jenkinsfiles in the referenced repo, and I used the same pipeline script as you posted in your question.
In a multibranch pipeline job, I have configured builds (basic linting) to scan across branches for a jenkins file. I still have to perform this build manually however. What is the property I can set to enable polling of GitHub or, even better, triggered on new commits.
In general, I'm trying to find a way to learn how all GUI fields map to keys I can use in the properties(); method. There is no way for me to translate between GUI form field and script key-value option.
node('master') {
properties([
[$class: 'BuildDiscarderProperty', strategy: [$class: 'LogRotator', artifactDaysToKeepStr: '', artifactNumToKeepStr: '', daysToKeepStr: '', numToKeepStr: '10']],
[$class: 'BuildTriggerProperty???', strategy: 'Build when a change is pushed to GitHub???']
]);
...
}
Jenkins version 2.7
I'm trying to find a way to learn how all GUI fields map to keys I can use in the properties(); method.
If I got you correctly, the answer is:
Go to to your Pipeline project page
Find Pipeline Syntax link in the left-side menu and follow it
Find Snippet Generator link in the left-side menu and follow it
Select properties: Set job properties from Sample Step dropdown
Choose whatever you want and click Generate Groovy
Profit =)
This does not work (anymore?) as the only options are:
Build Triggers:
Build periodically
Build when another project is promoted
Build whenever a SNAPSHOT dependency is built
Monitor Docker Hub/Registry for image changes
Periodically if not otherwise run
Stash Pull Requests Builder
On a simple "pipeline" build, you can specify:
Build when a change is pushed to BitBucket
But MultiBranch doesn't have this option.
Background: We are looking for a solution on how to optimize our pipeline (former workflow).
Currently, we run quiet a few parallel deployments and tests which are spread on 2 builders, with 4 executors each.
The pipeline is triggered by a Git push, so subsequent pushes will trigger multiple builds. We have experimented with the stage concurrency: 1 option, which nicely blocks a step by a subsequent build, but will kick of when that specific stage is done.
Question(s):
I am not sure this is best practise, but It seems to me, it would be better to not execute the new build, until the previous one is done. (Reasoning from the fact that we have committed resources to it, and it should be allowed to finished, even if it's not the latest and greatest commit).
Q1: Is this even best practise?
Q2: how do we pre-empt the new triggert build, while still running the previous one? (I can imagine iterating through the builds of this job and stopping the new one...).
See the config of the first stage [1]
[1] first stage..
stage name: 'Checkout and build WAR'
node {
def mvnHome = tool 'Maven 3.2.x'
checkout([$class : 'GitSCM',
poll : true,
branches : [[name: '*/master']],
doGenerateSubmoduleConfigurations: false,
extensions : [[$class : 'RelativeTargetDirectory',
relativeTargetDir: 'checkout-directory']],
submoduleCfg : [],
userRemoteConfigs : [[url: 'https://some.repo/repo.git']]])
// Archive the cloned repo.
stash name: 'src', includes: 'checkout-directory/war/src/, checkout-directory/war/pom.xml'
// Run without tests, do the unit and integration tests in a separate stage.
sh "${mvnHome}/bin/mvn -f checkout-directory clean install -DskipTests"
// Archive the application build.
stash name: 'war', includes: 'checkout-directory/war/target/*.war'
}
From job's configuration you can set:
Execute concurrent builds if necessary
Quiet period
If set, a newly scheduled build waits for this many seconds before
actually being built. This is useful for:
Collapsing multiple CVS change notification e-mails into one (some CVS changelog e-mail generation scripts generate multiple e-mails in
quick succession when a commit spans across directories).
If your coding style is such that you commit one logical change in a few cvs/svn operations, then setting a longer quiet period would
prevent Jenkins from building it prematurely and reporting a failure.
Throttling builds. If your Jenkins installation is too busy with too many builds, setting a longer quiet period can reduce the number
of builds.
If not explicitly set at project-level, the system-wide default value
is used.
As for jenkins-pipeline DSL this article answer you question:
By default, Pipeline builds can run concurrently. The stage command
lets you mark certain sections of a build as being constrained by
limited concurrency (or, later, unconstrained). Newer builds are
always given priority when entering such a throttled stage; older
builds will simply exit early if they are preëmpted.
Using the Jobs configuration through properties seems to be the cleanest way to go.
See https://stackoverflow.com/a/43963315/1756183