New Job/Project Type

[Michael Carter]

Was trying to reverse engineer the Ivy/Maven project to figure out how to create my own type of job.

Is there a basic Hello World type template I could grab and expand off of?

[Gavin Mogan]

I would take a look at FreeStyleProject. You'd need @Extension and some templates at the very least.

https://javadoc.jenkins.io/hudson/model/FreeStyleProject.html

Maven project type is pretty much abandoned because of how integrated it was with the java version your running jenkins with.

But why would you want a new job type, does pipeline or multibranch pipeline not work for you?

On Thu, Aug 6, 2020 at 3:09 PM Michael Carter <mikeyca...@gmail.com> wrote:

Was trying to reverse engineer the Ivy/Maven project to figure out how to create my own type of job.

Is there a basic Hello World type template I could grab and expand off of?

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0e8388c7-751f-4c23-96d8-21efcfabf428o%40googlegroups.com.

[Michael Carter]

Guess you could say 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.

Partly on one server as a way to open up people having some control over their job without a free run on the system... other side of this is a "turn-key" solution for those who keep saying to me, "It's unreasonble for me to expect developers to know how to write scripts"

That last one these people tend to get overwhelmed with too many options so want to limit the options to only the things they need to choose from.

At the moment just fact finding to see what I can and can't do.  When I noticed the Ivy/Maven templates had everything embedded with options turned off... I started looking at them as a template to make my own.

On Thursday, August 6, 2020 at 6:54:24 PM UTC-4, Gavin Mogan wrote:

I would take a look at FreeStyleProject. You'd need @Extension and some templates at the very least.

https://javadoc.jenkins.io/hudson/model/FreeStyleProject.html

Maven project type is pretty much abandoned because of how integrated it was with the java version your running jenkins with.

But why would you want a new job type, does pipeline or multibranch pipeline not work for you?

On Thu, Aug 6, 2020 at 3:09 PM Michael Carter <mikeyca...@gmail.com> wrote:

Was trying to reverse engineer the Ivy/Maven project to figure out how to create my own type of job.

Is there a basic Hello World type template I could grab and expand off of?

--
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 jenkin...@googlegroups.com.

[Gavin Mogan]

Cloudbees has some templating type products out there.

Honestly I think every and all build should just be sh("./runs.h") or sh("make")

I can't help more than that though, i think freestyle, while huge, might be a good place to look at how its done.

Gavin

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/33e8d7c0-9f19-4559-aab2-d9ce7d6fddd2o%40googlegroups.com.

[Jesse Glick]

On Thu, Aug 6, 2020 at 10:07 PM Michael Carter
<mikeyca...@gmail.com> 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.

[Michael Carter]

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?