[22:29:12] <bitwiseman> jglick: is there a way to tell a shared library to load from a folder other than root inside a repo?
[22:29:36] <jglick> bitwiseman: no
[22:29:53] <jglick> (and no plans to support that either)
[22:31:41] <bitwiseman> jglick: I'll see if I can change your mind on that.  :)  JIRA soon.
[22:33:19] <bitwiseman> jglick: out of curiosity, would it be an hard/messy to add it?
[22:33:51] <jglick> bitwiseman: bad for performance, the lib must be a small checkout since we do it for every build
[22:35:13] <bitwiseman> jglick: ah, sure, but I'm not talking about large repos, just the aspect of loading from a subdirectory.
[22:35:30] <jglick> bitwiseman: so what is your goal then?
[22:38:24] <bitwiseman> jglick: just go with me for a second.  You currently always load from repo root directory, how hard would  it be to allow a library to be loaded from a subdirectory instead?
[22:39:01] <jglick> Probably easy.
[22:39:24] <jglick> (I mean, along with the hundreds of probably more important easy things.)
[22:40:23] <bitwiseman> jglick: sure.   I have an idea about how to solve the method definition JIRA.
[22:42:09] <jglick> bitwiseman: JENKINS-41396?!
[22:42:11] <jenkins-admin> JENKINS-41396:Declarative: Add method definition section to root pipeline block (Reopened) https://issues.jenkins-ci.org/browse/JENKINS-41396
[22:42:52] <jglick> bitwiseman: what on earth does subdirs in external libraries have to do with that?
[22:45:35] <bitwiseman> jglick: because the don't have to be "external".   A Library could just as well loaded from the local repository, but it would need to be loaded from a subdir instead of root to be safe and not muddy the root dir.
[22:48:05] <jglick> bitwiseman: no this makes no sense
[22:48:13] <jglick> totally different system
[22:48:18] <jglick> just use `loadFile`
[22:48:42] <jglick> or `evaluate`
[22:51:31] <bitwiseman> In declarative?
[22:52:25] <jglick> bitwiseman: inside `pipeline-model-definition`
[22:53:15] <jglick> Stop thinking about `workflow-cps-global-lib`, you are barking up the wrong tree there.
[22:53:16] <bitwiseman> `pipeline-model-definition` = Declarative Pipeline, right?
[22:54:56] <jglick> bitwiseman: yes
[22:57:08] <bitwiseman> jglick: okay, well, I'll finish filling out the JIRA.  Seemed like a pretty cool idea to me.  Basically reusing the existing functionality to solve a swath of requests all at once.
[22:58:00] <jglick> bitwiseman: libraries are for sharing, pointless to use it within the same repo
[22:58:06] <jglick> buys you nothing
[23:00:31] <bitwiseman> jglick: From a user perspective, I feel like it buys me almost exactly what I was talking about in JENKINS-41396.
[23:00:32] <jenkins-admin> JENKINS-41396:Declarative: Add method definition section to root pipeline block (Reopened) https://issues.jenkins-ci.org/browse/JENKINS-41396
[23:04:45] <bitwiseman> Combine with an option on  LibraryStep to load from local repo.   As a user, I get the concept of a library and the structure and behavior of library is defined and documented.
[23:07:31] <jglick> bitwiseman: total overkill. `pipeline-model-definition` can easily add such a feature using `readTrusted`. It need not and should not use `workflow-cps-global-lib`.
[23:11:00] <bitwiseman> jglick: I guess this is another case of me knowing just enough to get things all wrong.  :|
[23:15:45] <jglick> bitwiseman: the raison d’être of `workflow-cps-global-lib` was to avoid issues with the original idiom of grabbing a separate `node` to `checkout` stuff and then `loadFile` it before exiting the block and resuming. But if you have stuff in the same repo you can simply `evaluate` the `readTrusted`. Or even more simply if it is already inside `Jenkinsfile`
[23:15:45] <jglick> anyway, just call it without further ado.
[23:18:34] <rtyler> jglick: so I'm understanding correctly, does readTrusted already work in declarative?
[23:25:57] <jglick> rtyler: it should
[23:27:36] <rtyler> hrmpw: is the preferred middle ground between declarative pipeline and putting stuff into shared libraries going to be "use readTrusted" then?
[23:28:22] <hrmpw> ?? rtyler
[23:28:42] <rtyler> heh, I feel like you've missed a fair bit of discussion here hrmpw
[23:28:53] <hrmpw> I feel that too
[23:30:20] <hrmpw> I think readTrusted works if you want to put libraries into your current repo rtyler
[23:30:42] <hrmpw> but I actually agree with bitwiseman and think JENKINS-41396 is a good step
[23:30:44] <jenkins-admin> JENKINS-41396:Declarative: Add method definition section to root pipeline block (Reopened) https://issues.jenkins-ci.org/browse/JENKINS-41396
[23:31:21] <hrmpw> you can already do what bitwiseman says by putting your functions outside of the pipeline block
[23:31:34] <hrmpw> this just lets you move it inside the pipeline block
[23:31:57] <bitwiseman> hrmpw: tht functions outside the pipeline block is what I'd like to not do anymore.
[23:32:04] <rtyler> hrmpw: I want to make sure that we're documenting approaches which are guaranteed to work within the Pipeline Visual Editor, and will be supported by Pipeline moving foprward
[23:32:40] <bitwiseman> hrmpw: so, JENKINS-41396  would be cool, but as I was thinking about it.
[23:32:41] <jenkins-admin> JENKINS-41396:Declarative: Add method definition section to root pipeline block (Reopened) https://issues.jenkins-ci.org/browse/JENKINS-41396
[23:32:48] <hrmpw> I think I’m agreeing with you rtyler
[23:33:09] <bitwiseman> I  could see technical difficulties.
[23:33:30] <bitwiseman> which abayer described to me.
[23:33:43] <bitwiseman> Further there's related issues
[23:34:07] <bitwiseman> like JENKINS-41335
[23:34:08] <jenkins-admin> JENKINS-41335:Allow variables and functions to be defined within pipeline to be used in any stage (Open) https://issues.jenkins-ci.org/browse/JENKINS-41335
[23:34:19] <bitwiseman> And people are saying those are hard to solve.
[23:34:58] <bitwiseman> the only reason they are hard to solve is we're trying to them in the Jenkinsfile and inside the pipeline section.
[23:35:54] <bitwiseman> hrmpw All these things are already handled correctly in shared libraries (or if not they should be bugged and fixed).
[23:36:47] <bitwiseman> hrmpw: which got me thinking, instead of adding "method" to pipeline, using a "local" library would in some ways be even better.
[23:37:50] <hrmpw> Kindel: node won’t clone it unless you do “checkout sam"
[23:37:55] <hrmpw> scm not sam
[23:38:37] <rtyler> bitwiseman: "local" library I'm kind of meh on personally, I like the method block concept because everything would end up in one file
[23:38:43] <hrmpw> bitwiseman: we talked about having a local library a long time ago
[23:38:45] <rtyler> and the "pain" of not using a shared library would show up sooner
[23:39:04] <hrmpw> at first I thought it would be great but then thought it might be hard to manage
[23:39:17] <rtyler> I'm sure abayer could add a cute little hack to say after 80 lines, we put a console output warning that says " Hey, maybe you should use shared libraries you silly goose"
[23:39:32] <hrmpw> then again if we build in “library” step in declarative like we plan we could build some sugar around readtrusted and a local file there
[23:39:42] <bitwiseman> rtyler: but should they really be using a shared library?
[23:40:15] <bitwiseman> Do we have to push them that way?
[23:42:29] <rtyler> bitwiseman: i think it should be encouraged
[23:42:48] <rtyler> in the blog post your wrote as an example, anybody implementing something like that is definitely not going to have just a single Pipeline :P
[23:43:15] <hrmpw> shared libraries are a good best practice I think but for quick hit, one off helper functions they can seem heavy
[23:43:37] * rtyler nods
[23:44:11] <rtyler> I assume that if somebody has exceeded a certain number of helper methods, or exceeded a certain length, they should be encouraged to either use shared libraries or consider just scripted pipeline
[23:44:29] <bitwiseman> hrmpw: they only seem heavy because they currently have to be a whole separate repo.
[23:45:03] <rtyler> bitwiseman: I think we're crossing streams here
[23:46:02] <hrmpw> I’m a little wary of C# style “code-behind” pages for libaries
[23:46:16] <rtyler> there are two use-cases we're kind of talking around. 1) middle-ground between declarative and a library 2) making libraries more easily created
[23:46:17] <hrmpw> but that’ because I had to write C# in the first place
[23:46:20] <rtyler> (I think)
[23:46:29] * rtyler puts a warm blanket around hrmpw
[23:46:36] <rtyler> ASP.NET can't hurt you anymore
[23:46:46] <bitwiseman> :D
[23:47:12] <bitwiseman> rtyler - "encouraged to ...  consider just scripted pipeline" - I disagree.
[23:47:28] <hrmpw> I think we all agree on that rtyler
[23:49:29] <bitwiseman> I think there are fewer cases where people should be pushed to scripted than we are currently thinking.
[23:49:56] <rtyler> that may be true, but I also don't think we should turn declarative into scripted :P
[23:50:34] <bitwiseman> rtyler: agreed.  Declarative should not be made into scripted.
[23:50:45] <rtyler> hrmpw: it might be interesting for you to pick stephend and davehunt's brains about their Jenkinsfile complexity and the perceived boundaries between shared libraries and jenkinsfiles
[23:51:10] <rtyler> I reviewed a few Jenkinsfiles from mozilla this morning
[23:51:17] <rtyler> many varying levels of complexity in thar
[23:51:21] <hrmpw> I saw one of them
[23:51:30] <hrmpw> had several things before “pipeline"
[23:52:18] <hrmpw> some of that might also be solved by the readProperties stuff that rsandell is working on too
[23:52:21] <rtyler> bitwiseman: fwiw I like the local library concept a lot, and think it actually maps to use-cases that Mozilla and other organizations with large repos/projects
[23:52:32] <rtyler> but I want a methods directive much more right now
[23:53:07] <hrmpw> the “build” command launches a separate job in Jenkins
[23:53:47] <hrmpw> if you create a parameter in your pipeline for commit hash and pass that in via build command or otherwise you can use that hash in your pipeline
[23:53:48] <bitwiseman> rtyler: directive vs local libary - I think we need abayer's opinion, but the local library might be easier to implement.
[23:54:35] <rtyler> bitwiseman: the downside to a local library for that middle ground though is there would be this additional directory structure and hierarchy needed, for what I believe would just be a one-off helper method in most cases
[23:54:37] <bitwiseman> rtyler: and because local library would reuse the library code it would probably be more dependable.
[23:54:58] <bitwiseman> rtyler: fair point.
[23:57:19] <hrmpw> andrew and jesse know better but there is a difference in how shared libraries are loaded into pipeline versus readTrusted
[23:59:50] <bitwiseman> rtyler: hrmpw: okay, I'm cool with either.  I just thought the local library might be an expedient solution to several requests. (shrug) I'll finish the JIRA ticket, capture some of this discussion, and move on.