| Preface This is a major feature with potentially prohibitive core engineering implications, but I am unable to determine the scope of those implications myself. If you are a core jenkins contributor and you see any merit in this feature request, please comment about the feasibility. Also of note, I'm specifically requesting this as a "core feature" because I am not confident it's possible (or a good idea) to implement it as a Jenkins plugin. I could be wrong about this, in which case a valid vote might be "this could/should be implemented as a plugin". If it's clearly unsupportable in any context, and/or nobody feels it should move forward, this request should be closed sooner rather than later. All the more reason I request feedback from core team. Synopsis There are many native Jenkins events related to a job which occur frequently but are not part of the jobs "execution" logic, so they are not natively accessible or actionable for users without a custom plugin for the dedicated purpose. This is because "pipelines" are executed from the known list of "trigger" event types, which is a small subset of "jenkins events". Thus, "job execution" is limited to the context of "trigger events". In theory, a plugin could be written to turn any particular "jenkins event" into a new custom "trigger" type. However, plugins are overkill for many enterprise needs, which are often one-off, short term, or just very custom. Also, the scope of creating/supporting/maintaining a Jenkins plugin is prohibitive for many non-expert Jenkins users/administrators, many of whom are not Java developers. Much like Jenkins Shared Libraries provide an easier entrypoint for adding custom programming facilities to Jenkins jobs when compared to writing a whole plugin, this ticket suggests providing a simpler entrypoint for interacting with the broader event system than writing a whole plugin. There are some specific examples below, but it is a very general feature. Example Events
- A job is disabled or re-enabled
- The job configuration is changed in the GUI or via API
- The job is triggered by any of the causes
- Job pause/resume
- Jobs enter or leave a job queue
There are of course, countless others when plugins get involved. Some Concrete Use Cases which are effectively impossible today:
- Filtering trigger events in a consuming job such that a "build" is never created in the queue/job log
- Automatically force a rebuild if someone modifies the job in the Jenkins GUI
Prior Art
https://plugins.jenkins.io/groovy-events-listener-plugin/
This plugin is novel, but institutes a global hooking system with awareness of a limited number of events. This feature request is similar in that it also aims to implement "hooking capability". However, this feature request is different in the following ways:
- It suggests the ability to define "hooks" in the jenkinsfile / jenkins shared library
- It suggests the ability to define "hooks" on far more event types
- It suggests supporting declarative pipelines from the start
Pipeline Syntax Example
One could imagine something like the following, although there might be other syntax paradigms that make more sense, like some sort of pub/sub declaration and/or some query notation. This example is pseudocode to cancel queued items when there are already 5 or more items in the queue.
pipeline{
events{
event("hudson.model.Queue"){
when{
allOf {
eventName "WaitingItem.onEnterWaiting"
expression { this.queue.getItems().size > 4 }
}
action {
this.item.cancel
}
}
}
}
}
Summary Having not authored a plugin from scratch before, I don't know what I don't know with regard to scope. If all the event plumbing and extension points exist in Jenkins, it could be a matter of "implementing this feature". If not, the scope could be considerably large enough to render this feature "currently infeasible". Again, feedback welcome. |
