Re: How can I tail the console output for a failed pipeline build?
Answering my own question in case it may help someone. I put this in my
"failure" post action section of my Jenkinsfile to extract the last 100
lines of the build log. I also filtered out the post actions output and
the leading rubbish on each line of the actual build log.
jobName = "${env.JOB_NAME}"
tokens = jobName.split('/')
jobDir = tokens[0]
logFile =
"${env.JENKINS_HOME}/jobs/${jobDir}/branches/${env.JOB_BASE_NAME}/builds/${env.BUILD_NUMBER}/log"
command = $/tail -100 ${logFile} | sed '/Post Actions/q' | sed
'/\[Pipeline\]/d' | sed -e 's/^.*\[0m//g'/$
logSnippet = sh(script: command, returnStdout: true)
On Monday, September 4, 2017 at 10:27:52 AM UTC-5, Dallas Clement wrote:
>
> I've done all that. What I want is to extract the last portion of the
> actual console output for a build that has failed so that I can embed it in
> the body of an email notification to indicate where the build has failed.
> I'm trying to avoid attaching the whole build log. I've been able to
> locate the build log, but I don't know how to extract the raw console
> output from it.
>
> On Monday, September 4, 2017 at 6:14:56 AM UTC-5, xwyxw wrote:
>>
>> Blueoncean, split your script in functions and stages and you will get
>> a good understanding of what is actually happening on every stage (clone,
>> build, fail, etc). Also using groovy and try/catch will help too
>>
>> On Friday, September 1, 2017 at 2:25:05 AM UTC+10, Dallas Clement wrote:
>>>
>>> I am working with multibranch pipeline builds and I want to be able to
>>> tail the end of the console output to include in build failure email
>>> notifications. I can see where the log file is located in the filesystem
>>> under
>>>
>>> /var/lib/jenkins/jobs//branches/>> branch>/builds/5
>>>
>>> The build log appears to have the console output embedded in it. But
>>> there appears to be a whole lot more also. How can I extract / render just
>>> the console output?
>>>
>>>
>>>
--
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/1baad50f-780d-4296-96cb-030a26683fca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: How can I tail the console output for a failed pipeline build?
I've done all that. What I want is to extract the last portion of the actual console output for a build that has failed so that I can embed it in the body of an email notification to indicate where the build has failed. I'm trying to avoid attaching the whole build log. I've been able to locate the build log, but I don't know how to extract the raw console output from it. On Monday, September 4, 2017 at 6:14:56 AM UTC-5, xwyxw wrote: > > Blueoncean, split your script in functions and stages and you will get a > good understanding of what is actually happening on every stage (clone, > build, fail, etc). Also using groovy and try/catch will help too > > On Friday, September 1, 2017 at 2:25:05 AM UTC+10, Dallas Clement wrote: >> >> I am working with multibranch pipeline builds and I want to be able to >> tail the end of the console output to include in build failure email >> notifications. I can see where the log file is located in the filesystem >> under >> >> /var/lib/jenkins/jobs//branches//builds/5 >> >> The build log appears to have the console output embedded in it. But >> there appears to be a whole lot more also. How can I extract / render just >> the console output? >> >> >> -- 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/0bc0f3fa-1df3-4d51-88cd-1e9f9b2a9e50%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to disable concurrent builds in a multibranch pipeline?
Yes, this gent is complaining of the same problem. I think it really needs to be addressed. It's an obvious oversight in the multibranch pipeline. Limiting the # of executors is the way to go. On Friday, September 1, 2017 at 2:07:40 PM UTC-5, mpapo - Michael Pailloncy wrote: > > Yes, probably. Seems there are already some discussions about that here : > https://issues.jenkins-ci.org/browse/JENKINS-35359 > > 2017-09-01 20:18 GMT+02:00 Dallas Clement <dallas.a...@gmail.com > >: > >> Thanks for the tip Michael. This looks like it would work. But not very >> elegant. Would be better if you could simply disable concurrent builds for >> an entire multibranch pipeline. Maybe a Jira improvement request? >> >> On Friday, September 1, 2017 at 12:29:15 PM UTC-5, mpapo - Michael >> Pailloncy wrote: >>> >>> You might be interested by this thread >>> <https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/jenkinsci-users/Cnoc0RFCvvw/E92WKr53CQAJ> >>> >>> :-) >>> >>> 2017-08-31 16:58 GMT+02:00 Dallas Clement <dallas.a...@gmail.com>: >>> >>>> I know how to disable concurrent builds for a particular branch. That >>>> works fine. But how I can I disable multiple branches from building at >>>> the >>>> same time? >>>> >>>> -- >>>> 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/1fa8921b-4539-4f69-b0c2-b063cda60d18%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/jenkinsci-users/1fa8921b-4539-4f69-b0c2-b063cda60d18%40googlegroups.com?utm_medium=email_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/48e545f9-dcaf-4ed6-b6a5-dff6b7b752ba%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-users/48e545f9-dcaf-4ed6-b6a5-dff6b7b752ba%40googlegroups.com?utm_medium=email_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/87624d3d-772d-4ef5-a9f1-5fdb9617d196%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to disable concurrent builds in a multibranch pipeline?
I created an improvement issue for this in Jira => https://issues.jenkins-ci.org/browse/JENKINS-46593 On Friday, September 1, 2017 at 1:18:34 PM UTC-5, Dallas Clement wrote: > > Thanks for the tip Michael. This looks like it would work. But not very > elegant. Would be better if you could simply disable concurrent builds for > an entire multibranch pipeline. Maybe a Jira improvement request? > > On Friday, September 1, 2017 at 12:29:15 PM UTC-5, mpapo - Michael > Pailloncy wrote: >> >> You might be interested by this thread >> <https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/jenkinsci-users/Cnoc0RFCvvw/E92WKr53CQAJ> >> >> :-) >> >> 2017-08-31 16:58 GMT+02:00 Dallas Clement <dallas.a...@gmail.com>: >> >>> I know how to disable concurrent builds for a particular branch. That >>> works fine. But how I can I disable multiple branches from building at the >>> same time? >>> >>> -- >>> 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/1fa8921b-4539-4f69-b0c2-b063cda60d18%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jenkinsci-users/1fa8921b-4539-4f69-b0c2-b063cda60d18%40googlegroups.com?utm_medium=email_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/74df7f38-5047-4ba5-a222-f4c9aa31f0e1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to disable concurrent builds in a multibranch pipeline?
Thanks for the tip Michael. This looks like it would work. But not very elegant. Would be better if you could simply disable concurrent builds for an entire multibranch pipeline. Maybe a Jira improvement request? On Friday, September 1, 2017 at 12:29:15 PM UTC-5, mpapo - Michael Pailloncy wrote: > > You might be interested by this thread > <https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/jenkinsci-users/Cnoc0RFCvvw/E92WKr53CQAJ> > > :-) > > 2017-08-31 16:58 GMT+02:00 Dallas Clement <dallas.a...@gmail.com > >: > >> I know how to disable concurrent builds for a particular branch. That >> works fine. But how I can I disable multiple branches from building at the >> same time? >> >> -- >> 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/1fa8921b-4539-4f69-b0c2-b063cda60d18%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-users/1fa8921b-4539-4f69-b0c2-b063cda60d18%40googlegroups.com?utm_medium=email_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/48e545f9-dcaf-4ed6-b6a5-dff6b7b752ba%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
How can I tail the console output for a failed pipeline build?
I am working with multibranch pipeline builds and I want to be able to tail the end of the console output to include in build failure email notifications. I can see where the log file is located in the filesystem under /var/lib/jenkins/jobs//branches//builds/5 The build log appears to have the console output embedded in it. But there appears to be a whole lot more also. How can I extract / render just the console output? -- 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/9ae82925-5787-4b1f-afcb-58cac19cf85a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
How to disable concurrent builds in a multibranch pipeline?
I know how to disable concurrent builds for a particular branch. That works fine. But how I can I disable multiple branches from building at the same time? -- 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/1fa8921b-4539-4f69-b0c2-b063cda60d18%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: "Scan Multibranch Pipeline Now" triggers immediate build
I removed the "PollSCM" from the "triggers" section of my declarative
Jenkinsfile. And then I enabled "Scan multibranch pipeline triggers" and
the "Periodically if not otherwise run" option. This method of polling
seems to work fine so far. I'm afraid I will need to rely on polling
because our git repo is on another machine in a different facility. Our
jenkins is deployed on an EC2 host and the company doesn't want to open a
port to the world for the trigger notification.
On Wednesday, August 30, 2017 at 3:40:18 AM UTC-5, Stephen Connolly wrote:
>
> On 29 August 2017 at 18:38, Dallas Clement <dallas.a...@gmail.com
> > wrote:
>
>> No I don't have any post commit hook defined. Starting with a green
>> field here. Sounds like that's what I need to setup though.
>>
>> I also don't have the "Scan Multibranch Pipeline Triggers" checkbox
>> enabled on my job configuration. I really don't know how it could be
>> triggering unless that PollSCM in my Jenkinsfile is somehow working.
>>
>
> Ok, well that sounds like a bug.
>
> I've filed https://issues.jenkins-ci.org/browse/JENKINS-46536 to track
> that.
>
>
>>
>>
>> On Tuesday, August 29, 2017 at 6:48:55 PM UTC-5, Stephen Connolly wrote:
>>>
>>> Sounds like you have a post commit hook pushing the commit details to
>>> Jenkins, in which case events are working... to confirm, check the cause of
>>> a build, if it says "Branch Event" then you are solid gold...
>>>
>>>
>>> On Wed 30 Aug 2017 at 00:42, Dallas Clement <dallas.a...@gmail.com>
>>> wrote:
>>>
>>>> Thanks for the info Stephen. I was not aware that the pollSCM trigger
>>>> was ignored in a multibranch pipeline. Something is polling for changes.
>>>> When someone pushes a change, a build gets triggered shortly thereafter.
>>>> I
>>>> do agree with you that polling is evil and not scalable with many
>>>> branches. I would like to make things event driven. Will need to
>>>> investigate how with git.
>>>>
>>>>
>>>> On Tuesday, August 29, 2017 at 5:33:42 PM UTC-5, Stephen Connolly wrote:
>>>>>
>>>>>
>>>>> On Tue 29 Aug 2017 at 23:21, Stephen Connolly <stephen.al...@gmail.com>
>>>>> wrote:
>>>>>
>>>>
>>>>>> On Tue 29 Aug 2017 at 22:35, Dallas Clement <dallas.a...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> If I click on the "Scan Multibranch Pipeline Now" link in the
>>>>>>> Jenkins dashboard, it will kick off a build immediately even when there
>>>>>>> were no changes. I have my declarative Jenkinsfile configured to poll
>>>>>>> for
>>>>>>> SCM changes. I only want builds to be triggered from SCM changes. Any
>>>>>>> idea how I can suppress this behavior?
>>>>>>>
>>>>>>> pipeline {
>>>>>>> agent any
>>>>>>> options {
>>>>>>> disableConcurrentBuilds()
>>>>>>> timestamps()
>>>>>>> buildDiscarder(logRotator(numToKeepStr: '8'))
>>>>>>> }
>>>>>>> triggers {
>>>>>>> // Poll every 5 minutes for new changes
>>>>>>> pollSCM 'H/5 * * * *'
>>>>>>>
>>>>>>
>>>>>> You do know in multibranch that this poll is ignored?
>>>>>>
>>>>>
>>>>> To explain why the design is this way:
>>>>>
>>>>> 1. Polling is evil
>>>>>
>>>>> 2. In most SCM implementations the poll for each branch is effectively
>>>>> a redundant check, so if you have 10 branches all polling then Jenkins
>>>>> will
>>>>> end up doing the *exact same* operation in a parallel batch of 5 (default
>>>>> polling pool size) and follow up with another batch of 5... hammering the
>>>>> SCM where one request would provide the answer for all 10 branches.
>>>>>
>>>>> 3. Branch API needs to maintain its own state as to the last revision
>>>>> built. Polling will not update that correctly.
>>>>>
>>>>> 4. Polling for Git can be a mess due to how git can be configured to
>>>>> built multiple branches in
Re: "Scan Multibranch Pipeline Now" triggers immediate build
No I don't have any post commit hook defined. Starting with a green field
here. Sounds like that's what I need to setup though.
I also don't have the "Scan Multibranch Pipeline Triggers" checkbox enabled
on my job configuration. I really don't know how it could be triggering
unless that PollSCM in my Jenkinsfile is somehow working.
On Tuesday, August 29, 2017 at 6:48:55 PM UTC-5, Stephen Connolly wrote:
>
> Sounds like you have a post commit hook pushing the commit details to
> Jenkins, in which case events are working... to confirm, check the cause of
> a build, if it says "Branch Event" then you are solid gold...
>
>
> On Wed 30 Aug 2017 at 00:42, Dallas Clement <dallas.a...@gmail.com
> > wrote:
>
>> Thanks for the info Stephen. I was not aware that the pollSCM trigger
>> was ignored in a multibranch pipeline. Something is polling for changes.
>> When someone pushes a change, a build gets triggered shortly thereafter. I
>> do agree with you that polling is evil and not scalable with many
>> branches. I would like to make things event driven. Will need to
>> investigate how with git.
>>
>>
>> On Tuesday, August 29, 2017 at 5:33:42 PM UTC-5, Stephen Connolly wrote:
>>>
>>>
>>> On Tue 29 Aug 2017 at 23:21, Stephen Connolly <stephen.al...@gmail.com>
>>> wrote:
>>>
>>
>>>> On Tue 29 Aug 2017 at 22:35, Dallas Clement <dallas.a...@gmail.com>
>>>> wrote:
>>>>
>>>>> If I click on the "Scan Multibranch Pipeline Now" link in the Jenkins
>>>>> dashboard, it will kick off a build immediately even when there were no
>>>>> changes. I have my declarative Jenkinsfile configured to poll for SCM
>>>>> changes. I only want builds to be triggered from SCM changes. Any idea
>>>>> how I can suppress this behavior?
>>>>>
>>>>> pipeline {
>>>>> agent any
>>>>> options {
>>>>> disableConcurrentBuilds()
>>>>> timestamps()
>>>>> buildDiscarder(logRotator(numToKeepStr: '8'))
>>>>> }
>>>>> triggers {
>>>>> // Poll every 5 minutes for new changes
>>>>> pollSCM 'H/5 * * * *'
>>>>>
>>>>
>>>> You do know in multibranch that this poll is ignored?
>>>>
>>>
>>> To explain why the design is this way:
>>>
>>> 1. Polling is evil
>>>
>>> 2. In most SCM implementations the poll for each branch is effectively a
>>> redundant check, so if you have 10 branches all polling then Jenkins will
>>> end up doing the *exact same* operation in a parallel batch of 5 (default
>>> polling pool size) and follow up with another batch of 5... hammering the
>>> SCM where one request would provide the answer for all 10 branches.
>>>
>>> 3. Branch API needs to maintain its own state as to the last revision
>>> built. Polling will not update that correctly.
>>>
>>> 4. Polling for Git can be a mess due to how git can be configured to
>>> built multiple branches in one job.
>>>
>>> So the decision is that polling is disabled on multibranch leaf jobs (if
>>> you have a case where it is not disabled... congratulations you have found
>>> a bug... likely not the one you thought, but a bug... polling should not
>>> happen for leaf nodes of a multibranch project)
>>>
>>> You want to have indexing at a frequency such that if an event was lost,
>>> you cannot go more than this long without the build (typically somewhere
>>> between 4-24h for most people)
>>>
>>> You want event support to trigger the builds, not polling
>>>
>>> }
>>>>>
>>>>> --
>>>>> 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/4dff0257-8170-4976-8998-13f20023e528%40googlegroups.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/4dff0257-8170-4976-8998-13f20023e528%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>&
Re: "Scan Multibranch Pipeline Now" triggers immediate build
Thanks for the info Stephen. I was not aware that the pollSCM trigger was
ignored in a multibranch pipeline. Something is polling for changes. When
someone pushes a change, a build gets triggered shortly thereafter. I do
agree with you that polling is evil and not scalable with many branches. I
would like to make things event driven. Will need to investigate how with
git.
On Tuesday, August 29, 2017 at 5:33:42 PM UTC-5, Stephen Connolly wrote:
>
>
> On Tue 29 Aug 2017 at 23:21, Stephen Connolly <stephen.al...@gmail.com
> > wrote:
>
>>
>> On Tue 29 Aug 2017 at 22:35, Dallas Clement <dallas.a...@gmail.com
>> > wrote:
>>
>>> If I click on the "Scan Multibranch Pipeline Now" link in the Jenkins
>>> dashboard, it will kick off a build immediately even when there were no
>>> changes. I have my declarative Jenkinsfile configured to poll for SCM
>>> changes. I only want builds to be triggered from SCM changes. Any idea
>>> how I can suppress this behavior?
>>>
>>> pipeline {
>>> agent any
>>> options {
>>> disableConcurrentBuilds()
>>> timestamps()
>>> buildDiscarder(logRotator(numToKeepStr: '8'))
>>> }
>>> triggers {
>>> // Poll every 5 minutes for new changes
>>> pollSCM 'H/5 * * * *'
>>>
>>
>> You do know in multibranch that this poll is ignored?
>>
>
> To explain why the design is this way:
>
> 1. Polling is evil
>
> 2. In most SCM implementations the poll for each branch is effectively a
> redundant check, so if you have 10 branches all polling then Jenkins will
> end up doing the *exact same* operation in a parallel batch of 5 (default
> polling pool size) and follow up with another batch of 5... hammering the
> SCM where one request would provide the answer for all 10 branches.
>
> 3. Branch API needs to maintain its own state as to the last revision
> built. Polling will not update that correctly.
>
> 4. Polling for Git can be a mess due to how git can be configured to built
> multiple branches in one job.
>
> So the decision is that polling is disabled on multibranch leaf jobs (if
> you have a case where it is not disabled... congratulations you have found
> a bug... likely not the one you thought, but a bug... polling should not
> happen for leaf nodes of a multibranch project)
>
> You want to have indexing at a frequency such that if an event was lost,
> you cannot go more than this long without the build (typically somewhere
> between 4-24h for most people)
>
> You want event support to trigger the builds, not polling
>
>
>> }
>>>
>>> --
>>> 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/4dff0257-8170-4976-8998-13f20023e528%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/jenkinsci-users/4dff0257-8170-4976-8998-13f20023e528%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> Sent from my phone
>>
> --
> Sent from my phone
>
--
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/c4d93f77-80ec-4f7c-a783-0947fdb3af5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
"Scan Multibranch Pipeline Now" triggers immediate build
If I click on the "Scan Multibranch Pipeline Now" link in the Jenkins
dashboard, it will kick off a build immediately even when there were no
changes. I have my declarative Jenkinsfile configured to poll for SCM
changes. I only want builds to be triggered from SCM changes. Any idea
how I can suppress this behavior?
pipeline {
agent any
options {
disableConcurrentBuilds()
timestamps()
buildDiscarder(logRotator(numToKeepStr: '8'))
}
triggers {
// Poll every 5 minutes for new changes
pollSCM 'H/5 * * * *'
}
--
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/4dff0257-8170-4976-8998-13f20023e528%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Declarative pipeline post condition 'aborted' not working.
If I manually abort a build, the 'always' and 'failure' post conditions get triggered, but never the 'aborted' post condition. I would wish for 'aborted' to work so that I can distinguish between an aborted build and a truly failed build. I only want to send email notifications for the latter case. Anybody know how to identify an aborted build? -- 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/f9f32943-cb15-4764-a8fa-537af0fe14e9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Getting the real Jenkins job status for a pipeline job.
James, how soon do you think these changes will come to fruition? Looking at the Jira issues you noted, I got the impression it might be a while. On Thursday, August 17, 2017 at 10:05:13 PM UTC-5, James Dumay wrote: > > Thats great to hear, Dallas! > > We are also making a change so that you can see from the test reporting > screen which stage and parallel was responsible for the test result. See > JENKINS-46166 <https://issues.jenkins-ci.org/browse/JENKINS-46166>. > > Without going into details, the underlying work we need to do for all of > these things is highly related. > > On Fri, Aug 18, 2017 at 12:43 AM Dallas Clement <dallas.a...@gmail.com > > wrote: > >> Hi James. This sounds like a dream come true to have status for >> individual stages and steps. In my particular situation I need to collect >> test results from a lot of bash scripts and somehow tally failure counts >> and report them back for each individual test. Will have to think some >> more about that and perhaps open a new ticket describing what I need. >> Thanks for the help. >> >> >> On Thursday, August 17, 2017 at 1:53:32 AM UTC-5, James Dumay wrote: >>> >>> Oh, and if your use case is covered by an existing ticket, providing us >>> with more context (like I described for new tickets) as a comment would be >>> fantastic. >>> >>> On Thursday, August 17, 2017 at 4:52:43 PM UTC+10, James Dumay wrote: >>>> >>>> We are working right now on making sure steps, stages, etc having >>>> individual statuses, a method for setting them at a stage/parallel level >>>> instead of for the whole pipeline and to introduce consistent behaviour >>>> for those statuses in the Blue Ocean pipeline visualisation. >>>> >>>> You can check the status for this on the roadmap >>>> <https://jenkins.io/projects/blueocean/roadmap/> "Unstable stages, >>>> parallels and steps" >>>> >>>> The tickets to watch are: >>>> * JENKINS-39203 <https://issues.jenkins-ci.org/browse/JENKINS-39203> will >>>> make all the statuses consistent, remove unstable setting the whole >>>> pipeline to unstable >>>> * JENKINS-45579 <https://issues.jenkins-ci.org/browse/JENKINS-45579> will >>>> allow you to set a stage to "unstable" using a special step (similar to >>>> the >>>> error step) >>>> >>>> If you have any other use cases in mind, please open a new ticket >>>> describing your problem. If you can describe your problem with a mock >>>> Jenkinsfile and a drawing of your desired visualization that helps narrow >>>> things down even further :) >>>> >>>> >>>> >>>> On Wednesday, August 16, 2017 at 6:47:03 PM UTC+10, Dallas Clement >>>> wrote: >>>>> >>>>> I have setup a declarative Jenkinsfile for my project. I have some >>>>> post conditions defined for success and failure. I would like to be able >>>>> to determine the job status for the previous build within the 'success' >>>>> block so that I can know if this success is a recovery from a previous >>>>> failure. I do understand that the currentBuild.result variable can be >>>>> set >>>>> at various stages and that the previous build result is available through >>>>> currentBuild.getPreviousBuild()?.getResult(). But this previous build >>>>> result seems to require the setting of currentBuild.result. >>>>> >>>>> At this point, I am more interested in accessing the actual Jenkins >>>>> job status, i.e. whatever it uses to determine whether a job has been a >>>>> success or failure and not rely on currentBuild.result. Is there some >>>>> other variable available for this? >>>>> >>>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Jenkins Users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/jenkinsci-users/3nWDhDOPrE4/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> jenkinsci-use...@googlegroups.com . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-users/d93a3cf6-1eca-4d67-80cd-16d38eef01f8%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-users/d93a3cf6-1eca-4d67-80cd-16d38eef01f8%40googlegroups.com?utm_medium=email_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > James Dumay, > Director of Product Management. > CloudBees, Inc. > Skype: jdumaycb Twitter: i386 > Meet with me: https://calendly.com/jdumay > -- 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/3b4ee108-9ecf-4977-a1a3-d3c1cecea0b4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Declarative Pipeline: How to get build cause?
I would like to be able to determine what triggered a build. It looks like build cause information is available in currentBuild.rawBuild, but can't access that from the groovy sandbox. Is there another way from a pipeline? -- 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/68d815a1-6eec-4ad2-a8e1-fae522eab04d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Getting the real Jenkins job status for a pipeline job.
Hi James. This sounds like a dream come true to have status for individual stages and steps. In my particular situation I need to collect test results from a lot of bash scripts and somehow tally failure counts and report them back for each individual test. Will have to think some more about that and perhaps open a new ticket describing what I need. Thanks for the help. On Thursday, August 17, 2017 at 1:53:32 AM UTC-5, James Dumay wrote: > > Oh, and if your use case is covered by an existing ticket, providing us > with more context (like I described for new tickets) as a comment would be > fantastic. > > On Thursday, August 17, 2017 at 4:52:43 PM UTC+10, James Dumay wrote: >> >> We are working right now on making sure steps, stages, etc having >> individual statuses, a method for setting them at a stage/parallel level >> instead of for the whole pipeline and to introduce consistent behaviour >> for those statuses in the Blue Ocean pipeline visualisation. >> >> You can check the status for this on the roadmap >> <https://jenkins.io/projects/blueocean/roadmap/> "Unstable stages, >> parallels and steps" >> >> The tickets to watch are: >> * JENKINS-39203 <https://issues.jenkins-ci.org/browse/JENKINS-39203> will >> make all the statuses consistent, remove unstable setting the whole >> pipeline to unstable >> * JENKINS-45579 <https://issues.jenkins-ci.org/browse/JENKINS-45579> will >> allow you to set a stage to "unstable" using a special step (similar to the >> error step) >> >> If you have any other use cases in mind, please open a new ticket >> describing your problem. If you can describe your problem with a mock >> Jenkinsfile and a drawing of your desired visualization that helps narrow >> things down even further :) >> >> >> >> On Wednesday, August 16, 2017 at 6:47:03 PM UTC+10, Dallas Clement wrote: >>> >>> I have setup a declarative Jenkinsfile for my project. I have some post >>> conditions defined for success and failure. I would like to be able to >>> determine the job status for the previous build within the 'success' block >>> so that I can know if this success is a recovery from a previous failure. >>> I do understand that the currentBuild.result variable can be set at >>> various stages and that the previous build result is available through >>> currentBuild.getPreviousBuild()?.getResult(). But this previous build >>> result seems to require the setting of currentBuild.result. >>> >>> At this point, I am more interested in accessing the actual Jenkins job >>> status, i.e. whatever it uses to determine whether a job has been a success >>> or failure and not rely on currentBuild.result. Is there some other >>> variable available for this? >>> >> -- 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/d93a3cf6-1eca-4d67-80cd-16d38eef01f8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Pipeline: Is SCM revision information stored with each build?
Answering my own question again. It looks like there is some API available
for getting SCM revision info in a groovy sandbox environment.
def getChanges() {
def lines = []
def changeSets = currentBuild.changeSets
for (int i = 0; i < changeSets.size(); i++) {
def entries = changeSets[i].items
for (int j = 0; j < entries.length; j++) {
def entry = entries[j]
lines.add("${entry.commitId} by ${entry.author} on ${new
Date(entry.timestamp)}: ${entry.msg}")
def files = new ArrayList(entry.affectedFiles)
for (int k = 0; k < files.size(); k++) {
def file = files[k]
lines.add("\t${file.editType.name} ${file.path}")
}
}
}
def string = ''
for (i = 0; i < lines.size(); i++) {
string += lines[i] + '\n'
}
return string
}
Trying to get this info from currentBuild.rawBuild seems nearly impossible
due to sandbox / security restrictions.
On Wednesday, August 16, 2017 at 12:46:46 PM UTC-5, Dallas Clement wrote:
>
> I know that I can get the latest revision for the current build by
> executing a shell command such as:
> def currentCommit = sh(returnStdout: true, script: 'git rev-parse
> HEAD').trim()
>
> But I would like to get the commit hash associated with a previous build.
> The reason I want to do this is so that I can list all commits associated
> with a given build since the previous build.
>
--
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/cd74bcbf-0f94-4b36-a180-4489f74bd01c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Pipeline: Is SCM revision information stored with each build?
I know that I can get the latest revision for the current build by executing a shell command such as: def currentCommit = sh(returnStdout: true, script: 'git rev-parse HEAD').trim() But I would like to get the commit hash associated with a previous build. The reason I want to do this is so that I can list all commits associated with a given build since the previous build. -- 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/30fc932b-a187-426a-b9bd-fa3c8a19b452%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Is is possible to define methods in a declarative pipeline?
I'm answering my own question here. It looks like this is indeed possible.
I added some method definitions at the end of my Jenkinsfile following the
pipeline definition. I was able to call the methods from a script {}
embedded in stages and post sections.
On Wednesday, August 16, 2017 at 11:19:40 AM UTC-5, Dallas Clement wrote:
>
> I would like to be able to define some groovy methods in my declarative
> Jenkinsfile and call as needed from a script {} section. For example I
> would like to define some methods that extract git commit information from
> the jenkins API and use when notifying concerning build status from one of
> the pipeline post conditions. Is it possible to define methods in a
> declarative pipeline?
>
--
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/75dbde18-e546-47a2-84f6-66e75ef3d991%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Is is possible to define methods in a declarative pipeline?
I would like to be able to define some groovy methods in my declarative
Jenkinsfile and call as needed from a script {} section. For example I
would like to define some methods that extract git commit information from
the jenkins API and use when notifying concerning build status from one of
the pipeline post conditions. Is it possible to define methods in a
declarative pipeline?
--
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/db56ff5f-608f-4e13-97dc-dfb446fff907%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Getting the real Jenkins job status for a pipeline job.
Thanks for these helpful ideas. Seems like this would work fine. One
last related question: How dost one trigger the 'unstable' condition in
the pipeline post section?
On Wednesday, August 16, 2017 at 11:09:12 AM UTC-5, slide wrote:
>
> You could do this with a map
>
> Map stageResults = [:]
>
> stage('Foo') {
> stageResults['Foo'] = Result.FAILURE
> }
>
> stage('Bar') {
>stageResults['Bar'] = Result.SUCCESS
> }
>
> Not ideal, but should work.
>
> On Wed, Aug 16, 2017 at 8:57 AM Victor Martinez > wrote:
>
>> Unfortunately, I'm also asking a kind of similar question:
>> - https://groups.google.com/forum/#!topic/jenkinsci-users/9UYN8FZL35k
>>
>> I haven't worked out how to do it without creating variables specifically
>> per stage
>>
>> --
>> 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/ce3fbe5c-df26-471c-a804-1d6643650b9b%40googlegroups.com
>>
>>
>> .
>> 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/0a47ebd1-1fbb-4844-891b-6dd797138787%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Getting the real Jenkins job status for a pipeline job.
Victor, you are sure right. This works like a champ! Thank you very much.
Do you know if it's possible to get the status for each stage in a
pipeline?
On Wednesday, August 16, 2017 at 10:13:46 AM UTC-5, Victor Martinez wrote:
>
> As far as I see "currentBuild.getCurrentResult()" is not null even though
> when no set was explicitly set, this is my snippet and console output
>
> pipeline {
> agent any
> stages {
> stage ('release') {
> steps {
> script {
> echo "echo currentbuild ${BUILD_ID}"
> //sh 'exit 1'
> }
> }
> }
> }
> post {
> changed {
> script {
> echo "${currentBuild.getCurrentResult()}"
> if (currentBuild.resultIsBetterOrEqualTo('SUCCESS')) {
> echo "Previous build failed
> ${currentBuild?.getPreviousBuild()?.number} and now it has been fixed"
> }
> }
> }
> }
> }
>
> [Pipeline] nodeRunning on master in
> /var/jenkins_home/workspace/_scratch/test_def[Pipeline] {[Pipeline]
> stage[Pipeline] { (release)[Pipeline] script[Pipeline] {[Pipeline] echoecho
> currentbuild 37[Pipeline] }[Pipeline] // script[Pipeline] }[Pipeline] //
> stage[Pipeline] stage[Pipeline] { (Declarative: Post Actions)[Pipeline]
> script[Pipeline] {[Pipeline] echoSUCCESS[Pipeline] echoPrevious build failed
> 36 and now it has been fixed[Pipeline] }[Pipeline] // script[Pipeline]
> }[Pipeline] // stage[Pipeline] }[Pipeline] // node[Pipeline] End of
> PipelineFinished: SUCCESS
>
>
> Cheers
>
>
--
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/4adbb842-6f3f-4605-9497-15a050a792bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Getting the real Jenkins job status for a pipeline job.
Victor, thanks for the help here. I have played with the 'changed' action
and also currentBuild.result and currentBuild?.getPreviousBuild(), but it
looks like this variable is null unless explicitly set in one of the
pipeline stages. What I really want is the status Jenkins uses to
determine which post condition is applicable, i.e. success, failure, etc.
It knows somehow, presumably based on $? values from each step.
On Wednesday, August 16, 2017 at 5:05:27 AM UTC-5, Victor Martinez wrote:
>
> Hey Dallas,
>
> Cannot you just use the changed condition
> https://jenkins.io/doc/book/pipeline/syntax/#post? Then you can use the
> http://javadoc.jenkins.io/plugin/workflow-support/org/jenkinsci/plugins/workflow/support/steps/build/RunWrapper.html#resultIsBetterOrEqualTo-java.lang.String-
>
> See the below snippet:
>
> ...
> post {
> changed {
> script {
> //
> http://javadoc.jenkins.io/plugin/workflow-support/org/jenkinsci/plugins/workflow/support/steps/build/RunWrapper.html#resultIsBetterOrEqualTo-java.lang.String-
> if (currentBuild.resultIsBetterOrEqualTo('SUCCESS')) {
> echo "Previous build failed
> ${currentBuild?.getPreviousBuild()?.number} and now it has been fixed"
> }
> }
> }
> }
> ...
>
>
> Cheers
>
--
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/f7e40755-50c6-4077-9288-a9336476f9aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Getting the real Jenkins job status for a pipeline job.
I have setup a declarative Jenkinsfile for my project. I have some post conditions defined for success and failure. I would like to be able to determine the job status for the previous build within the 'success' block so that I can know if this success is a recovery from a previous failure. I do understand that the currentBuild.result variable can be set at various stages and that the previous build result is available through currentBuild.getPreviousBuild()?.getResult(). But this previous build result seems to require the setting of currentBuild.result. At this point, I am more interested in accessing the actual Jenkins job status, i.e. whatever it uses to determine whether a job has been a success or failure and not rely on currentBuild.result. Is there some other variable available for this? -- 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/38b5f9d7-2168-4f93-be78-ff13556c3820%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Subversion plugin issues
Hello Dustin, Thanks a ton! This is the exact dilemma I have run into. Do you mind posting the contents of these two files on your system? /var/lib/jenkins/hudson.scm.SubversionSCM.xml /var/lib/jenkins/jobs/jobname/subversion.credentials I'm still a little unclear on what should go in the certificate and userName fields. Should the certificate field specify a path to the cert file? It sounds like the userName field needs to contain the realm info also. On Thu, Aug 16, 2012 at 1:07 PM, Dustin Parker dustin.a.par...@gmail.com wrote: See this issue: https://issues.jenkins-ci.org/browse/JENKINS-3912 and this forum post: https://groups.google.com/d/msg/jenkinsci-users/uA4dtvlMsCQ/FAwo2y4pI8MJ On Thursday, August 16, 2012 7:36:18 AM UTC-7, Dallas wrote: I'm trying to setup Jenkins to attach to a subversion repo that requires username/password as well as a https/pkcs#12 client cert file and passphrase. Unfortunately, the subversion scm config presents a radio button with the following choices: username/password, SSH public key, or HTTPS client cert. I've opened an issue about this JENKINS-14792. But I am seeking some more immediate relief and wanting to find a workaround or a way to hack the subversion plugin. Can anyone point me in the right direction? Thanks
