I should mention that I'm specifically trying to perform file operations within a workspace using global pipeline libraries. I'm not following how a global pipeline library would even make sense if it can only run on master - am I missing something here?
On Thursday, August 3, 2017 at 3:06:23 PM UTC-5, bbyjenkns wrote: > > FYI AntBuilder is not going to work because it is running on the master >> not on the build agent... > > > So, using java.nio.file.Files for example wouldn't work to copy files on > any nodes other than master? How do you do any file operations inside a > workspace on a slave otherwise? Do you have to shell out and cp everything? > If that's the case, how do you properly handle errors etc? > > > > On Wednesday, August 2, 2017 at 10:58:52 AM UTC-5, Stephen Connolly wrote: >> >> On 2 August 2017 at 08:14, bbyjenkns <mcj...@gmail.com> wrote: >> >>> Ok - understood. That does clear some things up. Where can I find more >>> info on what is and is not allowed in global pipelines libraries? I'm >>> writing one now, and have defaulted to using the 'sh' step and returning >>> status codes to do most every file operation because what I try to do in >>> base groovy just does not work (using AntBuilder to copy directories for >>> example). >>> >> >> FYI AntBuilder is not going to work because it is running on the master >> not on the build agent... >> >> >>> >>> On Wednesday, August 2, 2017 at 9:46:18 AM UTC-5, Stephen Connolly wrote: >>>> >>>> On 2 August 2017 at 06:10, bbyjenkns <mcj...@gmail.com> wrote: >>>> >>>>> I'm struggling with the same thing - doc is very light or wants you to >>>>> shell out for everything. I want to write groovy for everything, but it >>>>> seems like simple things, such as using AntBuilder for it's file >>>>> operation >>>>> magic is very difficult if not impossible. >>>>> >>>>> >>>> Pipeline is *NOT* groovy. >>>> >>>> It is a CPS engine built on top of Groovy... it may look like Groovy, >>>> it may even sometimes walk and quack like Groovy, but your life will be >>>> infinitely better if you just accept that it is *NOT* Groovy. >>>> >>>> Global Shared Libraries is where you go if you want to write idiomatic >>>> Groovy, and even there you can hit issues unless you truly understand the >>>> CPS magic and its full implications. >>>> >>>> Use pipeline as a final orchestration glue layer and your life will be >>>> much easier >>>> >>>> >>>> >>>>> On Tuesday, August 1, 2017 at 6:24:25 PM UTC-5, rcarruth wrote: >>>>>> >>>>>> I’ve read the “getting started with pipeline” pages ( >>>>>> https://jenkins.io/doc/book/pipeline/getting-started/). >>>>>> >>>>>> >>>>>> >>>>>> I’ve spent literally hours looking for something really helpful, in >>>>>> one place, for someone who wants to write CODE in the pipeline script. >>>>>> >>>>>> >>>>>> >>>>>> I did just find https://jenkins.io/doc/book/pipeline/syntax/, which >>>>>> is a great step in the direction I was looking for. >>>>>> >>>>>> >>>>>> >>>>>> However, an update. I’ve been searching around and gotten a lot >>>>>> further, but I want more, quicker. >>>>>> >>>>>> >>>>>> >>>>>> I should mention that I’ve been a software developer for many years >>>>>> (oh, what, 40 or so? C, C++ primarily, but a little Java), I teach a >>>>>> class >>>>>> called “Linux Operating System” at a community college (have been for 3 >>>>>> years or so), I write scripts (bash, python, perl, etc) all the time, so >>>>>> I >>>>>> hope I have more than a small clue about ‘things’. >>>>>> >>>>>> >>>>>> >>>>>> I note that Jenkins World is coming soon to SF. Perhaps that’s the >>>>>> best place to learn/etc… >>>>>> >>>>>> >>>>>> >>>>>> Here’s the deal. I’m trying to Jenkins-ize our test infrastructure. >>>>>> Right now it is all done via shell scripts and ssh. >>>>>> >>>>>> >>>>>> >>>>>> However, it’s a monolith. You set your configuration for each test >>>>>> host (in a pretty big config file), start the run, and wait (up to more >>>>>> than a day! (sometimes multiple days)) for the test run to complete. >>>>>> When >>>>>> the test run completes, a script runs which generates a report, >>>>>> including >>>>>> of what tests ran, which of those that ran failed, and so forth (NOTE >>>>>> that >>>>>> just because a single test fails does NOT mean we want to kill the >>>>>> entire >>>>>> test run). >>>>>> >>>>>> >>>>>> >>>>>> Oh, yes – I should mention that the test run involves MULTIPLE test >>>>>> hosts, each running basically independently of each other. Once a test >>>>>> host finishes its test run, it is available for another test run. Every >>>>>> day we build our system and that triggers a full test run, as defined by >>>>>> a >>>>>> config file (which defines which hosts to run, and the test config file >>>>>> to >>>>>> use for that host – each host can have a different test configuration. >>>>>> Indeed, it can have a completely different product being tested). >>>>>> >>>>>> >>>>>> >>>>>> To do a test run on a host, we first run some scripts on the server >>>>>> which sets up the global environment (we monitor serial port activity >>>>>> and >>>>>> store the output in a log file in the test report directory, for >>>>>> example), >>>>>> then we set up stuff on the test host (which starts out running Linux) >>>>>> for >>>>>> the test to come. Right now, MOST of our tests are run under FreeDOS >>>>>> (don’t ask – we currently have no choice in that matter), then when >>>>>> those >>>>>> tests finish the host reboots into Linux, runs any Linux-based tests, >>>>>> and >>>>>> then runs ‘finish’, which copies the logs to the server, creates the >>>>>> test >>>>>> report, and emails it to a specified group. >>>>>> >>>>>> >>>>>> >>>>>> For one thing, we’d like to have better visibility into the progress >>>>>> of the test (even possibly with partial results), and the ability to >>>>>> stop >>>>>> the testing at any stage in the process fairly easily. >>>>>> >>>>>> >>>>>> >>>>>> So, I’m working on re-doing it all with Jenkins driving things. >>>>>> >>>>>> >>>>>> >>>>>> Right now I’ve got one pipeline which will use a config file to >>>>>> specify which test hosts (and configuration) to start running – its more >>>>>> or >>>>>> less done (reads config file, parses, does what it says). >>>>>> >>>>>> >>>>>> >>>>>> I’ve got another pipeline which runs the ‘setup global environment’ >>>>>> script, and which I’ve just proven works fine, as far as it goes. No >>>>>> scripts AFTER that have been implemented… >>>>>> >>>>>> >>>>>> >>>>>> I’m working on implementing the rest of the thing (both the ‘actually >>>>>> start the run’ part that happens after the global environment setup, and >>>>>> all the different stages. Right now I’ve got a pipeline which parses >>>>>> another config file and runs the scripts specified (and their >>>>>> command-line >>>>>> args). It kind of works too, but I’m thinking that the command-line >>>>>> args >>>>>> are way too unfriendly for ‘normal’ users. >>>>>> >>>>>> >>>>>> >>>>>> So, I’m halfway competent (which means at least 50% INcompetent!), >>>>>> but feel like if I knew a bit more I’d not rush down a path that I’ll >>>>>> have >>>>>> to redo later. >>>>>> >>>>>> >>>>>> >>>>>> Are there any good documents to help me move more into the competent >>>>>> phase? As I asked above, is Jenkins World the best place (bang for >>>>>> buck)? >>>>>> >>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> Rusty >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> 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-use...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/jenkinsci-users/d316f5f2-3620-4472-bc44-2aa7422c31da%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/jenkinsci-users/d316f5f2-3620-4472-bc44-2aa7422c31da%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> 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-use...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-users/46ec8239-73d3-4ff7-9a7a-4e8705181d6b%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jenkinsci-users/46ec8239-73d3-4ff7-9a7a-4e8705181d6b%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > On Wednesday, August 2, 2017 at 10:58:52 AM UTC-5, Stephen Connolly wrote: >> >> On 2 August 2017 at 08:14, bbyjenkns <mcj...@gmail.com> wrote: >> >>> Ok - understood. That does clear some things up. Where can I find more >>> info on what is and is not allowed in global pipelines libraries? I'm >>> writing one now, and have defaulted to using the 'sh' step and returning >>> status codes to do most every file operation because what I try to do in >>> base groovy just does not work (using AntBuilder to copy directories for >>> example). >>> >> >> FYI AntBuilder is not going to work because it is running on the master >> not on the build agent... >> >> >>> >>> On Wednesday, August 2, 2017 at 9:46:18 AM UTC-5, Stephen Connolly wrote: >>>> >>>> On 2 August 2017 at 06:10, bbyjenkns <mcj...@gmail.com> wrote: >>>> >>>>> I'm struggling with the same thing - doc is very light or wants you to >>>>> shell out for everything. I want to write groovy for everything, but it >>>>> seems like simple things, such as using AntBuilder for it's file >>>>> operation >>>>> magic is very difficult if not impossible. >>>>> >>>>> >>>> Pipeline is *NOT* groovy. >>>> >>>> It is a CPS engine built on top of Groovy... it may look like Groovy, >>>> it may even sometimes walk and quack like Groovy, but your life will be >>>> infinitely better if you just accept that it is *NOT* Groovy. >>>> >>>> Global Shared Libraries is where you go if you want to write idiomatic >>>> Groovy, and even there you can hit issues unless you truly understand the >>>> CPS magic and its full implications. >>>> >>>> Use pipeline as a final orchestration glue layer and your life will be >>>> much easier >>>> >>>> >>>> >>>>> On Tuesday, August 1, 2017 at 6:24:25 PM UTC-5, rcarruth wrote: >>>>>> >>>>>> I’ve read the “getting started with pipeline” pages ( >>>>>> https://jenkins.io/doc/book/pipeline/getting-started/). >>>>>> >>>>>> >>>>>> >>>>>> I’ve spent literally hours looking for something really helpful, in >>>>>> one place, for someone who wants to write CODE in the pipeline script. >>>>>> >>>>>> >>>>>> >>>>>> I did just find https://jenkins.io/doc/book/pipeline/syntax/, which >>>>>> is a great step in the direction I was looking for. >>>>>> >>>>>> >>>>>> >>>>>> However, an update. I’ve been searching around and gotten a lot >>>>>> further, but I want more, quicker. >>>>>> >>>>>> >>>>>> >>>>>> I should mention that I’ve been a software developer for many years >>>>>> (oh, what, 40 or so? C, C++ primarily, but a little Java), I teach a >>>>>> class >>>>>> called “Linux Operating System” at a community college (have been for 3 >>>>>> years or so), I write scripts (bash, python, perl, etc) all the time, so >>>>>> I >>>>>> hope I have more than a small clue about ‘things’. >>>>>> >>>>>> >>>>>> >>>>>> I note that Jenkins World is coming soon to SF. Perhaps that’s the >>>>>> best place to learn/etc… >>>>>> >>>>>> >>>>>> >>>>>> Here’s the deal. I’m trying to Jenkins-ize our test infrastructure. >>>>>> Right now it is all done via shell scripts and ssh. >>>>>> >>>>>> >>>>>> >>>>>> However, it’s a monolith. You set your configuration for each test >>>>>> host (in a pretty big config file), start the run, and wait (up to more >>>>>> than a day! (sometimes multiple days)) for the test run to complete. >>>>>> When >>>>>> the test run completes, a script runs which generates a report, >>>>>> including >>>>>> of what tests ran, which of those that ran failed, and so forth (NOTE >>>>>> that >>>>>> just because a single test fails does NOT mean we want to kill the >>>>>> entire >>>>>> test run). >>>>>> >>>>>> >>>>>> >>>>>> Oh, yes – I should mention that the test run involves MULTIPLE test >>>>>> hosts, each running basically independently of each other. Once a test >>>>>> host finishes its test run, it is available for another test run. Every >>>>>> day we build our system and that triggers a full test run, as defined by >>>>>> a >>>>>> config file (which defines which hosts to run, and the test config file >>>>>> to >>>>>> use for that host – each host can have a different test configuration. >>>>>> Indeed, it can have a completely different product being tested). >>>>>> >>>>>> >>>>>> >>>>>> To do a test run on a host, we first run some scripts on the server >>>>>> which sets up the global environment (we monitor serial port activity >>>>>> and >>>>>> store the output in a log file in the test report directory, for >>>>>> example), >>>>>> then we set up stuff on the test host (which starts out running Linux) >>>>>> for >>>>>> the test to come. Right now, MOST of our tests are run under FreeDOS >>>>>> (don’t ask – we currently have no choice in that matter), then when >>>>>> those >>>>>> tests finish the host reboots into Linux, runs any Linux-based tests, >>>>>> and >>>>>> then runs ‘finish’, which copies the logs to the server, creates the >>>>>> test >>>>>> report, and emails it to a specified group. >>>>>> >>>>>> >>>>>> >>>>>> For one thing, we’d like to have better visibility into the progress >>>>>> of the test (even possibly with partial results), and the ability to >>>>>> stop >>>>>> the testing at any stage in the process fairly easily. >>>>>> >>>>>> >>>>>> >>>>>> So, I’m working on re-doing it all with Jenkins driving things. >>>>>> >>>>>> >>>>>> >>>>>> Right now I’ve got one pipeline which will use a config file to >>>>>> specify which test hosts (and configuration) to start running – its more >>>>>> or >>>>>> less done (reads config file, parses, does what it says). >>>>>> >>>>>> >>>>>> >>>>>> I’ve got another pipeline which runs the ‘setup global environment’ >>>>>> script, and which I’ve just proven works fine, as far as it goes. No >>>>>> scripts AFTER that have been implemented… >>>>>> >>>>>> >>>>>> >>>>>> I’m working on implementing the rest of the thing (both the ‘actually >>>>>> start the run’ part that happens after the global environment setup, and >>>>>> all the different stages. Right now I’ve got a pipeline which parses >>>>>> another config file and runs the scripts specified (and their >>>>>> command-line >>>>>> args). It kind of works too, but I’m thinking that the command-line >>>>>> args >>>>>> are way too unfriendly for ‘normal’ users. >>>>>> >>>>>> >>>>>> >>>>>> So, I’m halfway competent (which means at least 50% INcompetent!), >>>>>> but feel like if I knew a bit more I’d not rush down a path that I’ll >>>>>> have >>>>>> to redo later. >>>>>> >>>>>> >>>>>> >>>>>> Are there any good documents to help me move more into the competent >>>>>> phase? As I asked above, is Jenkins World the best place (bang for >>>>>> buck)? >>>>>> >>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> Rusty >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> 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-use...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/jenkinsci-users/d316f5f2-3620-4472-bc44-2aa7422c31da%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/jenkinsci-users/d316f5f2-3620-4472-bc44-2aa7422c31da%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> 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-use...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-users/46ec8239-73d3-4ff7-9a7a-4e8705181d6b%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jenkinsci-users/46ec8239-73d3-4ff7-9a7a-4e8705181d6b%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > On Wednesday, August 2, 2017 at 10:58:52 AM UTC-5, Stephen Connolly wrote: >> >> On 2 August 2017 at 08:14, bbyjenkns <mcj...@gmail.com> wrote: >> >>> Ok - understood. That does clear some things up. Where can I find more >>> info on what is and is not allowed in global pipelines libraries? I'm >>> writing one now, and have defaulted to using the 'sh' step and returning >>> status codes to do most every file operation because what I try to do in >>> base groovy just does not work (using AntBuilder to copy directories for >>> example). >>> >> >> FYI AntBuilder is not going to work because it is running on the master >> not on the build agent... >> >> >>> >>> On Wednesday, August 2, 2017 at 9:46:18 AM UTC-5, Stephen Connolly wrote: >>>> >>>> On 2 August 2017 at 06:10, bbyjenkns <mcj...@gmail.com> wrote: >>>> >>>>> I'm struggling with the same thing - doc is very light or wants you to >>>>> shell out for everything. I want to write groovy for everything, but it >>>>> seems like simple things, such as using AntBuilder for it's file >>>>> operation >>>>> magic is very difficult if not impossible. >>>>> >>>>> >>>> Pipeline is *NOT* groovy. >>>> >>>> It is a CPS engine built on top of Groovy... it may look like Groovy, >>>> it may even sometimes walk and quack like Groovy, but your life will be >>>> infinitely better if you just accept that it is *NOT* Groovy. >>>> >>>> Global Shared Libraries is where you go if you want to write idiomatic >>>> Groovy, and even there you can hit issues unless you truly understand the >>>> CPS magic and its full implications. >>>> >>>> Use pipeline as a final orchestration glue layer and your life will be >>>> much easier >>>> >>>> >>>> >>>>> On Tuesday, August 1, 2017 at 6:24:25 PM UTC-5, rcarruth wrote: >>>>>> >>>>>> I’ve read the “getting started with pipeline” pages ( >>>>>> https://jenkins.io/doc/book/pipeline/getting-started/). >>>>>> >>>>>> >>>>>> >>>>>> I’ve spent literally hours looking for something really helpful, in >>>>>> one place, for someone who wants to write CODE in the pipeline script. >>>>>> >>>>>> >>>>>> >>>>>> I did just find https://jenkins.io/doc/book/pipeline/syntax/, which >>>>>> is a great step in the direction I was looking for. >>>>>> >>>>>> >>>>>> >>>>>> However, an update. I’ve been searching around and gotten a lot >>>>>> further, but I want more, quicker. >>>>>> >>>>>> >>>>>> >>>>>> I should mention that I’ve been a software developer for many years >>>>>> (oh, what, 40 or so? C, C++ primarily, but a little Java), I teach a >>>>>> class >>>>>> called “Linux Operating System” at a community college (have been for 3 >>>>>> years or so), I write scripts (bash, python, perl, etc) all the time, so >>>>>> I >>>>>> hope I have more than a small clue about ‘things’. >>>>>> >>>>>> >>>>>> >>>>>> I note that Jenkins World is coming soon to SF. Perhaps that’s the >>>>>> best place to learn/etc… >>>>>> >>>>>> >>>>>> >>>>>> Here’s the deal. I’m trying to Jenkins-ize our test infrastructure. >>>>>> Right now it is all done via shell scripts and ssh. >>>>>> >>>>>> >>>>>> >>>>>> However, it’s a monolith. You set your configuration for each test >>>>>> host (in a pretty big config file), start the run, and wait (up to more >>>>>> than a day! (sometimes multiple days)) for the test run to complete. >>>>>> When >>>>>> the test run completes, a script runs which generates a report, >>>>>> including >>>>>> of what tests ran, which of those that ran failed, and so forth (NOTE >>>>>> that >>>>>> just because a single test fails does NOT mean we want to kill the >>>>>> entire >>>>>> test run). >>>>>> >>>>>> >>>>>> >>>>>> Oh, yes – I should mention that the test run involves MULTIPLE test >>>>>> hosts, each running basically independently of each other. Once a test >>>>>> host finishes its test run, it is available for another test run. Every >>>>>> day we build our system and that triggers a full test run, as defined by >>>>>> a >>>>>> config file (which defines which hosts to run, and the test config file >>>>>> to >>>>>> use for that host – each host can have a different test configuration. >>>>>> Indeed, it can have a completely different product being tested). >>>>>> >>>>>> >>>>>> >>>>>> To do a test run on a host, we first run some scripts on the server >>>>>> which sets up the global environment (we monitor serial port activity >>>>>> and >>>>>> store the output in a log file in the test report directory, for >>>>>> example), >>>>>> then we set up stuff on the test host (which starts out running Linux) >>>>>> for >>>>>> the test to come. Right now, MOST of our tests are run under FreeDOS >>>>>> (don’t ask – we currently have no choice in that matter), then when >>>>>> those >>>>>> tests finish the host reboots into Linux, runs any Linux-based tests, >>>>>> and >>>>>> then runs ‘finish’, which copies the logs to the server, creates the >>>>>> test >>>>>> report, and emails it to a specified group. >>>>>> >>>>>> >>>>>> >>>>>> For one thing, we’d like to have better visibility into the progress >>>>>> of the test (even possibly with partial results), and the ability to >>>>>> stop >>>>>> the testing at any stage in the process fairly easily. >>>>>> >>>>>> >>>>>> >>>>>> So, I’m working on re-doing it all with Jenkins driving things. >>>>>> >>>>>> >>>>>> >>>>>> Right now I’ve got one pipeline which will use a config file to >>>>>> specify which test hosts (and configuration) to start running – its more >>>>>> or >>>>>> less done (reads config file, parses, does what it says). >>>>>> >>>>>> >>>>>> >>>>>> I’ve got another pipeline which runs the ‘setup global environment’ >>>>>> script, and which I’ve just proven works fine, as far as it goes. No >>>>>> scripts AFTER that have been implemented… >>>>>> >>>>>> >>>>>> >>>>>> I’m working on implementing the rest of the thing (both the ‘actually >>>>>> start the run’ part that happens after the global environment setup, and >>>>>> all the different stages. Right now I’ve got a pipeline which parses >>>>>> another config file and runs the scripts specified (and their >>>>>> command-line >>>>>> args). It kind of works too, but I’m thinking that the command-line >>>>>> args >>>>>> are way too unfriendly for ‘normal’ users. >>>>>> >>>>>> >>>>>> >>>>>> So, I’m halfway competent (which means at least 50% INcompetent!), >>>>>> but feel like if I knew a bit more I’d not rush down a path that I’ll >>>>>> have >>>>>> to redo later. >>>>>> >>>>>> >>>>>> >>>>>> Are there any good documents to help me move more into the competent >>>>>> phase? As I asked above, is Jenkins World the best place (bang for >>>>>> buck)? >>>>>> >>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> Rusty >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> 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-use...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/jenkinsci-users/d316f5f2-3620-4472-bc44-2aa7422c31da%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/jenkinsci-users/d316f5f2-3620-4472-bc44-2aa7422c31da%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> 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-use...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-users/46ec8239-73d3-4ff7-9a7a-4e8705181d6b%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jenkinsci-users/46ec8239-73d3-4ff7-9a7a-4e8705181d6b%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > On Wednesday, August 2, 2017 at 10:58:52 AM UTC-5, Stephen Connolly wrote: >> >> On 2 August 2017 at 08:14, bbyjenkns <mcj...@gmail.com> wrote: >> >>> Ok - understood. That does clear some things up. Where can I find more >>> info on what is and is not allowed in global pipelines libraries? I'm >>> writing one now, and have defaulted to using the 'sh' step and returning >>> status codes to do most every file operation because what I try to do in >>> base groovy just does not work (using AntBuilder to copy directories for >>> example). >>> >> >> FYI AntBuilder is not going to work because it is running on the master >> not on the build agent... >> >> >>> >>> On Wednesday, August 2, 2017 at 9:46:18 AM UTC-5, Stephen Connolly wrote: >>>> >>>> On 2 August 2017 at 06:10, bbyjenkns <mcj...@gmail.com> wrote: >>>> >>>>> I'm struggli >>>>> >>>> -- 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/c2197900-d6d8-4a83-8931-61336ac7198a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
