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/ms >>> gid/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-users+unsubscr...@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. > -- 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/CA%2BnPnMy6OF4wsV5fXL6uR2N6o2%3D88HLTEHZFjtqMBFsYUD__tQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
