Added this to my research doc to look into. Thing I like about the plugin's new job type is it's locked into our development cycle. If it's an "in Jenkins" config setup the risk of people making "from the hip" changes is rather high. That said ... guess that's what the config history plugin is for. Just need to layout the pros and cons right now.
In some case no but in some... Yes, they need access to the "configuation" screen. Which is why I'm looking at options. One of the current solutions is an approval system around an install.pipeline script, with their custom programming. Then all 1000+ developers code goes through a single job. But that solution gets scrutiny so seeing what's possible. Just for completeness is there a doc/tutorial on the "not recommend creating a new job type" somewhere? On Friday, August 7, 2020 at 9:52:21 AM UTC-4, Jesse Glick wrote: > > On Thu, Aug 6, 2020 at 10:07 PM Michael Carter > <[email protected] <javascript:>> wrote: > > what I'm investigating is to create is a few "secure" templates. That > is create a job type where the "builder" and/or "publishers" are basically > locked in and the people using them have only a few of the "freestyle" > options. > > As Gavin alluded to, this is precisely the use case for the CloudBees > CI template feature: GUI configuration of jobs with only a limited > number of options, using a sort of RAD builder for Jenkins form > controls. (This relies on a custom *New Item* type and custom > *Configure* screen, _not_ a custom job type internally.) That feature > is usually combined with another that allows for the *New Item* screen > on a given folder to be locked down to custom selections, and with > folder-scoped role-based access control. > > Various OSS plugins and systems exist in this space, with more of a > focus (as far as I am aware) on eliminating the need for duplication > rather than literally blocking users from doing something else. > > If you are not tied to GUI configuration, it may suffice to simply > give users only read access to Jenkins (plus *Job/Build* as needed) > and define all job behaviors via code, which can be controlled at the > repository permission level and through programmatic validation. The > `job-dsl` plugin is often used for this purpose. Another option is to > use multibranch Pipeline, perhaps even an organization folder, with > one of the plugins offering a special recognizer rather than the > default of reading `Jenkinsfile`; there are a couple of OSS plugins > for this, and CloudBees CI also has a version. > > I really would not recommend creating a new job type. It is a major > endeavour and poses a lot of interoperability issues. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d1441fa5-edf3-49b6-b3a4-e0d600084c01o%40googlegroups.com.
