from:"Tim Downey"

Re: GitHub and Bitbucket branch source UI refactoring

2017-08-03 Thread Tim Downey

Hi Michael -- I finally go around to upgrading as well and am facing the 
same problem.  Have you worked around this?  Are you just supplying the XML 
directly?

On Tuesday, July 11, 2017 at 8:39:29 PM UTC-4, Michael Kobit wrote:
>
> Finally got some time to try it out (sorry!) and I know the PR has already 
> been merged, but UI looks great, and the contextual help menus make it 
> easy to pick up. Awesome job!
>
> Only thing I noticed is no built-in Job DSL support - we use the Job DSL 
> entirely to create and setup all of our Organization folders, and I didn't 
> see any generated DSL methods under 
> */plugin/job-dsl/api-viewer/index.html#path/organizationFolder-organizations-bitbucket*
> .
>
> On Thu, Jun 29, 2017 at 9:43 AM Mark Waite  > wrote:
>
>> I think I have detected the difference between by multi-branch pipelines 
>> with GitHub branch sources.
>>
>> The problem job is a GitHub private repository (
>> https://github.com/MarkEWaite/jenkins-bugs-private), while the working 
>> job is a GitHub public repository (
>> https://github.com/MarkEWaite/jenkins-bugs) .
>>
>> When I configure the private repository job, it presents the list of 
>> repositories but only includes public repositories in the list.  The 
>> credentials are valid and are used in other jobs, but it is as though the 
>> list of repositories is not being refreshed with the credentials.
>>
>> Mark Waite
>>
>> On Thu, Jun 29, 2017 at 8:27 AM Mark Waite > > wrote:
>>
>>> I'm using latest betas (as far as I can tell).  The GitHub source is now 
>>> working in the cases that were failing previously.  Thanks very much for 
>>> that!
>>>
>>> Unfortunately, when I open the "Configure" page for one of my 
>>> multi-branch pipeline job that is using GitHub as a branch source, it 
>>> reverts the repository choice to the top of the list, instead of showing 
>>> the originally selected repository.
>>>
>>> When I open the "Configure" page for another of my multi-branch pipeline 
>>> jobs that is using GitHub as a branch source, it retains the repository 
>>> choice.
>>>
>>> Unfortunately, I don't know what is different between those two cases of 
>>> a GitHub branch source for a multi-branch pipeline.
>>>
>>> I'll let you know if I identify key attributes which make the two cases 
>>> behave differently.
>>>
>>> Mark Waite 
>>>
>>>
>>> On Monday, June 26, 2017 at 10:04:00 PM UTC-6, Michael Neale wrote:

 I retested with latest betas and looking good (binary compat, migration 
 etc). 

 On Monday, June 26, 2017 at 11:46:49 PM UTC+10, Stephen Connolly wrote:
>
>
>
> On 26 June 2017 at 06:13, Kevin Burnett  
> wrote:
>
>> This is so good. :)
>>
>
> Great to hear it. I love feedback (+ve or -ve beats none)
>  
>
>>
>> The pre and post diffs looked right, and the new UI and functionality 
>> gives me everything that I was hoping for.
>>
>
> w00t
>  
>
>>
>> I'm going to remove the "discover pull requests from [everywhere]" 
>> behaviors and select "Only branches that are also filed as PRs" on 
>> production as soon as possible.
>>
>> Michael Neale mentioned that one issue he had seen "does look better 
>> now with the new version." I used the plugin versions that Stephen 
>> originally posted on June 20, but I take Michael's comment to mean there 
>> might be newer versions. Please make this irrelevant by issuing release 
>> versions of these plugins this week. :)
>>
>> Thanks a ton!
>> -KB
>>
>> On Friday, June 23, 2017 at 12:45:44 PM UTC-4, Stephen Connolly wrote:
>>>
>>>
>>>
>>> On 23 June 2017 at 17:24, Mark Waite  wrote:
>>>
 I see duplicate entries in the "Add' configuration of the Bitbucket 
 source for "Checkout over ssh".  Let me know if you need steps to see 
 that.

