AW: Problems releasing plugin "[ERROR] ssh: Could not resolve hostname : Name or service not known"

Hello everybody, I am still unable to release our plugin. As described I can release to GitHub if I omit the password and user name parameters but copying to the Jenkins maven repository fails. If I declare Dusername and Dpassword mvn release will fail to push anything to GitHub because it

Re: Problems releasing plugin "[ERROR] ssh: Could not resolve hostname : Name or service not known"

Do you have the credentials for the maven repo defined in your settings.xml as described here? https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-Releasingtojenkinsci.org Domi > On 19 Oct 2015, at 08:34, Joachim Kuhnert wrote: > > Hello

Re: Proposal: Use the same DSL for the job-dsl-plugin and for the workflow-plugin

So this has been brought up before - I think it'd be a good thing if it's viable. I'm honestly not sure how hard it'd be, though... A. On Sat, Oct 17, 2015 at 11:43 PM, Stefan Wolf wrote: > Hi, > > both the job-dsl-plugin and the workflow plugin are using a groovy-DSL to >

AW: Problems releasing plugin "[ERROR] ssh: Could not resolve hostname : Name or service not known"

Thank you very much, this solved the problem. It is a little bit embarrassing that I did forget about the settings.xml, because I did read the wiki page and it seems to be optional. But of course you need this entry if you omit the username and password parameter. So thank you again for

Re: Submit all custom views after a restart Jenkins

Ok, So if I want to do the apply thing (to update my json files). The best way would be to do in the Initializer a foreach on views and do a deleteView and addView. I will check that. On Friday, October 16, 2015 at 6:01:26 PM UTC+2, Robert Sandell wrote: > > Well what I was suggesting was to

Start process on slave

