On 2 August 2017 at 08:14, bbyjenkns <[email protected]> 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 <[email protected]> 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 [email protected]. >>> 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 [email protected]. > 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 [email protected]. 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.