>>>
>>> Shouldn't... may just be a bug in the drop down populator when you 
>>> have GitHub and Bitbucket
>>>  
>>>

 I also wonder if the text "General", "Git" and "Bitbucket" should 
 be italicized, or bold, or separated with dashes, or something, so 
 that the 
 user has a concept that things will be appearing under them.  They 
 seem to 
 be standard text currently, and it wasn't obvious to me that they were 
 categories into which settings would be placed.

>>>
>>> Cannot style the drop-down menu without significant JS changes that 
>>> risk affecting form binding.
>>>  
>>>

 Mark Waite


 On Friday, June 23, 2017 at 9:58:52 AM UTC-6, Mark Waite wrote:
>
> The UI experience has been great for me in the two or three places 
> where I've used it.  I was a little surprised (and pleased) with the

Re: [RFF] SonarQube Scanner for Jenkins 2.6

2017-03-21 Thread Tim Downey

Hi Julien,

'steps' is part of declarative pipeline which is becoming the
recommendation from the Jenkins folks on how to write your Jenkinsfiles.

https://jenkins.io/doc/book/pipeline/

Tim

On Tue, Mar 21, 2017 at 4:29 AM, Julien HENRY 
wrote:

> Hi,
>
> Can you tell me what is this "steps" keyword? When I try to use it I get
> NoSuchMethodError: No such DSL method 'steps'
>
> Also, what is the point of the script block?
>
> In short, what happen if you simplify your script to:
>
> stage ("SonarQube analysis") {
>STAGE_NAME = "SonarQube analysis"
>
>if (BRANCH_NAME == "develop") {
>   echo "In 'develop' branch, don't analyze."
>}
>else { // this is a PR build, run sonar analysis
>   withSonarQubeEnv("SonarGate") {
>  sh "../../../sonar-scanner-2.9.0.670/bin/sonar-scanner"
>   }
>}
>   }
>
>   stage ("SonarQube Gatekeeper") {
>STAGE_NAME = "SonarQube Gatekeeper"
>
>if (BRANCH_NAME == "develop") {
>   echo "In 'develop' branch, skip."
>}
>else { // this is a PR build, fail on threshold spill
>   def qualitygate = waitForQualityGate()
>   if (qualitygate.status != "OK") {
>  error "Pipeline aborted due to quality gate coverage 
> failure: ${qualitygate.status}"
>   }
>}
>   }
>
>
>
> 2017-03-20 23:46 GMT+01:00 Idan Adar :
>
>> I'd like to join the growing number of users unable to make this work...
>>
>> Jenkins 2.5
>> SonarQube 6.2
>> 1 master and 1 slave machine
>>
>> The following fails with: java.lang.IllegalStateException: Unable to get
>> SonarQube task id and/or server name. Please use the 'withSonarQubeEnv'
>> wrapper to run your analysis.
>>
>>
>> stage ("SonarQube analysis") {
>>  steps {
>> script {
>>STAGE_NAME = "SonarQube analysis"
>>
>>if (BRANCH_NAME == "develop") {
>>   echo "In 'develop' branch, don't analyze."
>>}
>>else { // this is a PR build, run sonar analysis
>>   withSonarQubeEnv("SonarGate") {
>>  sh "../../../sonar-scanner-2.9.0.670/bin/sonar-scanner"
>>   }
>>}
>> }
>>  }
>>   }
>>
>>   stage ("SonarQube Gatekeeper") {
>>  steps {
>> script {
>>STAGE_NAME = "SonarQube Gatekeeper"
>>
>>if (BRANCH_NAME == "develop") {
>>   echo "In 'develop' branch, skip."
>>}
>>else { // this is a PR build, fail on threshold spill
>>   def qualitygate = waitForQualityGate()
>>   if (qualitygate.status != "OK") {
>>  error "Pipeline aborted due to quality gate coverage 
>> failure: ${qualitygate.status}"
>>   }
>>}
>> }
>>  }
>>   }
>>
>>
>>
>> I did also post more information on StackOverflow, but given that there
>> hasn't been any interaction there, I'll just mention here as well...
>> https://stackoverflow.com/questions/42909439/using-waitforqu
>> alitygate-in-a-jenkins-declarative-pipeline
>>
>>
>> On Wednesday, February 22, 2017 at 5:02:24 PM UTC+2, Julien HENRY wrote:
>>>
>>> Hi,
>>>
>>> I would like to collect feedback before the upcoming release of the
>>> SonarQube Scanner for Jenkins.
>>>
>>> The main new feature is that we introduced a new pipeline step that
>>> would put the pipeline in pause until SonarQube analysis is finished, and
>>> the step will then give access to the quality gate status. You can then
>>> implement any logic you want.
>>>
>>> Example:
>>>   stage("build & SonarQube analysis") {
>>>   node {
>>>   withSonarQubeEnv('My SonarQube Server') {
>>>  sh 'mvn clean package sonar:sonar'
>>>   }
>>>   }
>>>   }
>>>
>>>   stage("Quality Gate"){
>>>   timeout(time: 1, unit: 'HOURS') {
>>>   def qg = *waitForQualityGate()*
>>>   if (qg.status != 'OK') {
>>>   error "Pipeline aborted due to quality gate failure:
>>> ${qg.status}"
>>>   }
>>>   }
>>>   }
>>>
>>> You can test using this artifact:
>>> https://repox.sonarsource.com/sonarsource-public-builds/org/
>>> jenkins-ci/plugins/sonar/2.6-build1166/sonar-2.6-build1166.hpi
>>>
>>> Documentation is available directly on the step in the pipeline snippet
>>> generator.
>>>
>>> Feedback period is open until Friday.
>>>
>>> Regards,
>>>
>>> Julien
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/jenkinsci-dev/7so6S2mAhzg/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the