I am writing a Jenkins CI plugin. It runs on the slave machine where I want to start a process. I tried this by writing the following code inside the invoke method in a FileCallable: ArgumentListBuilder args = new ArgumentListBuilder(); args.addTokenized(nsisExecutable.toString() + "

Re: 2.0 proposal

+1000 (having had to dance around the @AdaptField on private fields called "id" in Jenkins 1.602+ more times than I'd care to recall already this year) On 19 October 2015 at 14:13, James Nord wrote: > Hi all, > > So we have strived to keep Jenkins backwards compatible and

Backporting for 1.625.2 has started

Hi, Backporting for next LTS release started. The RC will be published 2015-10-28. Candidates: https://issues.jenkins-ci.org/issues/?filter=12146 Fixed: https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%201.625.2-fixed -- oliver -- You received this message because you are

Re: Upgrading Plugin to use Credentials

On Sat, Oct 17, 2015 at 1:40 PM, Gavin wrote: > I won't turn down any examples on upgrading to credentials though. `ssh-plugin` IIRC. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and

Re: Proposal: Use the same DSL for the job-dsl-plugin and for the workflow-plugin

On Sat, Oct 17, 2015 at 5:43 PM, Stefan Wolf wrote: > the main advantage of the workflow approach is that you > can instantiate plugins and these do not depend on the workflow plugin > itself. The main disadvantage is that the dsl you obtain is not very nice. See

This week's office hours: FOSDEM Planning

I've posted this to the blog already here: But this wednesday at 11:00am PDT I'll be hosting a Google Hangout during the scheduled office hours to plan for FOSDEM 2016. I'd love for anybody interested in

Looking for some help with a baffling plugin bug (ansicolor)

Myself and the maintainers of the jenkins-ansicolor plugin have been struggling with a weird bug. So far I am the only one who can reproduce it, and I can only repro it on my production Jenkins server. A seemingly-identical test server does not exhibit the bug. We seem to have exhausted most

Re: 2.0 proposal

On Monday, October 19, 2015 at 9:19:44 PM UTC+2, Jesse Glick wrote: > > On Mon, Oct 19, 2015 at 2:19 PM, Kohsuke Kawaguchi > wrote: > > Queue.Item.id has known fixed set of subtypes, so we can restrict the > rewrite to a much smaller subset. > > Not sure I follow that.

Re: 2.0 proposal

The part about proactively changing non-private fields is too reckless. It presumably breaks a significant number of plugins, and it does so for no good reasons. I say no good reasons because most of these fields need not be adopted ever. IIUC, the pain that motivated you is the side effect of

Re: Request to host plugin: delphix-jenkins-plugin

That makes sense. Could I get the name to be delphix-plugin for the repository in the jenkinsci organization and keep the current name for the repository on our company github since it does make sense on our company github? I have the LICENSE folder in the root of the git repository, and I

Request to host plugin: delphix-jenkins-plugin

Hello everyone! First time doing this, and I'm doing this based off the wiki. I have a plugin that I would like to be hosted on jenkins-ci.org. The plugin interacts with the Delphix Engine which is the core product that my company sells. Our product allows for customers to spin up virtual

Re: Adopt-a-plugin!

Yes, but you can nominate any plugin for this by adding the label. I'll later go through the more popular plugins to populate the list. On 19.10.2015, at 20:44, Baptiste Mathus wrote: > LGTM. > Hence IIUC only one plugin currently up for adoption right? > > -- Baptiste > >

Re: Request to host plugin: delphix-jenkins-plugin

On 19.10.2015, at 20:44, Peter Vilim wrote: > That makes sense. Could I get the name to be delphix-plugin for the > repository in the jenkinsci organization and keep the current name for the > repository on our company github since it does make sense on our company >

Re: 2.0 proposal

That all makes sense, though to implement that we need a policy to remove deprecated API first. Removing non-private fields should be done by deprecating it first. I am tracking [1] for this effort. I would like to have a look at early deprecated API use detection. [1]

Re: 2.0 proposal

On Mon, Oct 19, 2015 at 2:19 PM, Kohsuke Kawaguchi wrote: > Queue.Item.id has known fixed set of subtypes, so we can restrict the rewrite > to a much smaller subset. Not sure I follow that. IIUC the problem is outside references to `id`. The number of subtypes of `Item` (and

Re: Adopt-a-plugin!

LGTM. Hence IIUC only one plugin currently up for adoption right? -- Baptiste Le 16 oct. 2015 4:39 PM, "Daniel Beck" a écrit : > > On 05.10.2015, at 17:04, Daniel Beck wrote: > > > Hi everyone, > > > > One problem that's been apparent for a while is that

Re: Looking for some direction on global.jelly testing

Just letting anyone reading this know that I've simple created a workaround of using page.getElementsByName to resolve this. Wiki updated and ticket updated and closed. Mike -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To

Re: Request to host plugin: delphix-jenkins-plugin

I have updated the source files to include the Apache 2.0 copyright header. I also modified the shortName in the build.gradle which overrides the directory name and set it to be delphix-plugin. I also verified that the plugin that was produced had the name delphix-plugin.hpi after building.

Re: 2.0 proposal

2015-10-19 12:19 GMT-07:00 Jesse Glick : > On Mon, Oct 19, 2015 at 2:19 PM, Kohsuke Kawaguchi wrote: > > Queue.Item.id has known fixed set of subtypes, so we can restrict the > rewrite to a much smaller subset. > > Not sure I follow that. IIUC the problem

Re: Adopt-a-plugin!

On 19.10.2015, at 20:54, Daniel Beck wrote: > I'll later go through the more popular plugins to populate the list. I added the first batch of plugins. Check out the list @

Proposal: revisiting JUC in 2016

Putting my CloudBees hat on, I'd like to discuss the following proposed changes to the events in 2016, where we are moving away from JUC into a new model. https://wiki.jenkins-ci.org/display/JENKINS/Proposal+-+Revisiting+JUC+in+2016 I put this up for the project meeting agenda in 1.5 week, but I

Re: [JENKINS-19524] Request for review of pull request for MultiJob plugin

Hi, Just tell me his JIRA id. I'll check and update the configuration. BR, Oleg On Oct 20, 2015 06:52, "Haggai Philip Zagury" wrote: > Itai or should be default assignee- who is in charge of configuring Jira ? > > > Thanks HP > > On Oct 4, 2015, at 12:28, Oleg

Re: Adopt-a-plugin!

What do we do with plugins belonging to Kohsuke? I doubt he has any time to maintain them. On Oct 20, 2015 02:25, "Daniel Beck" wrote: > > On 19.10.2015, at 20:54, Daniel Beck wrote: > > > I'll later go through the more popular plugins to populate the list. >

Re: Adopt-a-plugin!

How is https://wiki.jenkins-ci.org/display/JENKINS/SCP+plugin different from the Publish Over SCP Plugin? Maybe as part of this exercise, we should look at deprecating some of the plugins? On Mon, Oct 19, 2015 at 4:25 PM Daniel Beck wrote: > > On 19.10.2015, at 20:54, Daniel

fixing tied label get/set vs configuration page

I've been looking at some issues for the configurationslicing plugin, and one that came up is https://issues.jenkins-ci.org/browse/JENKINS-29547 which says the configuration slice for 'tied label' ignores the value 'master'. It looks like this is an issue with core jenkins, as I commented in the

Looking for some direction on global.jelly testing

Hi there, I'm happy to do the work but looking for a bit of direction (or help). I started with an issue.. https://issues.jenkins-ci.org/browse/WEBSITE-10 Someone suggested I move my question here So.. here goes.. asking it in the dev group now. I could update the documentation after

Re: 2.0 proposal

On Mon, Oct 19, 2015 at 9:13 AM, James Nord wrote: > there shall not be any use of the bytecode-compatibility-transformer and > @AdaptField. I see your point; this looks very scary, and we clearly do not have any JVM experts on hand to design a system that is truly