Customize node creation from within a pipeline definition

37 views
Skip to first unread message

Jonathan Ballet

unread,
Jul 24, 2017, 10:00:08 AM7/24/17
to Jenkins Developers
Hi,

I'm looking how possible it would be to allow the customization of a new Jenkins worker based on the definition of a node within a Jenkinsfile file.

Considering a node provisioner which is able to create new nodes from Docker images for example, I would like to be able to do something similar to this:

node("my-node-provisioner", docker_image="internal/jenkins-worker:v12", memory_limit="4GB") {
   
// my steps here
}

That would allow the developers to customize the context in which their job is running in, within the available node provisioner possibilities, while keeping all the versioning on how the job needs to be executed within the Jenkinsfile of the project.

Some more context about what I'd like to do: I'm using the Nomad plugin to schedule our Jenkins jobs in the pool of machines we are managing via the Nomad scheduler. Nodes ("slave templates" in the Nomad plugin terminology) can be configured from Jenkins main configuration screen, but it's not that convenient. See my RFC here for even more details: https://github.com/jenkinsci/nomad-plugin/issues/20

It's my first time digging inside Jenkins extensions and I don't really know where I should start to look for. Any pointers would be appreciated! I'm especially interested to know if it's something which has been done before, and if it's desirable or not.

Thanks!

 Jonathan

Jesse Glick

unread,
Jul 25, 2017, 8:54:56 AM7/25/17
to Jenkins Dev
The argument to `node` is a label expression, and the `Cloud` SPI
allows interpretation of labels, so you could probably write something
like

node('nomad && nomaddocker:internal/jenkins-worker:v12 &&
nomadmemlimit:4Gb') {…}

Carlos Sanchez

unread,
Jul 25, 2017, 9:05:01 AM7/25/17
to Jenkins Dev

The kubernetes plugin does that, so you can check for inspiration
https://github.com/jenkinsci/kubernetes-plugin/blob/master/README.md#pipeline-support

It would be nice to have a common syntax across container provisioners


--
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/CANfRfr166Uu4%2BjQn%2By5_Yy8%3DzuvBor_ADLqidr0K_0%2BzyWG7Tg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Jonathan Ballet

unread,
Jul 26, 2017, 4:54:17 AM7/26/17
to Jenkins Developers

Right, I see exactly where it's being done. It looks a bit hackish from the outside, but that could indeed be a possible solution :)

Do you know other plugins which are doing something like this? I'd like to know which kind of syntax or what uses they are making of these labels!

Thanks for the reply,

 Jonathan

Jonathan Ballet

unread,
Jul 26, 2017, 7:50:02 AM7/26/17
to Jenkins Developers
Le mardi 25 juillet 2017 15:05:01 UTC+2, Carlos Sanchez a écrit :

The kubernetes plugin does that, so you can check for inspiration
https://github.com/jenkinsci/kubernetes-plugin/blob/master/README.md#pipeline-support

It would be nice to have a common syntax across container provisioners


 That really looks like what I wanted to implement! I didn't thought of wrapping the node() call inside something which would define the environment to build in, that's definitively interesting, I'll try to play with that I guess.... :)

As for the common syntax, I'm just looking now at what you guys did for Kubernetes, I really like that example: https://github.com/jenkinsci/kubernetes-plugin/blob/master/examples/declarative.groovy but I haven't done any Jenkins plugin before, so there's still lot of work coming in :)

Jesse Glick

unread,
Jul 26, 2017, 8:17:05 AM7/26/17
to Jenkins Dev
On Tue, Jul 25, 2017 at 9:04 AM, Carlos Sanchez <car...@apache.org> wrote:
> The kubernetes plugin does that

I think it is doing something different than what I suggested; useful
only if you need to orchestrate several containers. Would be overkill
for the use case Jonathan was discussing.
Reply all
Reply to author
Forward
0 new messages