Re: [RFF] SonarQube Scanner for Jenkins 2.6

2017-02-22 Thread Tim Downey

Hi Julien,

This is terrific, but I'm having issues.  I'm trying to use this within a 
pipeline model definition build.  I'm struggling with `waitForQualityGate`. 
 Wherever I put it, I'm getting an exception.  I've tried the 
`waitForQualityGate` both in the same and in separate stages.  Any 
suggestions?

java.lang.IllegalStateException: Unable to get SonarQube task id and/or server 
name. If you are not using the 'withSonarQubeEnv' wrapper to run your analysis, 
you have to pass the attributes manually to this step.
at 
org.sonarsource.scanner.jenkins.pipeline.WaitForQualityGateStep$Execution.processStepParameters(WaitForQualityGateStep.java:127)
at 
org.sonarsource.scanner.jenkins.pipeline.WaitForQualityGateStep$Execution.start(WaitForQualityGateStep.java:107)


stage('sonar-build') {

steps {
script {
withSonarQubeEnv('VantageSonar') {
sh 'mvn clean package sonar:sonar'

def qg = waitForQualityGate()
if (qg.status != 'OK') {
  error "Pipeline aborted due to quality gate 
failure: ${qg.status}"
}
}
}
}
}Enter code here...


On Wednesday, February 22, 2017 at 10:02:30 AM UTC-5, Julien HENRY wrote:
>
> Hi,
>
> I would like to collect feedback before the upcoming release of the 
> SonarQube Scanner for Jenkins.
>
> The main new feature is that we introduced a new pipeline step that would 
> put the pipeline in pause until SonarQube analysis is finished, and the 
> step will then give access to the quality gate status. You can then 
> implement any logic you want.
>
> Example:
>   stage("build & SonarQube analysis") {
>   node {
>   withSonarQubeEnv('My SonarQube Server') {
>  sh 'mvn clean package sonar:sonar'
>   }
>   }
>   }
>   
>   stage("Quality Gate"){
>   timeout(time: 1, unit: 'HOURS') {
>   def qg = *waitForQualityGate()*
>   if (qg.status != 'OK') {
>   error "Pipeline aborted due to quality gate failure: 
> ${qg.status}"
>   }
>   }
>   }
>
> You can test using this artifact:
>
> https://repox.sonarsource.com/sonarsource-public-builds/org/jenkins-ci/plugins/sonar/2.6-build1166/sonar-2.6-build1166.hpi
>
> Documentation is available directly on the step in the pipeline snippet 
> generator.
>
> Feedback period is open until Friday.
>
> Regards,
>
> Julien
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/19027f4d-2246-4c35-b71c-9a9ef20abee2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adopt flowdock plugin?

