Re: Failing a build from within BuildWrapper setUp
From the javadoc: public BuildWrapper.Environment http://javadoc.jenkins-ci.org/hudson/tasks/BuildWrapper.Environment.html setUp(AbstractBuild http://javadoc.jenkins-ci.org/hudson/model/AbstractBuild.html build, Launcher http://javadoc.jenkins-ci.org/hudson/Launcher.html launcher, BuildListener http://javadoc.jenkins-ci.org/hudson/model/BuildListener.html listener) throws IOException http://download.oracle.com/javase/6/docs/api/java/io/IOException.html?is-external=true, InterruptedException http://download.oracle.com/javase/6/docs/api/java/lang/InterruptedException.html?is-external=true Returns:non-null if the build can continue, null if there was an error and the build needs to be aborted. Vincent 2014-10-01 23:16 GMT+02:00 Stuart Rowe stuartr...@gmail.com: Hi, Does anyone how to cause a build to fail during BuildWrapper setUp? For my purposes I want to be able to detect situations during this setup where the build shouldn't continue. Is this possible? I've tried setting the buildResult on the AbstractBuild object passed into setUp. This successfully fails the build, but not until after build steps have been performed. Thanks -- 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. 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. For more options, visit https://groups.google.com/d/optout.
Re: email-ext option suggestion
Ok. thank-you Slide for update.
On Wednesday, 1 October 2014 23:08:25 UTC+8, slide wrote:
As I mentioned before, if you add email addresses to the user accounts, it
will not use the mail resolvers to find it and will be much faster.
On Wed, Oct 1, 2014 at 6:42 AM, Venkat Prasad venkat@gmail.com
javascript: wrote:
We usually notify 50+ users it takes over 30mins to finish job from Sending
email to ... step.
So thought of check with you.
On Wednesday, 1 October 2014 00:46:48 UTC+8, slide wrote:
No, I don't think I'll do this. The best thing to do if you want to
bypass the mail address resolution through all the address resolvers is to
add an email address to the user in Jenkins.
On Tue, Sep 30, 2014 at 8:40 AM, Venkat Prasad venkat@gmail.com
wrote:
Hi Slide,
We have come across that your email-ext plugin resolves users email
address from LDAP.
its takes the lot of time to complete job if in case of more recipients.
Can you please provide an option not to resolve from LDAP that just
appends defaultSuffix?
https://github.com/jenkinsci/email-ext-plugin/blob/master/
src/main/java/hudson/plugins/emailext/EmailRecipientUtils.java
public static String getUserConfiguredEmail(User user) {
String addr = null;
if(user != null) {
Mailer.UserProperty mailProperty = user.getProperty(Mailer.
UserProperty.class);
if (mailProperty != null) {
addr = mailProperty.getAddress();
String message = String.format(Resolved %s to %s,
user.getId(), addr);
LOGGER.fine(message);
}
}
return addr;
}
Best regards,
Venkat
--
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-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Website: http://earl-of-code.com
--
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-de...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/d/optout.
--
Website: http://earl-of-code.com
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: Need of access to upload new plugin.
Hi Domi, i Thought this was clear due to the wiki pages, but i guess i still need to update it a bit more. Basicly the jabber plugin can only send normal and group events, but no pubsub. Since our company had previously written elOyente to pick up xmpp Pubsub messages, and trigger builds based upon this info. We've quickly written the complimentory plugin to be able to send pubsub messages. If i find the time later on, i'd like to merge both the ElOyente and the ElBoca plugin in to one. But at this moment, i don't have the time do to so. However the ElBoca plugin can also be incorporated into the Jabber messenger plugin. Don't know how the rest of the community feels about this? Suggestions are always welcome. Kind regards, Jacobs Dennis. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [WIKI] Plugin stats not updated in 3 months
Hi Kohsuke, sorry for bothering you with this stats issue again, but I wasn't sure who's taking care of this part of the Jenkins infrastructure. Best, Jan On Wednesday, 24 September 2014 13:33:15 UTC+1, Jan Molak wrote: Hi all, It seems that plugin stats on the Jenkins wiki haven't been updated since June (according to timestamps at http://stats.jenkins-ci.org/plugin-installation-trend/). Is this someone needs to kick manually, if so, should it be automated? And if that's the case is any help needed with that? Best, Jan -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Gradle JPI Plugin Released
Hi Daniel it all works fine with my two plugins selenium-axis-plugin https://github.com/jenkinsci/selenium-axis-plugin and an unreleased rebuild at run time demo axis plugin (in the Chuck Norris style) https://github.com/JeremyMarshall/chuck-norris-axis-plugin What changes are there? Regards Jeremy -- 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. For more options, visit https://groups.google.com/d/optout.
Re: envinject plugin pull request #33
Ping. On 29-09-2014 13:03, Thomas Sondergaard wrote: Hi, I made the following pull request a week ago and I was hoping someone here could do a review of it. https://github.com/jenkinsci/envinject-plugin/pull/33 The bug I filed prior to the pull request: https://issues.jenkins-ci.org/browse/JENKINS-24785 Pull request message (also git commit comment): For multi-configuration jobs the BUILD_CAUSE passed in the environment to build scripts is always UPSTREAMTRIGGER. Introduce ROOT_BUILD_CAUSE that expands UpstreamCause to the root causes. Update required jenkins version to 1.482 to get Cause.UpstreamCause.getUpstreamCauses(). Thanks, Thomas -- 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. For more options, visit https://groups.google.com/d/optout.
Re: dashbeats-plugin
Hi Christian, Jenkins Build widget is a Dashing widget to show a build status and progress only, by doing a pull from Jenkins. Does it aggregate all build stats and display rate of failure or number of failures? DashBeats is a Jenkins plugin to push data to Dashing widgets using BFA stats aggregation. A Dashing dashboard is under development actually, using specific widgets to display relevant information. It can use indeed Jenkins Build widget if we need such. Based on business feedback, we are evaluating the need of storing all stats and raw logs into an external database, and use elasticSearch/Kibana to display them as an alternative to Dashing. That being said, the effort we will put into this will depend on business needs. Br Kong On Tuesday, September 30, 2014 10:03:51 PM UTC+2, Christian Galsterer wrote: Hi, not sure why one need a new plugin. To update a Widget in Dashing a simple curl would do it. Wouldn't a simple Execute Shell Script not be enough? Have you checked out Jenkins Build Widget https://gist.github.com/mavimo/6334816 which shows the build status for specified Jenkins builds. We use this in 10+ dashboards with several 100 of builds polling every 1 minute without a problem. Just wanted to let you that there is already an option to display Jenkins build status with dashing. Br Christian On Wednesday, September 24, 2014 10:24:26 PM UTC+2, Kong To wrote: Hi Ullrich, Would you please add 2 maintainers to this repo. GitHub ids : scoheb https://github.com/scoheb and marco-miller. Kong On Wednesday, September 17, 2014 5:39:42 PM UTC-4, Ullrich Hafner wrote: Created https://github.com/jenkinsci/dashbeats-plugin Welcome aboard! Ulli Am 17.09.2014 um 15:18 schrieb Kong To newli...@gmail.com: Hi Ullrich, We do see interest in making this plugin available to the community and will create a wiki for this. Our organization's need is to display build stats on a screen. Actually this plugin publishes stats to Dashing. Jenkins users may find it usefull and may customise their own Dashing dashboards or widgets. Kong On Wednesday, September 17, 2014 6:52:39 AM UTC-4, Ullrich Hafner wrote: Is this plugin only relevant to your organization? Am 15.09.2014 um 16:27 schrieb Kong To newli...@gmail.com: Hi, Within our orgnization (Ericsson), we care going to create a new plugin and would like to host it on Jenkinsci. GitHub plugin name : dashbeats-plugin GitHub id: newlight77 Existing GitHub: https://github.com/newlight77/dashbeats-plugin Kong -- 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-de...@googlegroups.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-de...@googlegroups.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. For more options, visit https://groups.google.com/d/optout.
Re: Need of access to upload new plugin.
Hi Dennis, thanks for the update! If you'r already thinking about merging the plugins, then I would strongly suggest not to publish anything before that - users will only be confused. I also think that history has shown that most of the original promises to merge plugins actually never happen after a first release. If you don't have time to do the merge right now, then just use your current implementation on your own installation as a private build, because as soon as you publish it a maintainer is required for the plugin too. ...just my 2cent... regards Domi On 02.10.2014, at 09:22, Dennis Jacobs jcbs.d...@gmail.com wrote: Hi Domi, i Thought this was clear due to the wiki pages, but i guess i still need to update it a bit more. Basicly the jabber plugin can only send normal and group events, but no pubsub. Since our company had previously written elOyente to pick up xmpp Pubsub messages, and trigger builds based upon this info. We've quickly written the complimentory plugin to be able to send pubsub messages. If i find the time later on, i'd like to merge both the ElOyente and the ElBoca plugin in to one. But at this moment, i don't have the time do to so. However the ElBoca plugin can also be incorporated into the Jabber messenger plugin. Don't know how the rest of the community feels about this? Suggestions are always welcome. Kind regards, Jacobs Dennis. -- 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. 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. For more options, visit https://groups.google.com/d/optout.
Can't get access to the release button of the debian-package-builder-plugin in cloudbees
That job: https://jenkins.ci.cloudbees.com/job/plugins/job/debian-package-builder-plugin/ Either I do not have the permission or I am logging in wrong. I've tried doing that with both google ID and github ID and all I can get is You are not authorized to use this Jenkins instance. I assume I should have the described access since I'm a maintainer of that plugin. Can plz someone help? -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Disk Usage Plugin Suggestion
Hi, yes it is possible to add such option into configuration. Unfortunately I will not have a time to add this option soon, but you can send me pull request. I will happy to merge it. Do you have such overload due to a lot of builds (disk usage calculate only directory of build in described situation)? It could be caused by recalculation task too. There are 2 ways how calculate disk space - calculate it when build is finished or recalculate it for each build(job). Recalculation is set as periodic task. If the problem is caused by recalculation I suggest not to perform it often (you can set it in global configuration). Regards, Lucka Dne čtvrtek, 2. října 2014 6:01:04 UTC+2 Venkat Prasad napsal(a): We are facing job failures due to an error, Disk usage plugin fails during calculation disk usage of this build. Jenkins ver 1.572, Disk usage plugin ver .23 At present this plugin records disk usage for all the jobs, and it takes much of system resources. Our suggestion, Can you please provide an option in job configuration itself to enable disk-usage? -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Need of access to upload new plugin.
Hi Dominik, First off all, i'd like to thank you for your fast feedback. Now i can re-prioritize my tasks, so that the merge is at the top of my todo-list. But there is one issue I am somewhat hesitant about, and which i'd like to avoid if possible. Namely the fact that both the el-oyente and the el-boca plugins extend the jabber-plugin in an indirect manner meaning that they both provide/extend the xmpp-functionality with pubsub-features. However since the eloyente plugin actually triggers builds based on the pubsub-event, there is more to it than just recieving pubsub-events. Therefore it could be that extending the jabber-plugin is a wrong approach. Is this correct, or am i still missing something? Also I have read that in order to publish a plugin, it should have a maintainer. Does this imply that i am (or will become) the maintainer? Or how are these things regulated? Regards, Jacobs Dennis. On Thursday, October 2, 2014 11:25:01 AM UTC+2, Dominik Bartholdi wrote: Hi Dennis, thanks for the update! If you'r already thinking about merging the plugins, then I would strongly suggest not to publish anything before that - users will only be confused. I also think that history has shown that most of the original promises to merge plugins actually never happen after a first release. If you don’t have time to do the merge right now, then just use your current implementation on your own installation as a private build, because as soon as you publish it a maintainer is required for the plugin too. …just my 2cent... regards Domi On 02.10.2014, at 09:22, Dennis Jacobs jcbs...@gmail.com javascript: wrote: Hi Domi, i Thought this was clear due to the wiki pages, but i guess i still need to update it a bit more. Basicly the jabber plugin can only send normal and group events, but no pubsub. Since our company had previously written elOyente to pick up xmpp Pubsub messages, and trigger builds based upon this info. We've quickly written the complimentory plugin to be able to send pubsub messages. If i find the time later on, i'd like to merge both the ElOyente and the ElBoca plugin in to one. But at this moment, i don't have the time do to so. However the ElBoca plugin can also be incorporated into the Jabber messenger plugin. Don't know how the rest of the community feels about this? Suggestions are always welcome. Kind regards, Jacobs Dennis. -- 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-de...@googlegroups.com javascript:. 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. For more options, visit https://groups.google.com/d/optout.
Re: Help : Make a new release for dependency-analyzer-plugin
Hy all. Just some news. I saw that the version on my local pom was 0.8-SNAPSHOT but not in Github. Because, I really do not understand anything, I was not able to fix that. So, I have deleted my local repository and re import it. I add to remove the Github tag also. Then i run again the release:prepare and release:perform This time, I have a tag with version 0.7 and the version in master branch is 0.8-SNAPSHOT. Now, I will wait couple hours to see if this release will be taken. Really, coming from SVN to GIT is not so simple. For sure i need to read the documentation. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Help : Make a new release for dependency-analyzer-plugin
Good news there is something here : http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/dependencyanalyzer/0.7/ -- 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. For more options, visit https://groups.google.com/d/optout.
We must handle security advisories better
I already gave Kohsuke these opinions in person yesterday, but I don't think this is solely his problem so I wanted to bring it up on the dev mailing list. It's important to me that this is a constructive discussion and we talk about how we can do things better moving forward. IMO there's a few problems with the way we have handled security advisories in the past: * Low feedback times to researchers who discover vulnerabilities. One example I found in core, the submitter of the SECURITY issue did not get feedback for one calendar month on the issue. This is a problem as some security researchers are of the opinion that if they don't hear back from a vendor in a timely manner, they should disclose to the public in order to get the hole closed. * Lack of transparency to the Jenkins community into the SECURITY project in JIRA. I'm not of the opinion that SECURITY should be a publicly visible project in JIRA but we *must* come up with some criteria to give people access that prevents Kohsuke from being the only one paying attention. * Vendor notification, by virtue of Kohsuke being a Cloudbees employee they were aware and able to update in a timely manner, but I do not believe we communicated with vendors like Shining Panda CI, who rely on publicly facing Jenkins instances, that there was a big release coming before it was publicly announced. I don't think we should tell all companies using Jenkins before a public announcement, but I do think that maintaining a list of companies and organizations that run Jenkins as a public service should get a few hours of lead time. I have some ideas on what we can do to improve this. As some of you may know I work for Lookout, a mobile security company, and I can probably rope in members of our research team if need be to provide insight from the security research perspective, the ones disclosing vulnerabilities, if you all have questions there. - R. Tyler Croy -- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F -- pgpJDfJa0F0pe.pgp Description: PGP signature
Re: We must handle security advisories better
On 2 October 2014 16:59, R. Tyler Croy ty...@monkeypox.org wrote: I already gave Kohsuke these opinions in person yesterday, but I don't think this is solely his problem so I wanted to bring it up on the dev mailing list. It's important to me that this is a constructive discussion and we talk about how we can do things better moving forward. IMO there's a few problems with the way we have handled security advisories in the past: * Low feedback times to researchers who discover vulnerabilities. One example I found in core, the submitter of the SECURITY issue did not get feedback for one calendar month on the issue. This is a problem as some security researchers are of the opinion that if they don't hear back from a vendor in a timely manner, they should disclose to the public in order to get the hole closed. Yep. No disagreement that this is an issue. * Lack of transparency to the Jenkins community into the SECURITY project in JIRA. I'm not of the opinion that SECURITY should be a publicly visible project in JIRA but we *must* come up with some criteria to give people access that prevents Kohsuke from being the only one paying attention. There is a mailing list of people... they all seem rather quiet a lot of the time... granted I am one of those people too... so tarring myself with the same brush * Vendor notification, by virtue of Kohsuke being a Cloudbees employee they were aware and able to update in a timely manner, but I do not believe we communicated with vendors like Shining Panda CI, If it is critical to them, then they should ask to be part of the security-cert list. I do not see anyone stopping responsible parties from being advised. OTOH if they are relying on us to do all the donkey work and then complaining that we are a little bit more prepared because of that donkey work... I have slightly less sympathy. In general I find the community involvement on the jenkins-cert list less vocal than I would like to see. There are some things I would expect to see more vocal responses to... who rely on publicly facing Jenkins instances, that there was a big release coming before it was publicly announced. I don't think we should tell all companies using Jenkins before a public announcement, but I do think that maintaining a list of companies and organizations that run Jenkins as a public service should get a few hours of lead time. If you are on the cert list you would have had all of the LTS RC testing as foreknowledge... at least for the CVE-2014-3666 (if you have not upgraded your Jenkins to a version with the fix for that by the time you read this... stop what you are doing and upgrade it already) I have some ideas on what we can do to improve this. As some of you may know I work for Lookout, a mobile security company, and I can probably rope in members of our research team if need be to provide insight from the security research perspective, the ones disclosing vulnerabilities, if you all have questions there. - R. Tyler Croy -- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F -- -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Can't get access to the release button of the debian-package-builder-plugin in cloudbees
Plugin owners don’t have access to this CI instance, only a few core developers have access. Am 02.10.2014 um 13:53 schrieb Ivan Kalinin pupss...@gmail.com: That job: https://jenkins.ci.cloudbees.com/job/plugins/job/debian-package-builder-plugin/ Either I do not have the permission or I am logging in wrong. I've tried doing that with both google ID and github ID and all I can get is You are not authorized to use this Jenkins instance. I assume I should have the described access since I'm a maintainer of that plugin. Can plz someone help? -- 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. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Help : Make a new release for dependency-analyzer-plugin
Guys. Thank you all for all your inputs and help. Finally the new version is in the update center. Le jeudi 2 octobre 2014 16:05:50 UTC+2, Etienne Jouvin a écrit : Good news there is something here : http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/dependencyanalyzer/0.7/ -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Failing a build from within BuildWrapper setUp
Thanks! I saw that in the javadoc, but misinterpreted it as meaning that the build would be marked as aborted. On Wednesday, 1 October 2014 23:15:09 UTC-7, Vincent Latombe wrote: From the javadoc: public BuildWrapper.Environment http://javadoc.jenkins-ci.org/hudson/tasks/BuildWrapper.Environment.html setUp(AbstractBuild http://javadoc.jenkins-ci.org/hudson/model/AbstractBuild.html build, Launcher http://javadoc.jenkins-ci.org/hudson/Launcher.html launcher, BuildListener http://javadoc.jenkins-ci.org/hudson/model/BuildListener.html listener) throws IOException http://download.oracle.com/javase/6/docs/api/java/io/IOException.html?is-external=true, InterruptedException http://download.oracle.com/javase/6/docs/api/java/lang/InterruptedException.html?is-external=true Returns:non-null if the build can continue, null if there was an error and the build needs to be aborted. Vincent 2014-10-01 23:16 GMT+02:00 Stuart Rowe stuar...@gmail.com javascript:: Hi, Does anyone how to cause a build to fail during BuildWrapper setUp? For my purposes I want to be able to detect situations during this setup where the build shouldn't continue. Is this possible? I've tried setting the buildResult on the AbstractBuild object passed into setUp. This successfully fails the build, but not until after build steps have been performed. Thanks -- 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-de...@googlegroups.com javascript:. 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. For more options, visit https://groups.google.com/d/optout.
Re: We must handle security advisories better
(replies inline) On Thu, 02 Oct 2014, Stephen Connolly wrote: On 2 October 2014 16:59, R. Tyler Croy ty...@monkeypox.org wrote: I already gave Kohsuke these opinions in person yesterday, but I don't think this is solely his problem so I wanted to bring it up on the dev mailing list. It's important to me that this is a constructive discussion and we talk about how we can do things better moving forward. IMO there's a few problems with the way we have handled security advisories in the past: * Low feedback times to researchers who discover vulnerabilities. One example I found in core, the submitter of the SECURITY issue did not get feedback for one calendar month on the issue. This is a problem as some security researchers are of the opinion that if they don't hear back from a vendor in a timely manner, they should disclose to the public in order to get the hole closed. Yep. No disagreement that this is an issue. Do you have any ideas on how we can improve the feedback times? Is it just a matter of getting more people involved in the SECURITY project? * Lack of transparency to the Jenkins community into the SECURITY project in JIRA. I'm not of the opinion that SECURITY should be a publicly visible project in JIRA but we *must* come up with some criteria to give people access that prevents Kohsuke from being the only one paying attention. There is a mailing list of people... they all seem rather quiet a lot of the time... granted I am one of those people too... so tarring myself with the same brush Here I was thinking I was on, or knew of, every Jenkins mailing list. Is there another list I'm not aware where security issues are discussed? On a related note, how are plugin developers who maintain plugins which have vulnerabilities disclosed against them looped into these conversations? * Vendor notification, by virtue of Kohsuke being a Cloudbees employee they were aware and able to update in a timely manner, but I do not believe we communicated with vendors like Shining Panda CI, If it is critical to them, then they should ask to be part of the security-cert list. I do not see anyone stopping responsible parties from being advised. OTOH if they are relying on us to do all the donkey work and then complaining that we are a little bit more prepared because of that donkey work... I have slightly less sympathy. In general I find the community involvement on the jenkins-cert list less vocal than I would like to see. See previous comments about non-public lists. I'm not sure we need to do any donkey work to feed updates to vendors relying on Jenkins, I think having a process where somebody can sign up for pre-release notifications for public Jenkins instances would be valuable. I would imagine that the Shining Panda folks, OpenStack, FreeBSD, ASF and a number of other organizations would gladly fill out a form to subscribe to early access to security notifications or fixes. who rely on publicly facing Jenkins instances, that there was a big release coming before it was publicly announced. I don't think we should tell all companies using Jenkins before a public announcement, but I do think that maintaining a list of companies and organizations that run Jenkins as a public service should get a few hours of lead time. If you are on the cert list you would have had all of the LTS RC testing as foreknowledge... at least for the CVE-2014-3666 (if you have not upgraded your Jenkins to a version with the fix for that by the time you read this... stop what you are doing and upgrade it already) - R. Tyler Croy -- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F -- pgppVg8ARWHMB.pgp Description: PGP signature
Re: We must handle security advisories better
On Thu, Oct 2, 2014 at 7:23 PM, R. Tyler Croy ty...@monkeypox.org wrote: Do you have any ideas on how we can improve the feedback times? Is it just a matter of getting more people involved in the SECURITY project? By all means, if they are motivated to do serious investigations when issues come in. Is there another list I'm not aware where security issues are discussed? jenkinsci-cert, limited to those people who can also see the SECURITY component. On a related note, how are plugin developers who maintain plugins which have vulnerabilities disclosed against them looped into these conversations? Not very well. Currently we cannot even add them on CC to the JIRA issue, which makes it difficult to handle these. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Request to publish a Jenkins plug-in
Hi Jenkins Dev Team, Any update on my request to host a new plugin. Thanks, Kishore On Monday, 29 September 2014 14:46:39 UTC+5:30, Krishna Kishore wrote: Due to different dependencies we decided not to extend the functionality of the existing plugin but write a new plugin. The existing plugin implements the SCM extension point of Jenkins and the new plugin is much more lighter and uses the Build extension point. The target audience for the two plugins is also different. Their are some common aspects and we are looking a best ways to create a common layer that can be used by the two plugins. Thanks, Kishore On Monday, 29 September 2014 11:03:54 UTC+5:30, Dominik Bartholdi wrote: How about extending the existing one with your functionality? From a users point of view this is what I would love to see - as I guess you would provite of some of the existing features too Or maybe extract the parts the two plugins would have in common and create a base plugin which can be extended by implementing EPs Domi On 28.09.2014, at 16:01, Krishna Kishore clkki...@gmail.com wrote: Hi, The existing plugin woks with the RTC Source control, it helps teams which use RTC as SCC and Jenkins as CI engine. The new plugin will work with projects which use Git as source control and integrate (i.e create traceability links) Jenkins builds with RTC Work Items and Builds. This plugin is for teams which use Git as Source control and want to use RTC for Tracking and Planning. Thanks, Kishore On Sunday, 28 September 2014 12:37:47 UTC+5:30, Dominik Bartholdi wrote: How is this one different to the existing teamconcert plugin? [1] It seems very active. Domi [1] https://wiki.jenkins-ci.org/display/JENKINS/Team+Concert+Plugin Am 28.09.2014 um 06:09 schrieb Krishna Kishore clkki...@gmail.com: Hi Jenkins Dev team, I am with the Rational Team Concert(RTC) Development team in IBM ( www.ibm.com, www.jazz.net). We are developing a plugin which will integrate Jenkins Builds using Git as Source control to RTC Work items and builds. We would like to publish the plugin at jenkins-ci.org. Here are the details related to plugin Plugin Name: Team Concert Git Plugin Github Repository: https://github.com/clkkishore/teamconcert-git-plugin Github id: clkkishore Plugin Description: Integrates Jenkins with Rational Team Concert for Jenkins Builds which use Git as source control. This plugin will create traceability links from a Jenkins build to RTC work items and build result. Can someone please clone this to jenkinsci and provide me access for the same. Thanks In advance, Regards, Kishore PS: Currently the project https://github.com/clkkishore/teamconcert-git-plugin contains only a readme file will add the sources once the repository is cloned into jenkinssci space. -- 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-de...@googlegroups.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-de...@googlegroups.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. For more options, visit https://groups.google.com/d/optout.
Re: Request to publish a Jenkins plug-in
done: https://github.com/jenkinsci/teamconcert-git-plugin but creating a component for you in the issue tracker failed, what is your userid in JIRA? ...I don't have permission to create a CI job, can someone else create one? Domi On 03.10.2014, at 06:19, Krishna Kishore clkkish...@gmail.com wrote: Hi Jenkins Dev Team, Any update on my request to host a new plugin. Thanks, Kishore On Monday, 29 September 2014 14:46:39 UTC+5:30, Krishna Kishore wrote: Due to different dependencies we decided not to extend the functionality of the existing plugin but write a new plugin. The existing plugin implements the SCM extension point of Jenkins and the new plugin is much more lighter and uses the Build extension point. The target audience for the two plugins is also different. Their are some common aspects and we are looking a best ways to create a common layer that can be used by the two plugins. Thanks, Kishore On Monday, 29 September 2014 11:03:54 UTC+5:30, Dominik Bartholdi wrote: How about extending the existing one with your functionality? From a users point of view this is what I would love to see - as I guess you would provite of some of the existing features too Or maybe extract the parts the two plugins would have in common and create a base plugin which can be extended by implementing EPs Domi On 28.09.2014, at 16:01, Krishna Kishore clkki...@gmail.com wrote: Hi, The existing plugin woks with the RTC Source control, it helps teams which use RTC as SCC and Jenkins as CI engine. The new plugin will work with projects which use Git as source control and integrate (i.e create traceability links) Jenkins builds with RTC Work Items and Builds. This plugin is for teams which use Git as Source control and want to use RTC for Tracking and Planning. Thanks, Kishore On Sunday, 28 September 2014 12:37:47 UTC+5:30, Dominik Bartholdi wrote: How is this one different to the existing teamconcert plugin? [1] It seems very active. Domi [1] https://wiki.jenkins-ci.org/display/JENKINS/Team+Concert+Plugin Am 28.09.2014 um 06:09 schrieb Krishna Kishore clkki...@gmail.com: Hi Jenkins Dev team, I am with the Rational Team Concert(RTC) Development team in IBM (www.ibm.com, www.jazz.net). We are developing a plugin which will integrate Jenkins Builds using Git as Source control to RTC Work items and builds. We would like to publish the plugin at jenkins-ci.org. Here are the details related to plugin Plugin Name: Team Concert Git Plugin Github Repository: https://github.com/clkkishore/teamconcert-git-plugin Github id: clkkishore Plugin Description: Integrates Jenkins with Rational Team Concert for Jenkins Builds which use Git as source control. This plugin will create traceability links from a Jenkins build to RTC work items and build result. Can someone please clone this to jenkinsci and provide me access for the same. Thanks In advance, Regards, Kishore PS: Currently the project https://github.com/clkkishore/teamconcert-git-plugin contains only a readme file will add the sources once the repository is cloned into jenkinssci space. -- 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-de...@googlegroups.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-de...@googlegroups.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. 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. For more options, visit https://groups.google.com/d/optout.
