Hi,
I looked at using the https://plugins.jenkins.io/nodepool-agents in our locally installed instance because I felt that it would provide a better management of some shared systems than the locked resources as well as making a few other items a bit easier such as being able to place holds on machines so that they would be held after the current build for a developer to do some investigation before being returned to the pool of workers and a few other items. However after some testing I discovered that it currently doesn't support FreeStyle jobs: https://github.com/jenkinsci/nodepool-agents-plugin/blob/9275725dc5318c268274ef852dbde8d680046f24/src/main/java/com/rackspace/jenkins_nodepool/NodePoolQueueListener.java#L85 So I'd like to spend some time and add support for Freestyle jobs (even if only locally for to allow us to solve one problem first before tackling a larger migration issue). Looking around the code I think the main issue is in establishing if the node is the correct one for the job that was queued: https://github.com/jenkinsci/nodepool-agents-plugin/blob/226ad8bd2bb9c44ab670eb9bc6ed2ab33b63fb3a/src/main/java/com/rackspace/jenkins_nodepool/NodePoolQueueTaskDispatcher.java#L63-L67 I'm trying to understand if it is sufficient to simply use the task itself to determine if the node is the correct one for he job? That is when the nodepooljob is created using https://github.com/jenkinsci/nodepool-agents-plugin/blob/9275725dc5318c268274ef852dbde8d680046f24/src/main/java/com/rackspace/jenkins_nodepool/NodePoolJob.java#L19 if it is sufficient to use the task passed in to establish if it is the same job? Or is it a case that you can only do this if after first checking if it's a WorkflowRun class and only using the task if it's a FreeStyle job as pipeline jobs can have multiple nodes associated and thus you need to establish if the NodepoolJob has been created for the correct part of the pipeline for this execution as it may still be the same task queued, or indeed it may be a different task that is queued due to resuming of a pipeline? If it's not possible to use the task id, is there another way to ensure the correct task is assigned to the correct node created by nodepool? Is it as simple as making use of https://javadoc.jenkins-ci.org/hudson/model/Node.html#canTake-hudson.model.Queue.BuildableItem- as the NodepoolSlave is a subclass of https://javadoc.jenkins-ci.org/hudson/model/Slave.html which is a subclass of Node and follow the same idea from the vsphere cloud plugin https://github.com/jenkinsci/vsphere-cloud-plugin/blob/8e39d601d5c96be819fe22dd5ecd68bd481cd57e/src/main/java/org/jenkinsci/plugins/vSphereCloudSlave.java#L266 I'm assuming that for the remaining cases where the code is using the WorkflowRun object cast to a Run instance and returned with calls to the NodepoolJob.getRun() at the following places https://github.com/jenkinsci/nodepool-agents-plugin/search?q=getRun&unscoped_q=getRun that the general solution would be implement support for determing 'isBuilding()', 'getDisplayName' & 'getUrl' in NodepoolJob and have it query the correct API on the stored task to return the correct information in each case? Or is it a case that for historical runs that the task would disappear and while the Run object remains constant. So would NodepoolJob need to retrieve the correct run once the FreeStyle job has been successfully started as once it's building there is a run to reference, and that will subsequently provide sufficient information to satisfy those requests? Thanks for any info on adapting this plugin for additional usage, I understand as the questions are likely to be specific to how the plugin behaves it might require the plugin authors to answer, and I'm also still also kind of flailing around in the dark a bit with it at the moment. Hope to get a chance to experiment with some of my thoughts above towards the end of next week, so any pointers towards plugins or code that have/has implemented this sort of compatibility within queues for both pipeline and other types of jobs would be greatly appreciated. Regards, Darragh -- 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/15ec865e-d6fa-4680-bf0f-9945d1388baa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