2017-02-21 Thread Tim Downey

And here's the PRthanks.

https://github.com/jenkinsci/flowdock-plugin/pull/27


On Tuesday, February 21, 2017 at 7:51:18 AM UTC-5, Tim Downey wrote:
>
> Thanks Oleg.  I got a bounce from Antti and wasn't sure if we was still 
> with the company.
>
> Hello Mark & Antti -- I'm interested in helping out with the Flowdock 
> plugin.  I have a few enhancements in progress, one is for configurable 
> content and subjects as opposed to the auto-generated content and another 
> is direct support for Jenkins pipeline.  I have a PR ready for the first 
> and will submit.
>
> Thanks!
> Tim
>
>
> On Tue, Feb 21, 2017 at 6:56 AM, Oleg Nenashev  wrote:
>
>> Hi Tim,
>>
>> So the first step is to try contacting the current maintainer and 
>> FlowDock just to get feedback from them.
>>
>> I have added Antti Pitkanen to Cc. In addition, I have added Mark Waite 
>> to Cc. He is an active Jenkins contributor and also the director at CA 
>> technologies, which owns FlowDock now. So I suppose he is the best entry 
>> point if Antti is not available.
>>
>> Best regards,
>> Oleg
>>
>>
>> понедельник, 20 февраля 2017 г., 19:53:10 UTC+1 пользователь Tim Downey 
>> написал:
>>>
>>> Hi all,
>>>
>>> I wasn't sure on the process for adopting a potentially abandoned 
>>> plugin.  I'm interest in adopting the flowdock plugin if in fact it is 
>>> abandoned.  I reached out to the maintainer from the wiki, but got a bounce 
>>> and can see that there are several outstanding PRs.  I have a change just 
>>> about ready for a PR as well.  I'd be happy to adopt the plugin but wasn't 
>>> quite sure on the etiquette for finding out if a plugin has been abandoned.
>>>
>>> https://wiki.jenkins-ci.org/display/JENKINS/Flowdock+Plugin
>>>
>>> Thanks!
>>> Tim
>>>
>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/jenkinsci-dev/DzzY2SNheIk/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/9d1548c8-0f06-4b6d-b28a-59a460d36212%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/9d1548c8-0f06-4b6d-b28a-59a460d36212%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/416d6894-a712-4f4d-852e-c88c80e449a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adopt flowdock plugin?

2017-02-21 Thread Tim Downey

Thanks Oleg.  I got a bounce from Antti and wasn't sure if we was still
with the company.

Hello Mark & Antti -- I'm interested in helping out with the Flowdock
plugin.  I have a few enhancements in progress, one is for configurable
content and subjects as opposed to the auto-generated content and another
is direct support for Jenkins pipeline.  I have a PR ready for the first
and will submit.

Thanks!
Tim


On Tue, Feb 21, 2017 at 6:56 AM, Oleg Nenashev <o.v.nenas...@gmail.com>
wrote:

