Hi -
I'm looking to use gradle to run tests in declarative pipeline jobs.
Looking at docs here under tools I should be able to spec a gradle tool in
the tools section:
https://jenkins.io/doc/book/pipeline/syntax/#declarative-steps
So I created a job like this:
pipeline {
agent any
Hey there -
I think it might be worth posting the pipeline of your orchestration job
that runs the 12000 builds for anyone to comment in more detail.
>From what I understand, if your pipeline is not orchestrating each build in
a node section it will use something called a 'flyweight executor'
Yes, I did all that gradle configuration. 'GRADLE_LATEST' is the label we used
for our gradle installation. We name it that way so every time we update to the
latest gradle, we don't need to change all our jobs that we want to be on the
latest gradle version. We also use gradle version specific
Hi -
It is designed like that. Jenkins is masking the credentials details in the
logs by design as you might not want them visible there. If you echo the
credentials details to a file kept in the workspace, you should see the
actual values in the file. That is how I check it for debugging.
For future reference I discovered this issue is fixed by gradle plugin
v1.26 - this issue: https://issues.jenkins-ci.org/browse/JENKINS-37394
On Thursday, 16 February 2017 02:40:42 UTC, Bill Dennis wrote:
>
> Hi -
>
> I'm looking to use gradle to run tests in declarative p
I've seen it used in a 'when' condition - in this example online:
https://github.com/sta-szek/pojo-tester/blob/master/Jenkinsfile
Here is an extract from that:
when {
expression {
boolean publish = false
if (env.DEPLOYPAGES == "true") {
return true
}
t:32779/job/Foo/21/console#> or Abort
<http://localhost:32779/job/Foo/21/console#>
Approved by Bill Dennis <http://localhost:32779/user/bill>
[Pipeline] echo
localEnv.BUILD_NUMBER = 21
[Pipeline] echo
env.BUILD_NUMBER = 21
[Pipeline] echo
foo = Bar
[Pipeline] echo
myBuildNumber =
I think it is failing on the call to the generateXML() method - is it
defined in your job and how is it defined, what parameters does it expect?
BTW, be aware that the Groovy 'Eval' will allow anyone to execute whatever
Groovy code they would like to put in the input parameter. This line:
def
Hi -
You can do it with a declarative pipeline job to orchestrate running your
test and log collection jobs.
Something like this using 'agent none' so you don't tie up executors when
waiting at any point:
pipeline {
agent none
stages {
stage('Build') {
steps {
Should have been:
sleep time: 1, unit: 'HOURS'
On Wednesday, 15 March 2017 23:25:44 UTC, Bill Dennis wrote:
>
> Hi -
>
> You can do it with a declarative pipeline job to orchestrate running your
> test and log collection jobs.
>
> Something like this using 'agent none
Hi -
I'm tending to use Declarative as my preference after starting with the
scripted like you did. I'm finding:
- With declarative can have more of the job configuration in the
Jenkinsfile like parameters and SCM polling. It means the Jenkins server
can pick up the Jenkinsfiles for
, and
> throws the following message: No such property: $testMasterCred for class:
> groovy.lang.Binding
>
> I've got the feeling that I'm not very far from the truth.
> There's not much help on the pipeline-utility-steps-plugin readme
> regarding this.
>
> Would you have an
I have found the same. There is an open jira for this here:
https://issues.jenkins-ci.org/browse/JENKINS-40455
Are you using declarative or scripted pipeline?
In declarative, I have found I can reference env vars configured in Jenkins in
the environment section to set up job level environment:
ve an example of how you'd write one?
> Is it a key / value format? bash variables declarations? JSON? XML?
>
> Thank you for your time and your help.
>
> Regards.
>
> Jeremy.
>
> Le mercredi 8 mars 2017 10:05:02 UTC+1, Bill Dennis a écrit :
>>
>> Just some other things I
You can do it with a for loop. There are issues using Groovy iterators like
each {}. Try something like this:
pipeline {
agent any
stages {
stage('loop') {
steps {
script {
def x = ['a', 'b', 'c']
println x
If your Jenkinsfile is in the same repo, using declarative pipeline you can
have triggers in the pipeline to do this:
pipeline {
triggers {
pollSCM('*/5 * * * *')
}
...
}
It works for me using subversion.
Bill
--
You received this message because you are subscribed to the Google
If you put the pipeline / branch jobs inside a folder, you can scope the
credentials to just that folder. Pretty sure that is available in Jenkins OSS
and not just Enterprise - you need the CloudBees Folders plugin. Have a look on
here, it might have some clues:
handling for build errors.
Bill
On Wednesday, 8 March 2017 08:45:03 UTC, Bill Dennis wrote:
>
> If you put the pipeline / branch jobs inside a folder, you can scope the
> credentials to just that folder. Pretty sure that is available in Jenkins
> OSS and not just Enterpris
You could build the downstream jobs without propagating the error to the
top level job calling them.
Then you could get the results from each downstream job and handle it to do
the notifications according to SUCCESS/FAILURE/UNSTABLE etc.
I do this sort of thing using declarative pipeline then
Ah just saw you need the job to call all builds even if one fails. You can
do it with a parallel section like this:
Map buildResults = [:]
Boolean failedJobs = false
void nofify_email(Map results) {
echo "TEST SIMULATE notify: ${results.toString()}"
}
Boolean buildJob(String jobName, Map
There is no chaining mechanism I am aware of built in.
If you want to chain 2 pipeline jobs 'P1' and 'P2' you can just build P2
from a 'post' section of the last stage on P1.
Your pipeline code would need to look something like this:
pipeline {
agent any
stages {
(re-posting with corrections)
Has anyone managed to write pipeline code (or even their own plugin) to
approve an input using pipeline code from another job (shared library
NonCPS method or whatever)?
I have this scenario -
JobA
input id: 'JOBA_CALLBACK', message: 'Waiting for JobB',
Has anyone managed to write pipeline code (or even their own plugin) to
approve an input using pipeline code from another job (shared library
NonCPS method or whatever)?
I have this scenario -
*JobA*
input id: 'JOBA_CALLBACK', message: 'Waiting for JobB', parameters: [string(
defaultValue:
I don' t think the Jenkins CRON spec has seconds resolution.
You can build an orchestrater job that is scheduled to run every 1 minute.
Then in that job, loop 6 times with a sleep of 10 seconds and build another
job.
Also use the do not allow concurrent builds.
Something like this:
pipeline
Did you consider using a single declarative pipeline for this with multiple
stages? If you make the agent declaration at main pipeline level, the same
workspace should be used for each stage so no need to copy the 200MB of files
around - see this stack overflow
25 matches
Mail list logo
