Kahsuke, The fast turnaround on the fix is much appreciated.
Jesse, Thanks for pursuing this even further. I sat this aside to work on
some other aspects of the project and oddly enough, just before checking
back in on this thread this evening, I ran smack into the method not
available problem on another piece of code where again I was trying to call
node() in this case from within a formally declared class. Which leads me
to a follow-on problem:
First let me say that I am a long time coder but very new to groovy
(learning it just to be able to use this workflow stuff) so I completely
get why I can't call these methods from within a class now that I see the
error. But I have a few questions that may be more properly groovy
questions but I am a little unclear where groovy leaves of and workflow
picks up here so I hope you will humor me.
I presume that when using scripts as classes, each class is basically a
singleton with a lifespan equalling that of the execution of the workflow,
with the caveat that all classes get serialized by Jenkins-workflow's
state-saving mechanism that allows for resuming inflight workflows as well
as allows for the state to be created/managed on the master node yet
replicated to slave nodes for execution. I am curious if there is any
documentation around the implications and limitation that this need to be
serializable places on classes. For example, in my most recent effort,
realizing that the node() method was not available, I tried to pass "this"
into the class in order to try calling _this.node(). That got me a
serialization error right quick, which makes perfect sense. What else might
one do that would cause a class/script to not be serializable?
Which gets me back to my current dilemma. Again this may be more of a
groovy question but at present, I am again trying to use a formally
declared class within a script so that I can subclass it and override
certain methods as per the Template design pattern.
My original code looked like this:
*file Job.groovy:*
public start(nodeType, stashProject, stashRepo) {
node(nodeType) {
checkout changelog: true, poll: true, scm: [
$class: 'GitSCM',
branches: [[name: '*/master']],
doGenerateSubmoduleConfigurations: false,
submoduleCfg: [],
userRemoteConfigs: [[
credentialsId: 'c39766d4-52c3-42ed-a1f0-fdfd3491a545',
url: "ssh://git@stash:7999/${stashProject}/${stashRepo}.git"
]]
]
load './build.groovy'
}
But now I am trying to do this:
class Job {
def _nodeType, _stashProject, _stashRepo
public Job(nodeType, stashProject, stashRepo){
_nodeType = nodeType
_stashProject = stashProject
_stashRepo = stashRepo
}
public start() {
node(_nodeType) {
beforeCheckout()
checkout changelog: true, poll: true, scm: [
$class: 'GitSCM',
branches: [[name: '*/master']],
doGenerateSubmoduleConfigurations: false,
submoduleCfg: [],
userRemoteConfigs: [[
credentialsId: 'c39766d4-52c3-42ed-a1f0-fdfd3491a545',
url:
"ssh://git@stash:7999/${_stashProject}/${_stashRepo}.git"
]]
]
afterCheckout()
load './build.groovy'
afterRun()
}
}
def beforeCheckout(){
//Virtual method
}
def afterCheckout(){
//Virtual method
}
def afterRun(){
//Virtual method
}
}
The immediate impetus for this, is the need to conditionally do some
customization of the .kitchen.yml file in the afterCheckout() method of my
subclass depending on what nodeType it is running on (vagrant vs docker).
Perhaps I am trying to do things too much in my traditional OO GOF design
patterns way of thinking about polymorphism. So if there is a better
approach to trying to solve this sort of problem in the context of Jenkins
workflow and groovy, I am open too it.
Bottom line though, my requirement is to create some standardized
workflows, of which this Job.groovy and Cookbook.groovy are very simple
examples, which are extensible but only at specific points.
I hope that makes sense. Any advice even if only to point me to some
examples or docs to read would be greatly appreciated.
--Regards,
Ken
On Wednesday, December 17, 2014 8:10:38 AM UTC-5, Jesse Glick wrote:
>
> With that change I get an error
>
> > No signature of method: chef.Cookbook.sh() is applicable for argument
> types…
>
> meaning that the DSL methods are not accessible from your class. That is
> because when you define a standalone class, it has no access to the main
> ‘groovy.lang.Script’, on which DSL methods (and some miscellaneous stuff
> like ‘env’) are defined.
>
> If I delete the ‘class Cookbook {}’ wrapper then it works fine—once I wrap
> the ‘sh’ sequence of both functions in ‘node {}’.
>
> Basically, you did not need to rewrite the class structure to add the
> ‘_validated’ variable.
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/863c5a1d-8d48-461e-8f66-6c52cac63d09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