> Hi Tim,
>
> So the first step is to try contacting the current maintainer and FlowDock
> just to get feedback from them.
>
> I have added Antti Pitkanen to Cc. In addition, I have added Mark Waite to
> Cc. He is an active Jenkins contributor and also the director at CA
> technologies, which owns FlowDock now. So I suppose he is the best entry
> point if Antti is not available.
>
> Best regards,
> Oleg
>
>
> понедельник, 20 февраля 2017 г., 19:53:10 UTC+1 пользователь Tim Downey
> написал:
>>
>> Hi all,
>>
>> I wasn't sure on the process for adopting a potentially abandoned
>> plugin.  I'm interest in adopting the flowdock plugin if in fact it is
>> abandoned.  I reached out to the maintainer from the wiki, but got a bounce
>> and can see that there are several outstanding PRs.  I have a change just
>> about ready for a PR as well.  I'd be happy to adopt the plugin but wasn't
>> quite sure on the etiquette for finding out if a plugin has been abandoned.
>>
>> https://wiki.jenkins-ci.org/display/JENKINS/Flowdock+Plugin
>>
>> Thanks!
>> Tim
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/jenkinsci-dev/DzzY2SNheIk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/9d1548c8-0f06-4b6d-b28a-59a460d36212%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/9d1548c8-0f06-4b6d-b28a-59a460d36212%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAJp9yiM%2BBDDkjJncZ3njhW3i%2BHA7sYF50M-%2Bqu6N1AXjJ-FqsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Questions on updating flowdock plugin to support pipeline

2016-11-08 Thread Tim Downey

Ok, that helps.  Thanks again.

And for anyone searching the mailing list in the future, here's the
relevant bit for post build activity from the Pipeline Model Definition
plugin.

https://github.com/jenkinsci/pipeline-model-definition-plugin/wiki/Notifications


On Mon, Nov 7, 2016 at 6:56 PM, Jesse Glick <jgl...@cloudbees.com> wrote:

> On Mon, Nov 7, 2016 at 4:23 PM, Tim Downey <timothy.dow...@gmail.com>
> wrote:
> > under pipeline,
> > traditional Notifiers would not be used and instead flow control around
> > build status should be inside of the pipeline as opposed to the plugin?
>
> Right.
>
> > also
> > seems to require the most work for pipeline script writers
>
> See Pipeline Model Definition plugin.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/jenkinsci-dev/kI0BtRoE7kM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CANfRfr0ZKnJvuQwva_Q6tbBnPWEwh-2jmsPC4z-oTT5P_
> TmgZw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAJp9yiND7VD4kWSfnB%2BhSg0Jm7pf7VayigQByX%2BwBVjETpJRKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Questions on updating flowdock plugin to support pipeline

2016-11-07 Thread Tim Downey

Ok, so you're saying the convention would be that under pipeline,
traditional Notifiers would not be used and instead flow control around
build status should be inside of the pipeline as opposed to the plugin?  In
other words, instead of having the flowdockNotifier() figure out what to do
based on build status (from within the plugin), I should instead just
require the pipeline script writer to pass the correct args based on the
pipeline script logic directly (using try, catch logic in the pipeline)?

I can see that doing so would provide the most flexibility, but it also
seems to require the most work for pipeline script writers.  A specific
example would be crafting the logic to notify of a "fixed" build from a
pipeline.  As of now, the plugin does the work to determine if a build has
transitioned from failed to success and is now "fixed".  If that work is
now the job of the pipeline script, it will certainly complicate things and
result in lots of duplication and variance from one persons pipeline to
anothers.

That said, I appreciate the feedback and am still trying to digest what
folks are looking for in terms of idiomatic pipeline code.

Thanks for your time,
Tim

On Mon, Nov 7, 2016 at 3:52 PM, Jesse Glick <jgl...@cloudbees.com> wrote:

