Re: GitHub and Bitbucket branch source UI refactoring
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
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 HENRYwrote: > 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
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?
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?
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
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
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
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
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.