Hi everyone ![]()
I’ve been exploring the Jenkins plugin ecosystem recently, especially while going through plugins like email-ext and others that integrate with external systems.
While studying these, I’ve been trying to better understand how design boundaries are typically handled in Jenkins plugins.
In general, when a plugin depends on external systems (such as credential providers or third-party APIs), is the preferred approach to keep the plugin as a thin consumer and delegate lifecycle concerns (like token management, retries, etc.) entirely to the external component?
Or are there scenarios where plugins are expected to handle certain responsibilities themselves (for example, retry logic, fallback handling, or partial lifecycle control)?
I’m trying to align my understanding with established patterns used across plugins like Git, Kubernetes, etc., so that I can design things in a way that fits naturally into the Jenkins ecosystem.
Would really appreciate any general guidance or references to similar implementations. (Not specific to any ongoing issue — just trying to learn the design philosophy better.)
Thanks in advance!