> On Mon, Nov 7, 2016 at 2:26 PM, Tim Downey <timothy.dow...@gmail.com>
> wrote:
> > The issue is that run.getResult() is returning null even when used in a
> > pipeline *after* which the build should have failed (e.g. after failing
> to
> > pass unit tests or compilation).  I'm wondering if there is something I
> need
> > to do to ensure that I get the proper build result from the job and have
> > this step run only after that.
>
> For a `SimpleBuildStep` this would apply:
>
> https://github.com/jenkinsci/workflow-basic-steps-plugin/
> blob/master/CORE-STEPS.md#interacting-with-build-status
>
> but you are apparently writing a `Step`, so:
>
> > Is there something
> > different I should be doing to ensure that the flowdockNotifier is only
> run
> > after we've received some sort of build result?  The Flowdock plugin
> > traditionally has been a Notifier and run as a post build action.
>
> It is generally the responsibility of the script to decide whether or
> not to run a given publisher and with what settings. Avoid calling
> `Run.getResult`.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/jenkinsci-dev/kI0BtRoE7kM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CANfRfr2igFVJW-gMuaUvrFW%2Btf-874Cx3CaRY1yD1FzJRYemLg%
> 40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAJp9yiPJ4ikd288qvNQMzsmknmv8sNYAN3V1rDRsiSOZRp_2VA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Questions on updating flowdock plugin to support pipeline

2016-11-07 Thread Tim Downey

Hi Jesse,

I'm hoping you can point me in the right direction for one more thing.  I'm 
trying to understand at what point in the pipeline process does the build 
result (via run.getResult()) become available?  As you can see below, I'm 
calling the original FlowdockNotifier code in a step execution in order to 
be able to use the "legacy" plugin in a pipeline.  I'm including two blocks 
below.  First is how it's being used in a pipeline, and the second is the 
step execution code.

The issue is that run.getResult() is returning null even when used in a 
pipeline *after* which the build should have failed (e.g. after failing to 
pass unit tests or compilation).  I'm wondering if there is something I 
need to do to ensure that I get the proper build result from the job and 
have this step run only after that.

Here's the pipeline.  In this example, I was assuming that by running the 
flowdockNotifier in the pipeline, I'd already have the correct build result 
in place as a result of the mvn build in the previous section.  Instead, 
I'm getting null for run.getResult() no matter what.  Is there something 
different I should be doing to ensure that the flowdockNotifier is only run 
after we've received some sort of build result?  The Flowdock plugin 
traditionally has been a Notifier and run as a post build action.

try {
sshagent([config.gitCredentials]) {

withMaven(maven: 'Maven', mavenLocalRepo: '.repository', 
mavenSettingsConfig: 
'org.jenkinsci.plugins.configfiles.maven.MavenSettingsConfig1450194231885') 
{
sh "mvn versions:set -DnewVersion=${version}"
sh "mvn clean install"
}
  }

 } catch (err) {
mail body: "Please go to ${BUILD_URL} and verify the build." ,
from: config.email,
replyTo: config.email,
subject: "Build failed in Jenkins: ${JOB_NAME} ${version}",
to: config.recipients

throw err
} finally {
// Post build items here -- build will have already passed or 
failed by now?
flowdockNotifier(flowToken: 'myflowdocktoken', 
notificationTags: "jenkins, ${JOB_NAME}",
chatNotification:true, notifyFailure: true)

}

Here's the step execution.

*public* *static* *class* Execution *extends* 
AbstractSynchronousStepExecution {

   @StepContextParameter *private* *transient* Launcher launcher;

   @StepContextParameter *private* *transient* FilePath workspace;

   @StepContextParameter *private* *transient* TaskListener listener;

   @StepContextParameter *private* *transient* Run run;

   @StepContextParameter *private* *transient* EnvVars env;

   @Inject(optional=*true*) *private* *transient* FlowdockNotifierStep 
step;

@Override

   *protected* Void run() *throws* Exception {

   listener.getLogger().println("Running flowdock notifier.");

   FlowdockNotifier notifier = *new* FlowdockNotifier(step.flowToken
,

step.notificationTags, 

convertToString(step.chatNotification),

convertToString(step.notifySuccess),

convertToString(step.notifyFailure),

convertToString(step.notifyFixed),

convertToString(step.notifyUnstable), 

convertToString(step.notifyAborted),

convertToString(step.notifyNotBuilt));

   notifier.perform(run, workspace, launcher, listener);

*return* *null*;

   }

*private* *static* *final* *long* *serialVersionUID* = 1L;

*private* *static* String convertToString(Boolean bool) {

  *return* bool != *null* ? bool.toString() : *null*;

   }

   }

