I'm trying to use Configuration Slicing plugin to discard build and artifacts for a lot of different jobs in jenkins. However, I'm not exactly sure on how to configure it.
Discard Old Builds Slicer - Days to keep artifacts
The Item Names I understand would be the list of jobs we would like to discard the builds for. The configured value section has disabled by default. Should I make it enabled?
Where should I specify the #Days to Keep the artifacts? Is it in the dialogue box below?
Can anyone please provide examples on how to configure this? I'm trying to configure this in a live environment. I would like to be sure before making any changes.
Tia,
Lakshmi
I hope this helps.
Try to fill in the number of days for which you want to see the older builds where it says (Disabled) by default. Fill in the name of the jobs you want to apply the rule to under Item Names. Then Save.
For the changes to reflect you need to run the jobs once. This worked for me.
You can also use the Discard Old Builds Slicer - Max # of builds to keep with artifacts if you want to restrict to a certain number of builds. Configure it the same way.
Please see the screenshot attached.
Screenshot of Discard Old Builds Slicer - Days to keep artifacts
Related
As is good practise, I've got Jenkins set up at work to automatically build everything for continuous integration, pulling files from our Git repositories. On our development branches, builds get kicked off automatically whenever anyone commits a change. When we want to do formal testing, we pull the build from Jenkins and use that; and when we want to sign off a change request, we quote the Jenkins build number where the change went in. So far, so good.
The problem we have is that builds are a significant size. For our SDK, we have to build across multiple platforms so that we can check it works on all of them. At maybe 50MB per build, this starts to mount up! Short term I can keep asking IT to give me more storage space, but longer term I'd like a more strategic solution
The obvious answer in Jenkins is to set up deletion rules, whether deleting after some time or after some number of builds. The problem then though is that if we delete that older development build, we lose the traceability of what we tested. I'm sure most engineers at one time or another have had to do a binary chop through older builds to find an obscure bug/regression which was only spotted some time later. For me, it is unacceptable to lose that history.
The important feature of build history though is not the binary build artifacts, but the build log recording what Git commits (or anything else; toolchain versions for example) went into each build. That's what lets us go back to investigate older builds and recreate them if required. The build log is relatively small (and highly compressible, being a text file). We do still need to keep build artifacts for recent builds though, so that testers can use them. So I'm thinking a better alternative would be to preserve the build log in Jenkins for all builds, but to have Jenkins automatically delete build artifacts after some time.
Does anyone know of a way in Jenkins (perhaps a plugin?) which would let us automatically delete/archive build artifacts from older builds, but still keep the build details and log for those builds? I'm happy to do a Jenkins upgrade if necessary to get this feature. And of course this needs to be only for selected development build jobs - all release build jobs need their build artifacts to be preserved forever, as do any builds which have the "keep forever" button ticked.
If it's absolutely necessary, I could set up a separate cron job to do this on the Jenkins file area. That's a nasty hack though, and I suspect it's likely to cause some issues with Jenkins, so I'd rather not do something that brute-force if there's a better alternative.
I think you need this option in your jenkinsfile
buildDiscarder(logRotator(artifactNumToKeepStr: '10'))
artifactNumToKeepStr: This number of builds have their artifacts kept.
I don't understand what Promoted build really is and how it works. Can someone please explain to me like to a 10 years old kid. If you can provide some sample examples would help me a lot.
Thanks
In a typical software developing organization with CI system, there are 10's or 100's of continuous builds daily. Only one of those builds (usually the latest stable) is selected and "promoted" to be a Release Candidate (RC), which goes to the next quality gate - usually the QA department. Then, they select one of those RC's (others are dropped) and again, "promote" it to the next level - either to staging environment, validation etc. Then, finally... one of these builds is again "promoted" to be an official release.
Why is that important?
Visibility: You would want to distinguish many "regular", continuous builds from few, selected "RC" builds.
Retention: If you commit often (which is the best practice), you will likely get lot of daily builds, and would like to implement a retention policy (e.g. only keep last 100 builds or only builds from the last 7 days). You will then want to make sure promoted builds (RCs) are locked against retention. This is mostly important if you deploy binaries to customers, and may need the exact binary to reproduce an escaping bug in the future (though you still have the source code in the repository, I've seen cases where escaping bugs relate to the build process rather than the source code - due to rapid changes to the build process, or time-of-build sensitive data like digital signatures).
Permissions: you may want to prevent access to builds with "half baked" features from non-developers.
Binary Repositories: you may want to publish only meaningful builds to an external binary repository.
Builds in Jenkins can be "promoted" either manually or automatically, using plugins like Promoted Builds Plugin. You can also create your entire "promotion" workflow using pipeline scripts. Here's an example:
a "Continuous" job that polls SCM and builds on every change. It has a retention policy to keep only the last 50 builds. Access is restricted only to developers;
a "Release Candidates" job that copies artifacts from a manually selected build (using parameters). Access is allowed to QA testers;
a "Releases" jobs that copies artifacts from a manually selected RC. Access is allowed to the entire organization. Binaries are released to external/public repository.
I hope this answers your question :-)
I have a job to maven build our project, we now have one job per release version. As the number of releases grows, there are too many jobs and very hard to find the one we need.
I wonder if there is a way to launch the same job with different parameters? The problem is one job only has one workspace, so I'm not sure if it's possible?
Thanks.
Use This build is Parameterized option to build the jobs. Using this you can build the same job for different parameters. You will be asked to enter the parameter before building or you can also give a default parameter and you can have multiple parameters.
It is good the archive the artifacts which you need later.
You can also have the option keep build forever, this will keep the builds permanently Ir-respective of the number of builds to keep.
To use above option you should enable Discard old build option.
You can also link your repository directly to Jenkins which will trigger the job whenever a new commit is made to master or a new tag is created.
I have a large and time-consuming multi-configuration build, and once in a while I want to re-trigger only one of the configurations. How can I easily do that? I'd like it to still be easy to see that that all configurations have passed.
There is the Matrix Reloaded plugin
This gives you an interactive way of rerunning combinations
On all Matrix builds that has run while the plugin was installed there
will be a Matrix reloaded link. Click this, and it will take you to a
dialog, where you can check-mark the configurations that should be
build again. Nothing is checked by default, but the check-marks you
set will be cascaded as default settings, if applicable, to any
down-stream jobs triggered by the re-run.
I'm trying to tweak some options in my jenkins configuration, which is causing many builds to fail. I'd prefer to not keep these failures around in the build history, since they're not technically failures of the repository. In the past, I've just deleted the build after looking at the log, but this is a little tedious.
Is there a way to start a build with an option to not record the result of the build permanently?
Perhaps there's a URL that can be used to trigger a debugging build, somethign like:
JENKINS_URL/job/JOBNAME/build?DEBUGGING
You can set the "discard old builds" option in your job to only keep 1 build. If you have older builds you want to keep, you can give them the "keep this build forever" property. If you have a large number of jobs to work with, you can use the Configuration Slicing plugin to modify the Max # of builds to keep.