So far I can configure Jenkins logRotator to keep the last X builds or keep the builds for the last X days.
I’d like to keep builds based on some condition that is evaluated within the pipeline. So normally I’d like to keep a build for 7 days, but if condition1 I’d like to keep it for a month and if condition2 I’d like to keep it for 6 months.
How could I achieve that?
I think you’d need to make your own plugin. build-discarder-plugin/DefaultGlobalBuildDiscarderStrategy.java at 37ae6e024e72d0a552b479a3066f8b06552851c6 · jenkinsci/build-discarder-plugin · GitHub is a decent example. If you wanted the logic to be controlled by the build itself. I would recommend either finding a plugin that adds build actions to a build, or make your own pipeline step that adds build actions (essentially get your build object, then build.addAction(new MyAction())
more details can be provided, but i don’t think there’s anything out of the box that can do it. The default discarder strategy keeps the last succesful build + whatever your rules are, so if you you have your strategy to only keep 5 builds. If you have 1 good build, then 20 bad ones. It would keep that good one, and 4 or 5 most recent bad ones. Usually thats the strategy most people want.
Thank you for the quick response.
I was considering my own build discarder, and while checking out extension points it struck me that this build discarder would run when the build of the job would actually be finished. So the result of processing condition1 and condition2 would have to be stored somehow somewhere.
How can a pipeline store an additional property such that a build discarder can actually retrieve the value and action?
I am about to goto bed so i can’t dig into it. I swear there was a plugin that added actions. I tried both metadata and action search but didn’t see anything.
Honestly making a pipeline step is dead easy. My lighthouse plugin is a dead simple example - lighthouse-report-plugin/LighthouseReportStep.java at master · jenkinsci/lighthouse-report-plugin · GitHub - read some data, then store it to the build. You can then later look at build.getAction(ClassName.class) or something
I was not aware I should lookout for actions.
So now it seems to me I’d add my own action that would hold information about the two conditions, and in that way the information would be persisted in the build’s build.xml file.
When the build discarder is run, my customized strategy could then retrieve the information from the build/action and decide accordingly.
This sounds like a plan. 
Yea someone with more plugin Dev experience may give you other methods but that’s the way id do it
That’s strange. I seem to fail setting up my own maven project to create an action. And cloning and compiling yours also delivers an error.
Running InjectedTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.339 s <<< FAILURE! - in InjectedTest
InjectedTest.initializationError Time elapsed: 0.003 s <<< ERROR!
java.lang.ExceptionInInitializerError
...
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field private final java.util.Comparator java.util.TreeMap.comparator accessible: module java.base does not "opens java.util" to unnamed module @4434095f
without more of the output, i assume your not compiling with jdk 8. 11 should work, newer than that probably won’t work.
Thank you for taking a look. Actually in the meantime I tried different things and finally went from scratch through the Jenkins plugin development tutorials. It is a bit strange to know that current versions of Jenkins prefer Java 11 yet the docs often refer to 8. On the way I switched from Java 16 to Java 11 and found my (Netbeans-provided) maven was too old, and I had updated a lot of version references from the POM.
Finally I have now an action that stores some data in the jenkins run and a builddiscarder that reads that data from the run.
Still experimenting with freestyle projects, scripted and declarative pipelines to see how all this behaves but currently it is looking good.
Do you have any references to docs talking about Java 8? We tried to update the website to refer to Java 11 wherever we found it.
Check the ‘Download and install a JDK’ section on
Also, when creating the project from the archetype, inside the POM it is required to have
<properties>
<java.level>8</java.level>
</properties>
as well as
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>8</source>
<target>8</target>
</configuration>
</plugin>`
despite the fact that I configured maven to run on Java 11.
thanks that tutorial needs updating
As far as I understand it, those settings in the archetype are correct and need to remain that way until we drop support for Java 8 runtimes.
We configure Jenkins compilation to generate Java 8 byte code even when compiling with Java 11 so that plugin developers can use Java 11 and still run their plugins on Jenkins installations that use Java 8.
Indeed backwards compatibility is a good point.
Maybe it can be mentioned in the tutorial so it is easier to understand.
Another thing is that I disregarded compatibility for the new plugin I created but compilation would fail. Thus currently it is not even possible to go higher.
@timja very kindly revised the developer tutorial to better describe current state. See the revised tutorial at Plugin Tutorial
The Build History Manager plugin allows for some more complicated scenarios in which to delete a build (and a bit more control over what to delete, whether the build as a whole or just its artifacts). I don’t know if this does what you’re looking for?