Thanks for any help,
Tim

On Tuesday, November 1, 2016 at 5:55:55 PM UTC-4, Jesse Glick wrote:
>
> On Tue, Nov 1, 2016 at 2:04 PM, Tim Downey <timothy...@gmail.com 
> > wrote: 
> >if(build.getProject().getRootProject() != build.getProject()) { 
> >projectName = 
> > build.getProject().getRootProject().getDisplayName(); 
> >configuration = " on " + build.getProject().getDisplayName(); 
> >} else { 
> >projectName = build.getProject().getDisplayName(); 
> >} 
> > 
> > 
> > From the call, I've switched the fromBuild method to take Run 
> instead 
> > of AbstractProject 
>
> Instead of `AbstractBuild` I suppose you mean. 
>
> > but the issue is that I'm not clear on what needs to be 
> > done in the conditional.  The existing code seems to be trying to figure 
> out

Questions on updating flowdock plugin to support pipeline

2016-11-01 Thread Tim Downey

Hi,

I'm working on updating the Flowdock plugin to support pipeline and am 
getting hung up in how to map some of the old calls to the new API.  In 
general, I've gone through and replaced AbstractProject with Run. 
 I've got a few hangups that I was hoping that someone with direct 
knowledge could help me through.

I have this:

*public* *static* ChatMessage fromBuild(Run build, BuildResult 
buildResult, TaskListener listener) {

ChatMessage msg = *new* ChatMessage();

StringBuilder content = *new* StringBuilder();

String projectName = "";

String configuration = "";

   

   *if*(build.getProject().getRootProject() != build.getProject()) {

   projectName = build.getProject().getRootProject().getDisplayName
();

   configuration = " on " + build.getProject().getDisplayName();

   } *else* {

   projectName = build.getProject().getDisplayName();

   }

>From the call, I've switched the fromBuild method to take Run instead 
of AbstractProject, but the issue is that I'm not clear on what needs to be 
done in the conditional.  The existing code seems to be trying to figure 
out if it is the root project in order to construct the message (which will 
be sent to flowdock) but I'm not sure what the equivalent would be when 
working from Run instead of AbstractProject.

I have a similar problem with trying to figure out ChangeSets here, 
although it looks like I found some code on this forum to go after the 
changesets via reflection.

*public* *static* List parseCommits(Run build) {

*final* ChangeLogSet cs = build.getChangeSet();

*if*(cs == *null* || cs.isEmptySet())

   *return* *null*;

List commits = *new* ArrayList();

*for* (*final* Entry entry : cs) {

   // reverse order in order to have recent commits first

   commits.add(0, entry);

   }

*return* commits;

   }

Thanks for any suggestions!
Tim

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/a2b2c6d0-5aaa-45f2-ba3d-dcad7caabfb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub and Bitbucket branch source UI refactoring

Re: [RFF] SonarQube Scanner for Jenkins 2.6

Re: [RFF] SonarQube Scanner for Jenkins 2.6

Re: Adopt flowdock plugin?

Re: Adopt flowdock plugin?

Re: Questions on updating flowdock plugin to support pipeline

Re: Questions on updating flowdock plugin to support pipeline

Re: Questions on updating flowdock plugin to support pipeline

Questions on updating flowdock plugin to support pipeline

9 matches

Site Navigation

Mail list logo

Footer information