Re: Dead Plugin - Pushbullet?
Hi guys, The plugin is in a semi-comatose state. I have it working on my machine, but it depends on a library of which there are no releases yet (jpushbullet2), so anything I push to github would not be compilable as well. I will take this mail as a strong hint work with the developer of the other library to have it released to maven central. Then, I can push my local modifications as well, and we can get a working jenkins notification plugin. Regards, Hakan On Sunday, October 18, 2015 at 4:14:27 PM UTC+2, Oleg Nenashev wrote: > > Added the plugin developer to Cc. Probably he can comment the current > status. > The hosting request thread: > https://groups.google.com/forum/#!searchin/jenkinsci-dev/pushbullet/jenkinsci-dev/Zj_AidTS7j8/OF5aD0iDfakJ > > > воскресенье, 18 октября 2015 г., 8:34:01 UTC+3 пользователь Gavin написал: >> >> I was poking around at the credentials plugin, saw the pushbullet plugin. >> >> https://wiki.jenkins-ci.org/display/JENKINS/Pushbullet+Notifier+Plugin >> >> Says nothing was ever released. >> >> https://github.com/jenkinsci/pushbullet-plugin is just a barely modified >> helloworld plugin. >> >> Can/should this be deleted? >> > -- 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/76b92a5a-9200-4535-82fe-756bc1187ef4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Own credentials plugin - can I use my own icon?
Hi, I am creating a new credentials provider for pushbullet ( I have a few requirements, like fetching a list of devices to which pushes can be sent, so I can't use the plain-credentials-plugin ). On the list of credentials (Manage Jenkins - Manage Credentials - Credentials ) each credentials has a key icon. Can I replace this with my own icon for credentials managed by my plugin? Regards, Hakan -- 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: Own credentials plugin - can I use my own icon?
After having the user enter his secret (the API key from pushbullet), I want to contact the pushbullet server and fetch the devices this user has configured. And maybe, in the next version, periodically update this list. As far as I understand the plain-credentials-plugin, you can only use it to configure one secret string, but no additional information. On Friday, October 17, 2014 3:56:18 PM UTC+2, Stephen Connolly wrote: On Friday, October 17, 2014, Hakan Tandoğan hakan.t...@gmail.com javascript: wrote: Hi, I am creating a new credentials provider for pushbullet ( I have a few requirements, like fetching a list of devices to which pushes can be sent, so I can't use the plain-credentials-plugin ). Any reason that domain specifications won't work for your use case? On the list of credentials (Manage Jenkins - Manage Credentials - Credentials ) each credentials has a key icon. Can I replace this with my own icon for credentials managed by my plugin? Regards, Hakan -- 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. -- Sent from my phone -- 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: Own credentials plugin - can I use my own icon?
Because the devices actually are part of the account. At least currently, there is no way for one specific device to belong to multiple PB accounts. If I get you correctly, I would create some plugin that manages the device list, which in turn would ask the credentials providers for generic credentials, which happen to be the API key instead entered in the password field of the plain-credentials-provider. Overall, on the first consumer ( the pushbullet-notifier-plugin which I am also writing ), I lose the tight type / purpose coupling between credential and consumer. And as soon as I need a second consumer, I would need to duplicate the logic and code for obtaining the list of devices, choosing the appropriate ones etc etc etc. I guess my only defense is that having a dedicated credential type just feels tidier to me :-) On Friday, October 17, 2014 5:18:08 PM UTC+2, Stephen Connolly wrote: But why would you store the devices with the credential? It would make more sense to me that you keep the devices elsewhere and just inject a standard user/password into whatever manages the list of devices -- 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: Own credentials plugin - can I use my own icon?
Cool, I will find another place to store the device list. Thanks for your insights :-) On Friday, October 17, 2014 5:57:17 PM UTC+2, Stephen Connolly wrote: Well if your credentials are a simple type e.g. API key only, then that would be fine as a dedicated credentials type. but I still would not be putting the device stuff in the credential. So the simple rule I would like people to follow is this: If you think you need a new type, only create a new type if the value *cannot* be common with another consumer. So password's are typically common with other consumers because users can have SSO and thus the same password works on multiple systems. An application type specific key, on the other hand, that could only be used by that application, so a dedicated credential type is fine. But only store the credential... -- 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: New plugin (pushbullet-client) hosting and repository Request
During development, I realized that the plugin actually has two seperate components, one credentials provider (the existing ones don't fulfill my requirements) and one build notifier. So, could you please clone: https://github.com/hakan42/pushbullet-credentials-plugin and https://github.com/hakan42/pushbullet-notifier-plugin and, if possible, delete https://github.com/jenkinsci/pushbullet-plugin There are no releases of the plugin yet, so this should not inconvenience anyone (hopefully :-) ) Regards, Hakan On Friday, September 26, 2014 11:16:13 AM UTC+2, Ullrich Hafner wrote: Jira is down currently… Am 26.09.2014 um 11:11 schrieb Ulli Hafner ullrich...@gmail.com javascript:: Created https://github.com/jenkinsci/pushbullet-plugin Welcome aboard! Ulli Am 25.09.2014 um 11:09 schrieb Hakan Tandoğan hakan.t...@gmail.com javascript:: Hi, I'm building a new plugin to integrate pushbullet ( https://pushbullet.com ) with Jenkins. I would like to request GitHub hosting, my user there is hakan42, my project URL is https://github.com/hakan42/pushbullet-plugin . If possible, please create a JIRA component as well, my username on issues.jenkins.org is hakan Regards, Hakan -- 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.
New plugin (pushbullet-client) hosting and repository Request
Hi, I'm building a new plugin to integrate pushbullet ( https://pushbullet.com ) with Jenkins. I would like to request GitHub hosting, my user there is hakan42, my project URL is https://github.com/hakan42/pushbullet-plugin . If possible, please create a JIRA component as well, my username on issues.jenkins.org is hakan Regards, Hakan -- 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: Requesting to publish a new Jenkins plugin: CursePublish
Just out of curiosity, because your example show kerbal as game... Which addon are you using this plugin for? On Saturday, June 21, 2014 2:12:54 PM UTC+2, r04r wrote: @Oleg Sure, absolutely fine with me. On Sat, Jun 21, 2014 at 9:08 AM, Oleg Nenashev o.v.ne...@gmail.com javascript: wrote: Hello, What about renaming the plugin to: *curseforge-publisher* ? The current id (CursePublish) is not very good. The GitHub repository name in such case will be *curseforge-publisher-plugin* @r04r Do you agree with such changes? Best regards, Oleg Nenashev пятница, 20 июня 2014 г., 19:28:54 UTC+4 пользователь r04r написал: Hi all, I've been working on a plugin for Jenkins which can be found at https://github.com/r04r/CursePublisher-jenkins. This is the first Jenkins plugin that I've made, and in general I have little experience with maven so I hope that everything is in order. If not, please let me know and I will try my best to resolve it. -- 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: How do I detect my upstream job?
The users are most likely different. They might even not be authenticated at all against any user database the Jenkins instance is using. While the idea of disabling workspace permission sounds cool, I would love to avoid any access to the Jenkins instance at all. The good thing about exporting just the badge images to a sacrificial host is that people would not have access to my build server at all, thereby avoiding any vector of attack while simultanously exposing status information only about a few builds but not about the other 95% which might leak confidential information even by the name of the jobs (e.g. cust-customername.smoketest :-) ) On Monday, February 10, 2014 6:10:55 PM UTC+1, Marcelo Rebasti wrote: Hakan, Are The users in both sides of the firewall the same? If the users are different, you can disable the workspace permission for those outside the firewall and hide the passwords in the logs with https://wiki.jenkins-ci.org/display/JENKINS/Mask+Passwords+Plugin. Regards. Marcelo Rebasti On Mon, Feb 10, 2014 at 1:06 PM, Hakan Tandoğan hakan.t...@gmail.comjavascript: wrote: Hi, I have the following use case: Jenkins installation inside firewall, and the builds themselves need to be hidden because logs / workspaces might contain secret keys (e.g. OAuth keys). On the other hand, the build status of some of those jobs shall be externally visible.. My current idea is to have a post-build action that uploads the badge of it upstream (the job with the secrets) to some externally visible web site. The only thing I don't know how to do is to determine in the uploader job which job was the trigger. Any ideas except the last-ditch solution of having one uploader job per normal job? Regards, Hakan -- 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/groups/opt_out. -- 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/groups/opt_out.
How do I detect my upstream job?
Hi, I have the following use case: Jenkins installation inside firewall, and the builds themselves need to be hidden because logs / workspaces might contain secret keys (e.g. OAuth keys). On the other hand, the build status of some of those jobs shall be externally visible.. My current idea is to have a post-build action that uploads the badge of it upstream (the job with the secrets) to some externally visible web site. The only thing I don't know how to do is to determine in the uploader job which job was the trigger. Any ideas except the last-ditch solution of having one uploader job per normal job? Regards, Hakan -- 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/groups/opt_out.
Re: Suspending a Jenkins client for a period of time? with connection to Jenkins server kept alive?
Hi,
In your slave configuration, what did you select for Availability? I'm
guessing that you use Keep this slave on-line as much as possible, which
would explain the immediate restart you are seeing.
You could configure Take this slave on-line accoring to a schedule, and
set the scheduling before killing the slave. Or something like that, you
would have to experiment a bit there. Or even use the take on-line when in
demand.
Regards,
Hakan
On Tuesday, November 26, 2013 11:18:00 AM UTC+1, Kishore RP wrote:
when i run the above the jenkins slave console(jnlp) is not killed but
keeps trying every 10 seconds :-(, we dont want that to happen, we just
want to kill the jnlp client and bring it up again once our tests are done.
When i used the below instead of kill,
println('\tcomputer.disconnect: ' +
aSlave.getComputer().disconnect(offlineCause = new
OfflineCause.ChannelTermination()));
the jnlp client of slave terminates and reconnects in few seconds.
Thoughts?
Thank you for your help all along
--
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/groups/opt_out.
How can I put jelly translation files into Messages.properties?
Hi, if I understand https://wiki.jenkins-ci.org/display/JENKINS/Internationalization correctly, the translations for Jelly files seem to have to be placed in seperate property files per class. On the other hand, there is the big Messages.properties, of which only one per plugin seems to exist. Is there a way to put every translatable resource into Messages.properties? This would look tidier to me :-) Regards, Hakan -- 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/groups/opt_out.
Re: AW - *PLEASE READ* Re: strange pushes on GitHub
I pushed transifex-plugin.git from my local tree, all fine for this plugin now. Regards, Hakan On Sunday, November 10, 2013 7:55:08 PM UTC+1, lucamilanesio wrote: *The solution* I can raise a request to GitHub to provide the reflog of those repositories and restore the branches to the point before my forced push. *Alternatively the owners of those repositories can still perform a forced push to restore the correct position of the branches.* (if you would like to do so, *please write to the mailing list so that we do not overlap the recovery operations*) -- 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/groups/opt_out.
Re: How do I keep cloudbees from building the gh-pages branch
The site build job you have created does not seem to run on git changes like the main one does. Could this be added please? On Thursday, October 31, 2013 2:08:50 PM UTC+1, nicolas de loof wrote: I created https://jenkins.ci.cloudbees.com/job/plugins/job/transifex-plugin-site/as a short term fix will check if we could have such a site generation job for all plugin, that we could link from wiki as part of plugin informations. will also check how to exclude some branches. I can imagine a comparable issue with svn branch some plugin still have. Maybe would be simpler to introduce this option in git plugin 2013/10/31 nicolas de loof nicolas...@gmail.com javascript: 2013/10/31 Hakan Tandoğan hakan.t...@gmail.com javascript: Both would be good solutions. Especially the first so I don't have to run that job on my own build server :-) Will check this option. Unfortunately, for the second one, I cannot log in to jenkins.ci to exclude gh-pages, so this is something someone at cloudbees would have to do (maybe globally for all jenkins plugin jobs build on that jenkins instance?) sure, I'll. Regards, Hakan On Thursday, October 31, 2013 1:48:57 PM UTC+1, nicolas de loof wrote: This is to publish maven generated site, isn't it ? Maybe we could just add this to the ci job and publish on jenkins.ci.cloudbees.com using html report plugin, so you don't have to manage it and update gh-pages other option is to exclude gh-pages from monitored branches, git-plugin allows to pass a regex, need to double check how to get all branches but gh-pages 2013/10/31 Hakan Tandoğan hakan.t...@gmail.com Hi, I keep the maven site report of my transifex plugin ( https://github.com/**jenkinsci/transifex-pluginhttps://github.com/jenkinsci/transifex-plugin) in the gh-pages branch of my source repository. Unfortunately, any site generation and push to this branch causes a build to be performed on cloudbees ( https://jenkins.ci.**cloudbees.com/job/plugins/job/** transifex-plugin/https://jenkins.ci.cloudbees.com/job/plugins/job/transifex-plugin/ ). Is there a way to tell cloudbees that certain branches should not be built? I already thought about putting a very basic, nearly empty pom into the gh-pages as well but this would dilute any build success information I would have on the cloudbees job. Regards, Hakan -- 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/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- 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/groups/opt_out. -- 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/groups/opt_out.
How do I keep cloudbees from building the gh-pages branch
Hi, I keep the maven site report of my transifex plugin ( https://github.com/jenkinsci/transifex-plugin ) in the gh-pages branch of my source repository. Unfortunately, any site generation and push to this branch causes a build to be performed on cloudbees ( https://jenkins.ci.cloudbees.com/job/plugins/job/transifex-plugin/ ). Is there a way to tell cloudbees that certain branches should not be built? I already thought about putting a very basic, nearly empty pom into the gh-pages as well but this would dilute any build success information I would have on the cloudbees job. Regards, Hakan -- 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/groups/opt_out.
Re: How do I keep cloudbees from building the gh-pages branch
Both would be good solutions. Especially the first so I don't have to run that job on my own build server :-) Unfortunately, for the second one, I cannot log in to jenkins.ci to exclude gh-pages, so this is something someone at cloudbees would have to do (maybe globally for all jenkins plugin jobs build on that jenkins instance?) Regards, Hakan On Thursday, October 31, 2013 1:48:57 PM UTC+1, nicolas de loof wrote: This is to publish maven generated site, isn't it ? Maybe we could just add this to the ci job and publish on jenkins.ci.cloudbees.com using html report plugin, so you don't have to manage it and update gh-pages other option is to exclude gh-pages from monitored branches, git-plugin allows to pass a regex, need to double check how to get all branches but gh-pages 2013/10/31 Hakan Tandoğan hakan.t...@gmail.com javascript: Hi, I keep the maven site report of my transifex plugin ( https://github.com/jenkinsci/transifex-plugin ) in the gh-pages branch of my source repository. Unfortunately, any site generation and push to this branch causes a build to be performed on cloudbees ( https://jenkins.ci.cloudbees.com/job/plugins/job/transifex-plugin/ ). Is there a way to tell cloudbees that certain branches should not be built? I already thought about putting a very basic, nearly empty pom into the gh-pages as well but this would dilute any build success information I would have on the cloudbees job. Regards, Hakan -- 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/groups/opt_out. -- 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/groups/opt_out.
JIRA component for transifex-plugin please
Hi, I'm just about to create the first alpha of my transifex-plugin ( https://github.com/jenkinsci/transifex-plugin ). So, may I kindly ask for a matching JIRA component? My username on issues.jenkins.org is hakan. Regards, Hakan -- 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/groups/opt_out.
New plugin (transifex-client) Hosting and Repository Request
Hi, I'm building a new plugin to integrate transifex ( https://transifex.com ) with Jenkins. I would like to request GitHub hosting, my user there is hakan42, my project URL is https://github.com/hakan42/transifex-plugin . Regards, Hakan -- 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/groups/opt_out.
