Details
-
Improvement
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
Description
As a Jenkins administrator, I'd like to be able to set the logrotator on the jobs on my instance. I'd like this value to be "read-only" on the jobs, so the users of my instance cannot change it. This way, I'm sure that the space usage of the builds is handled correctly.
Today, it is possible to use the configuration slicing plugin to "re-apply" this logrotator configuration on the jobs from time to time. However, this task is time-consuming and having a way to prevent my users to change this value on the job configuration would be a more reliable solution.
Another solution would be to have the value set globally, and accept the users to change it on the job level, but the global value would act as a default value at the job creation time.
Attachments
Activity
Adrien Lecharpentier
created issue -
Adrien Lecharpentier
added a comment - even with configuration-slicing, I need to reapply the configuration from time to time and if I don't for a long period of time, users can set the logrotation values and use all the space of the JENKINS_HOME.
Also, from their point of view, they have a part of their jobs configuration that change without them knowing why (well, they do know but they disagree). So having this configuration "disabled" when set globally would make them understand they cannot modify it.
Adrien Lecharpentier
added a comment - even with configuration-slicing, I need to reapply the configuration from time to time and if I don't for a long period of time, users can set the logrotation values and use all the space of the JENKINS_HOME.
Also, from their point of view, they have a part of their jobs configuration that change without them knowing why (well, they do know but they disagree). So having this configuration "disabled" when set globally would make them understand they cannot modify it. | Field | Original Value | New Value |
|---|---|---|
| Component/s | plugin-proposals [ 15491 ] | |
| Component/s | core [ 15593 ] |
Probably better off separate from core. This looks a lot like something that needs to implement various org dependent strategies.
Adrien Lecharpentier
added a comment - danielbeck I guess it could also be a per-folder configuration but a global configuration would still be nice. It would also be something less to worry about when creating new MultiBranch Pipeline on the instance.
Adrien Lecharpentier
added a comment - danielbeck I guess it could also be a per-folder configuration but a global configuration would still be nice. It would also be something less to worry about when creating new MultiBranch Pipeline on the instance. Good point. I know rtyler has been complaining about lack of pipeline management, perhaps this is a duplicate of something he filed?
It would be nice