Re: Backporting for 1.554.3 started

[Kohsuke Kawaguchi]

1.553.1 rc1 posted at their usual locations: http://jenkins-ci.org/stable-rc


2014-06-11 10:13 GMT-07:00 ogondza :

> Backporting is over. We are ready for RC.
>
>
> --
>
> oliver
>
>  --
> 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.
>



-- 
Kohsuke Kawaguchi

-- 
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: Jenkins plugin for HPC job systems

['Bruno P. Kinoshita' via Jenkins Developers]

Hello James

>Regarding the problem of Jenkins going offline, my feeling would be to 
>mitigate this risk by: (1) Warning and doing a qdel on all Jenkins-submitted 
>jobs when Jenkins shuts down cleanly. (2) Warning and doing a qdel on all 
>lingering Jenkins jobs when Jenkins comes back up after an unclean shutdown.


That's the beauty of durable tasks and similar approaches: we won't have to 
qdel PBS jobs. Jenkins will reconnect automagically with the cluster and will 
continue monitoring the job till it is over.

>I don't think I understand the durable-task solution, as to me that sounds 
>like one would not be able to move existing freestyle jobs back and forth 
>between conventional nodes and batch system nodes... It seems to me that the 
>right solution would be a new kind of slave node, rather than a new kind of 
>job, though I'm happy to be corrected...


I'm still learning about the durable-task solution (and keeping track of what I 
understand about it [1]). But IIUC we could still use the slave node to 
represent the PBS cluster. The problem lies in the way we trigger PBS jobs and 
keep track of what's running. 

At the moment you can use a Freestyle project in Jenkins to qsub a job to the 
cluster. But if anything happens to Jenkins while the script is running in the 
cluster, you may lose that build and maybe have to connect to the cluster or 
look for it in the PBS queues in Jenkins.

Using the durable-task solution, or similar approaches, after Jenkins is 
restarted it would revive the job for us. Yesterday a researcher submitted a 
pull request [2] to make the Freestyle project to run as long as the PBS job is 
running in the cluster. 

I will try to write a prototype using some Jenkins+PBS durable solution and 
what he proposed too, and cut a new release by next weekend (though with the 
world cup that could take a few more days :-)

Bruno

[1] http://tupilabs.com/2014/06/13/durable-tasks-in-jenkins.html

[2] https://github.com/biouno/pbs-plugin/pull/2


>
> From: James Hetherington 
>To: jenkinsci-dev@googlegroups.com 
>Sent: Thursday, June 12, 2014 9:38 AM
>Subject: Re: Jenkins plugin for HPC job systems
> 
>
>
>I had a look at Bruno's plugin -- it looks like a great starting point for 
>what we need.
>
>I think generalising Bruno's PBS Java API to support other similar systems 
>with qsub/qstat type commands should work well: it seems that a 
>PBSSlaveComputer could be generalised into a BatchSystemSlave.
>
>
>Regarding the problem of Jenkins going offline, my feeling would be to 
>mitigate this risk by: (1) Warning and doing a qdel on all Jenkins-submitted 
>jobs when Jenkins shuts down cleanly. (2) Warning and doing a qdel on all 
>lingering Jenkins jobs when Jenkins comes back up after an unclean shutdown.
>
>
>I don't think I understand the durable-task solution, as to me that sounds 
>like one would not be able to move existing freestyle jobs back and forth 
>between conventional nodes and batch system nodes... It seems to me that the 
>right solution would be a new kind of slave node, rather than a new kind of 
>job, though I'm happy to be corrected...
>
>
>
>
>
>On Thu, Jun 12, 2014 at 1:29 AM, 'Bruno P. Kinoshita' via Jenkins Developers 
> wrote:
>
>Hi Jesse,
>>
>>
>>I'm waiting for the workflow plugin but hadn't heard about the durable tasks 
>>plugin. 
>>
>>
>>The current implementation of the pbs plugin [1] was a POC to submit jobs via 
>>the qsub command to a PBS Torque server. In our tests a PBS job was triggered 
>>from a Freestyle project to the server via a SSH jump box in a university 
>>cluster. It is working and creating new jobs.
>>
>>
>>However, indeed if Jenkins goes offline the build stops running, even though 
>>the PBS job might still be running. I thought about re-using the 
>>monitor-external-job plug-in, but in some places qsub might be the only 
>>option to submit jobs.
>> 
>>I will experiment with the durable task plugin. Any advice on how to add 
>>items created in the cluster to the build queue in Jenkins? 
>>
>>
>>The current implementation creates a PBSSlaveComputer that represents a PBS 
>>Server. A Widget is created to retrieve the list of queues and its jobs from 
>>the server.
>>
>>
>>Thanks!
>>Bruno
>>
>>
>>[1] https://github.com/biouno/pbs-plugin
>>
>>
>>
>>>
>>> From: Jesse Glick 
>>>To: jenkinsci-dev@googlegroups.com 
>>>Sent: Wednesday, June 11, 2014 1:11 PM
>>>Subject: Re: Jenkins plugin for HPC job systems
>>> 
>>>
>>>On Wed, Jun 11, 2014 at 10:05 AM, James Hetherington  
>>>wrote:
 Is anyone aware of a plugin which already does this?
>>>
>>>No but I have heard of someone interested in SGE support. My idea was
>>>to implement the durable-task-plugin API, at which point any client of
>>>that plugin can use the system (and Jenkins does not need to be
>>>continuously running while the scheduling system runs your batch job).
>>>Jenkins Enterprise by CloudBees has one such client

Re: Jenkins plugin for HPC job systems

['Bruno P. Kinoshita' via Jenkins Developers]

Hi Jesse,

I will probably read the FlyweightTask javadoc&src and will experiment with it.

But that special project type could work too. Any chance to see an Open Source 
version of it this year? :-) 

Thanks!

Bruno


>
> From: Jesse Glick 
>To: jenkinsci-dev@googlegroups.com 
>Sent: Thursday, June 12, 2014 10:59 AM
>Subject: Re: Jenkins plugin for HPC job systems
> 
>
>On Wed, Jun 11, 2014 at 8:29 PM, 'Bruno P. Kinoshita' via Jenkins
>Developers  wrote:
>> I thought about re-using the monitor-external-job plug-in
>
>It makes for pretty weak integration since it does not let Jenkins
>*initiate* the build. Cf.
>
>http://developer-blog.cloudbees.com/2014/03/support-for-long-running-builds-in.html
>
>> Any advice on how to add items created in the cluster to the build queue in 
>> Jenkins?
>
>I guess you could create a dummy FlyweightTask (tied to the master
>label) whose Executable does nothing but sleep, and schedule it when
>the cluster item is created, but have it claim to be “blocked” (with a
>new cause you define) until the cluster actually starts running it.
>
>I am not sure if that is really intuitive, or if you would better
>define a new Widget showing cluster status in a specialized manner.
>
>James Hetherington wrote:
>> I don't think I understand the durable-task solution, as to me that sounds 
>> like one would not be able to move existing freestyle jobs
>> back and forth between conventional nodes and batch system nodes
>
>Correct; freestyle projects are incapable of surviving Jenkins
>restarts, and I do not think that can be changed. Thus in Jenkins
>Enterprise we added a new project type superficially similar to
>freestyle but using durable-task-plugin for the main build step and
>which does survive restarts. Analogously, workflow builds (using a
>very different UI) can survive restarts and can also use
>durable-task-plugin to manage running your external build process
>during this time.
>
>
>-- 
>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: mstest plugin pull request

[Slide]

Can you verify it builds correctly with that merged in? It looks like
buildhive built it and it failed, though I can look at the failure because
buildhive doesn't exist...
On Jun 12, 2014 6:21 PM, "iansul"  wrote:

> I noticed a bug in the Jenkins MSTest plugin, and after some digging I
> found that a pull request was submitted on Aug 30th 2013 with the fix. Is
> there some way to expedite that request?
> https://github.com/jenkinsci/mstest-plugin/pull/2
>
> Thanks,
> -Ian
>
> --
> 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.

mstest plugin pull request

[iansul]

I noticed a bug in the Jenkins MSTest plugin, and after some digging I 
found that a pull request was submitted on Aug 30th 2013 with the fix. Is 
there some way to expedite that request?
https://github.com/jenkinsci/mstest-plugin/pull/2

Thanks,
-Ian 

-- 
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: jacoco-plugin and java8

[Peter Reilly]

Thanks,

That is great!

Peter


On Wed, Jun 11, 2014 at 5:38 PM, Ognjen Bubalo 
wrote:

> Thanks for your time Dominik!
>
> I made the release. It should be visible soon.
>
>
> On Wed, Jun 11, 2014 at 10:04 PM, Dominik Stadler 
> wrote:
>
>> Hi,
>>
>> I have now merged the changes and verified that it still works fine
>> with older JDKs and also that jobs running with JDK8 also produce
>> useful JaCoCo data.
>>
>> I'll leave the actual release to you.
>>
>> Thanks... Dominik.
>>
>>
>> On Thu, Jun 5, 2014 at 11:01 AM, Ognjen Bubalo 
>> wrote:
>> > Hi,
>> >
>> > I'll check the pull request this week.
>> >
>> > Cheers,
>> > Ogi
>> >
>> >
>> >
>> > On Tue, Jun 3, 2014 at 7:04 PM, Jesse Glick 
>> wrote:
>> >>
>> >> On Tue, Jun 3, 2014 at 9:28 AM, Tamás Kende 
>> wrote:
>> >> > it seems to me the jacoco-plugin is not actively maintained anymore,
>> but
>> >> > there is an important merge request to support java8
>> >>
>> >> Adding direct notes to people recently maintaining this.
>> >
>> >
>>
>
>  --
> 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: New plugin Perforce

[Oleg Nenashev]

2.0 should be indicate it, but the additional entry on Wiki is required to
explicitly describe the situation.
However,  the 1.x version is not dead. I'm not sure about the behavior for
common update centers if the 2.x version goes to the main repo.


2014-06-12 23:58 GMT+04:00 Daniel Beck :

>
> On 12.06.2014, at 18:07, Jesse Glick  wrote:
>
> > just merge to master, change
> > 2.0-beta--SNAPSHOT to 2.0-SNAPSHOT, and release
>
> And maybe indicate incompatibility of existing configurations.
>
> --
> 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/v-u3HRvFCi8/unsubscribe.
> To unsubscribe from this group and all its topics, 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: New plugin Perforce

[Daniel Beck]

On 12.06.2014, at 18:07, Jesse Glick  wrote:

> just merge to master, change
> 2.0-beta--SNAPSHOT to 2.0-SNAPSHOT, and release

And maybe indicate incompatibility of existing configurations.

-- 
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.

SecurityListener. fireAuthenticated @Restricted(NoExternalUse.class)

[Surya Gaddipati]

https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/jenkins/security/SecurityListener.java#L91

I am trying to call that method in github-oauth-plugin after user is 
authenticated 

https://github.com/jenkinsci/github-oauth-plugin/blob/master/src/main/java/org/jenkinsci/plugins/GithubSecurityRealm.java#L386


But the method is marked as  @Restricted(NoExternalUse.class) causing the 
build to fail. Is there another way to call that method ?

-- 
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: My released plugin doesn't show up in the list of available plugins in Jenkins

[Phong Nguyen Le]

It shows up now finally and magically. Thanks for your help.

Phong.

On Thursday, June 12, 2014 10:40:34 AM UTC-7, Phong Nguyen Le wrote:
>
> Yes, it has. I even had forced refreshing of the update list in the 
> Advanced tab.
>
> Thanks,
> Phong
>
> On Thursday, June 12, 2014, Slide  wrote:
>
>> Has your Jenkins server contacted and received the update list? If not, 
>> then it won't show up in the update center.
>>
>>
>> On Thu, Jun 12, 2014 at 9:39 AM, Phong Nguyen Le  
>> wrote:
>>
>>> Hi there,
>>>
>>> I have successfully released my plugin also a day ago and the release 
>>> does show up in Jenkins Update Center 
>>> https://updates.jenkins-ci.org/download/plugins/elasticbox/. However, 
>>> the plugin ElasticBox doesn't show up in the list of available plugins in 
>>> Manage Plugins page of Jenkins server. 
>>>
>>> This is the first time I released a Jenkins plugin. Do I miss something?
>>>
>>> Thanks,
>>> Phong.
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> Website: http://earl-of-code.com 
>>
>> -- 
>> 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/Owlm0-4WHaE/unsubscribe.
>> To unsubscribe from this group and all its topics, 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: Jenkins plugin for HPC job systems

['Bruno P. Kinoshita' via Jenkins Developers]

> How hard do you think it would be to make the PBS api generic to 
>multipleschedulers, to support SGE and LL as well?

Not so hard I think. I used an existing API [1] as reference (first contacted 
the author to see if we could re-use his library), and had a look at the Python 
API too [2]. 

If we want to have a generic API to multiple schedulers, ideally I think we 
must first look at DRMAA spec [3] and the python drmaa module [4] (used in 
Galaxy for scheduling jobs in batch servers). 

What do you think if we move the API discussion to the biouno mailing list, 
code a new API and release it to Maven central? 

Bruno

[1] https://code.google.com/p/pbs4java/
[2] http://freecode.com/projects/pbs_python
[3] http://www.drmaa.org/
[4] http://drmaa-python.github.io/


>
> From: "Hetherington, James" 
>To: Bruno P. Kinoshita ; 
>"jenkinsci-dev@googlegroups.com"  
>Cc: "Hetherington, James"  
>Sent: Thursday, June 12, 2014 8:04 AM
>Subject: Re: Jenkins plugin for HPC job systems
> 
>
>Thanks Bruno, that’s really interesting, especially the PBS java api at
>https://github.com/biouno/pbs-java-api
>
>How hard do you think it would be to make the PBS api generic to multiple
>schedulers, to support SGE and LL as well?
>
>-- 
>
>                              Dr James Hetherington,
>
>Team Leader,                                   Honorary Lecturer
>Research Software Development    Department of Computer Science
>Research IT Services
>Information Services Division           Faculty of Engineering
>
>                            University College London
>
>Tel: 02035495164 (Int. 65164)
>Mobile: 07946868834
>Skype: ucgajhe
>Twitter: @uclrcsoftdev
>Blog: blogs.ucl.ac.uk/research-software-development/
>Site: development.rc.ucl.ac.uk
>
>
>
>
>On 11/06/2014 15:52, "Bruno P. Kinoshita" 
>wrote:
>
>>
>>Hi James
>>
>>We have developed a pbs plugin, but it needs more work to be ready to
>>production use.
>>
>>Maybe we can collaborate? We have a pbs java api too.
>>
>>http://biouno.org
>>
>>Bruno
>>--
>>Em qua, 11 de jun de 2014 11:05 BRT James Hetherington escreveu:
>>
>>>I am considering starting to write a Jenkins plugin to support the use
>>>of 
>>>HPC job scheduler systems like SGE, LL and PBS.
>>>
>>>Jobs currently queued in the batch system would show as pending jobs in
>>>the 
>>>Jenkins UI.
>>>Jobs would be qsubbed when they are requested to be built, and the job
>>>would transition to currently running when it runs on the scheduler
>>>
>>>Configuration for the scheduler-based slave would specify the commands
>>>to 
>>>be used for job submission, termination and status monitoring, with
>>>standard options for common queue systems,
>>>as well as SSH connection details to the login node of an HPC system.
>>>
>>>I have two questions:
>>>
>>>1. Is anyone aware of a plugin which already does this?
>>>2. Would anyone be interested in collaborating on such a project?
>>>
>>>-- 
>>>
>>>                              Dr James Hetherington,
>>>
>>>Team Leader,                                   Honorary Lecturer
>>>Research Software Development    Department of Computer Science
>>>Research IT Services
>>>Information Services Division           Faculty of Engineering
>>>
>>>                            University College London
>>>
>>>Tel: 02035495164 (Int. 65164)
>>>Mobile: 07946868834
>>>Skype: ucgajhe
>>>Twitter: @uclrcsoftdev
>>>Blog: blogs.ucl.ac.uk/research-software-development/
>>>Site: development.rc.ucl.ac.uk
>>>
>>>-- 
>>>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: My released plugin doesn't show up in the list of available plugins in Jenkins

[Phong Le]

Yes, it has. I even had forced refreshing of the update list in the
Advanced tab.

Thanks,
Phong

On Thursday, June 12, 2014, Slide  wrote:

> Has your Jenkins server contacted and received the update list? If not,
> then it won't show up in the update center.
>
>
> On Thu, Jun 12, 2014 at 9:39 AM, Phong Nguyen Le  > wrote:
>
>> Hi there,
>>
>> I have successfully released my plugin also a day ago and the release
>> does show up in Jenkins Update Center
>> https://updates.jenkins-ci.org/download/plugins/elasticbox/. However,
>> the plugin ElasticBox doesn't show up in the list of available plugins in
>> Manage Plugins page of Jenkins server.
>>
>> This is the first time I released a Jenkins plugin. Do I miss something?
>>
>> Thanks,
>> Phong.
>>
>> --
>> 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.
>>
>
>
>
> --
> Website: http://earl-of-code.com
>
> --
> 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/Owlm0-4WHaE/unsubscribe.
> To unsubscribe from this group and all its topics, 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: form-based auth script

[Ben Castellucci]

Ha ha ha ok, sorry, you already tried that link I sent.

(Sigh)

Maybe try again after you confirm success through the gui?

When I do this it's against jenkins deployed to weblogic. I use a
deployment plan to transform web.xml to add CLIENT-CERT to auth config and
then configure the security realm to map client certificates to users then
set jenkins to delegate. Jenkins ends up thinking it did a form based auth
when really weblogic did all the work and all the client did was provide a
certificate.

It's a niche setup and probably not appropriate for what you're doing but I
get out of having to deal with what you are at the moment.

I apologize but I really am stumped after this.

I suppose you could go back to one of your original concerns and unpack the
war, change the auth config to BASIC, repack it and try again, just to
eliminate that as a concern.
On Jun 12, 2014 1:18 PM, "Ben Castellucci"  wrote:

> If login through gui works OK then try token based [1] and see if that
> works.
>
> Other than that I am stumped.
>
> [1]
> https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients
> On Jun 12, 2014 12:53 PM, "Ben Castellucci"  wrote:
>
>> A good test to see if jenkins properly recognizes the container role is
>> if it does not offer a delete option next to the role in the matrix
>> security config.
>>
>> Also, looks like you're trying form based and trying to get curl to store
>> the session cookie. You might try basic auth instead.
>>
>> Out of curiosity can you log in through the gui with this setup? If that
>> works then there's nothing wrong with the auth setup and the problem is
>> with curl (for whatever reason).
>> On Jun 12, 2014 11:10 AM, "Scott Cowan" 
>> wrote:
>>
>>> Thank you Robert and Ben for your tips.
>>>
>>> This is the closest I've been able to come to reproducing the form-based
>>> authentication captured with wireshark.
>>>
>>> curl -v -c cookies.txt http://localhost:8080/jenkins/
>>>200 OK
>>> curl -v -c cookies.txt -b cookies.txt
>>> http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F
>>> 200 OK
>>> curl -v -c cookies.txt -b cookies.txt -H "Referer:
>>> http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F\r\n
>>> "
>>> -d "j_username=admin&j_password=admin"
>>> http://localhost:8080/jenkins/j_security_check
>>> 302 Found
>>> curl -v -c cookies.txt -b cookies.txt -X POST
>>> http://localhost:8080/jenkins/job/test/build?delay=0sec
>>> 403 Forbidden  (authenticated as anonymous)
>>>
>>> So, I'm unsure if my POST to j_security_check didn't work, or if the
>>> roles in my tomcat-users.xml aren't being mapped auto-magically.  I've read
>>> through some tomcat docs (http://tomcat.apache.org/tomcat-7.0-doc/),
>>> but I'm really not sure what I'm looking for.
>>>
>>> Scott
>>>
>>> tomcat-users.xml
>>> ...
>>> 
>>> 
>>> ...
>>>
>>> In Jenkins' Configure Global Security > Access Control > Authorization >
>>> Matrix-based security, the admin user has every authorization checked.
>>>
>>>
>>> On Wednesday, June 4, 2014 8:54:36 PM UTC-4, Ben Castellucci wrote:

 Robert is correct - when delegating you are entirely subject to
 authentication against the container. Jenkins handles no part of
 authentication in this situation. It only handles authorization via
 roles/groups which you sometimes have to tell the container to map. For
 example, you have a user scott defined in tomcat-users.xml. scott is a
 member of admin role (also defined in tomcat-users.xml). You should have no
 problems authenticating scott against the container trouble is telling the
 container that it's 'admin' role means the same 'admin' group in the
 jenkins app deployed in it. Until you do that scott cannot log into 
 jenkins.

 It has been a while since I dealt with tomcat. In weblogic, for
 example, you would pick the combination deployment descriptors and
 container security policy then create either per-app or global role to
 group mappings. I am sure there is some sort of tomcat equivalent. Tomcat
 may just do this auto-magically. In fact, according to [1] it looks like it
 may 'just work' with only what is in tomcat-users.xml.

 [1] https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
  On Jun 3, 2014 3:52 AM, "Sandell, Robert" 
 wrote:

> Jenkins has a servlet filter [1] that last time I checked accepts http
> basic auth. But I'm not sure how/if this works when delegating to the
> servlet container, you'd probably need to authenticate the way the
> container dictates in that case.
>
>
>
> [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/
> main/java/hudson/security/HudsonFilter.java
>
>
>
>
>
> *Robert Sandell*
>
> Software Tools Engineer - SW Environment and Product Configuration
>
> Sony Mobile Communications
>
>
>>>

Re: form-based auth script

[Ben Castellucci]

If login through gui works OK then try token based [1] and see if that
works.

Other than that I am stumped.

[1]
https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients
On Jun 12, 2014 12:53 PM, "Ben Castellucci"  wrote:

> A good test to see if jenkins properly recognizes the container role is if
> it does not offer a delete option next to the role in the matrix security
> config.
>
> Also, looks like you're trying form based and trying to get curl to store
> the session cookie. You might try basic auth instead.
>
> Out of curiosity can you log in through the gui with this setup? If that
> works then there's nothing wrong with the auth setup and the problem is
> with curl (for whatever reason).
> On Jun 12, 2014 11:10 AM, "Scott Cowan"  wrote:
>
>> Thank you Robert and Ben for your tips.
>>
>> This is the closest I've been able to come to reproducing the form-based
>> authentication captured with wireshark.
>>
>> curl -v -c cookies.txt http://localhost:8080/jenkins/
>>200 OK
>> curl -v -c cookies.txt -b cookies.txt
>> http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F
>> 200 OK
>> curl -v -c cookies.txt -b cookies.txt -H "Referer:
>> http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F\r\n
>> "
>> -d "j_username=admin&j_password=admin"
>> http://localhost:8080/jenkins/j_security_check
>> 302 Found
>> curl -v -c cookies.txt -b cookies.txt -X POST
>> http://localhost:8080/jenkins/job/test/build?delay=0sec
>> 403 Forbidden  (authenticated as anonymous)
>>
>> So, I'm unsure if my POST to j_security_check didn't work, or if the
>> roles in my tomcat-users.xml aren't being mapped auto-magically.  I've read
>> through some tomcat docs (http://tomcat.apache.org/tomcat-7.0-doc/), but
>> I'm really not sure what I'm looking for.
>>
>> Scott
>>
>> tomcat-users.xml
>> ...
>> 
>> 
>> ...
>>
>> In Jenkins' Configure Global Security > Access Control > Authorization >
>> Matrix-based security, the admin user has every authorization checked.
>>
>>
>> On Wednesday, June 4, 2014 8:54:36 PM UTC-4, Ben Castellucci wrote:
>>>
>>> Robert is correct - when delegating you are entirely subject to
>>> authentication against the container. Jenkins handles no part of
>>> authentication in this situation. It only handles authorization via
>>> roles/groups which you sometimes have to tell the container to map. For
>>> example, you have a user scott defined in tomcat-users.xml. scott is a
>>> member of admin role (also defined in tomcat-users.xml). You should have no
>>> problems authenticating scott against the container trouble is telling the
>>> container that it's 'admin' role means the same 'admin' group in the
>>> jenkins app deployed in it. Until you do that scott cannot log into jenkins.
>>>
>>> It has been a while since I dealt with tomcat. In weblogic, for example,
>>> you would pick the combination deployment descriptors and container
>>> security policy then create either per-app or global role to group
>>> mappings. I am sure there is some sort of tomcat equivalent. Tomcat may
>>> just do this auto-magically. In fact, according to [1] it looks like it may
>>> 'just work' with only what is in tomcat-users.xml.
>>>
>>> [1] https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
>>>  On Jun 3, 2014 3:52 AM, "Sandell, Robert" 
>>> wrote:
>>>
 Jenkins has a servlet filter [1] that last time I checked accepts http
 basic auth. But I'm not sure how/if this works when delegating to the
 servlet container, you'd probably need to authenticate the way the
 container dictates in that case.



 [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/
 main/java/hudson/security/HudsonFilter.java





 *Robert Sandell*

 Software Tools Engineer - SW Environment and Product Configuration

 Sony Mobile Communications



 *From:* jenkin...@googlegroups.com [mailto:jenkin...@googlegroups.com] *On
 Behalf Of *Scott Cowan
 *Sent:* den 2 juni 2014 21:54
 *To:* jenkin...@googlegroups.com
 *Subject:* form-based auth script



 I've followed the "Java example with httpclient 4.1.2" section of
 https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+
 clients and been able to successfully authenticate a client with a
 Jenkins deployed in Winstone, but I haven't been able to do so when it's
 deployed in Tomcat and access control is "Delegate to servlet container".
 A GET on "http://localhost:8080/jenkins"; with user/pass in basic auth
 scheme returns a "HTTP/1.1 500 Internal Server Error" with the explanation,
 "anonymous is missing the Overall/Read permission".  I've enabled
 "Matrix-based security" and given no permissions to Anonymous.

 I noticed the auth-method in the jenkins web.xml is FORM, whether
 deployed in Winstone or Tomcat.  Can a client a

Re: form-based auth script

[Ben Castellucci]

A good test to see if jenkins properly recognizes the container role is if
it does not offer a delete option next to the role in the matrix security
config.

Also, looks like you're trying form based and trying to get curl to store
the session cookie. You might try basic auth instead.

Out of curiosity can you log in through the gui with this setup? If that
works then there's nothing wrong with the auth setup and the problem is
with curl (for whatever reason).
On Jun 12, 2014 11:10 AM, "Scott Cowan"  wrote:

> Thank you Robert and Ben for your tips.
>
> This is the closest I've been able to come to reproducing the form-based
> authentication captured with wireshark.
>
> curl -v -c cookies.txt http://localhost:8080/jenkins/
>200 OK
> curl -v -c cookies.txt -b cookies.txt
> http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F
> 200 OK
> curl -v -c cookies.txt -b cookies.txt -H "Referer:
> http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F\r\n
> " -d
> "j_username=admin&j_password=admin"
> http://localhost:8080/jenkins/j_security_check
> 302 Found
> curl -v -c cookies.txt -b cookies.txt -X POST
> http://localhost:8080/jenkins/job/test/build?delay=0sec
> 403 Forbidden  (authenticated as anonymous)
>
> So, I'm unsure if my POST to j_security_check didn't work, or if the roles
> in my tomcat-users.xml aren't being mapped auto-magically.  I've read
> through some tomcat docs (http://tomcat.apache.org/tomcat-7.0-doc/), but
> I'm really not sure what I'm looking for.
>
> Scott
>
> tomcat-users.xml
> ...
> 
> 
> ...
>
> In Jenkins' Configure Global Security > Access Control > Authorization >
> Matrix-based security, the admin user has every authorization checked.
>
>
> On Wednesday, June 4, 2014 8:54:36 PM UTC-4, Ben Castellucci wrote:
>>
>> Robert is correct - when delegating you are entirely subject to
>> authentication against the container. Jenkins handles no part of
>> authentication in this situation. It only handles authorization via
>> roles/groups which you sometimes have to tell the container to map. For
>> example, you have a user scott defined in tomcat-users.xml. scott is a
>> member of admin role (also defined in tomcat-users.xml). You should have no
>> problems authenticating scott against the container trouble is telling the
>> container that it's 'admin' role means the same 'admin' group in the
>> jenkins app deployed in it. Until you do that scott cannot log into jenkins.
>>
>> It has been a while since I dealt with tomcat. In weblogic, for example,
>> you would pick the combination deployment descriptors and container
>> security policy then create either per-app or global role to group
>> mappings. I am sure there is some sort of tomcat equivalent. Tomcat may
>> just do this auto-magically. In fact, according to [1] it looks like it may
>> 'just work' with only what is in tomcat-users.xml.
>>
>> [1] https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
>>  On Jun 3, 2014 3:52 AM, "Sandell, Robert" 
>> wrote:
>>
>>> Jenkins has a servlet filter [1] that last time I checked accepts http
>>> basic auth. But I'm not sure how/if this works when delegating to the
>>> servlet container, you'd probably need to authenticate the way the
>>> container dictates in that case.
>>>
>>>
>>>
>>> [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/
>>> main/java/hudson/security/HudsonFilter.java
>>>
>>>
>>>
>>>
>>>
>>> *Robert Sandell*
>>>
>>> Software Tools Engineer - SW Environment and Product Configuration
>>>
>>> Sony Mobile Communications
>>>
>>>
>>>
>>> *From:* jenkin...@googlegroups.com [mailto:jenkin...@googlegroups.com] *On
>>> Behalf Of *Scott Cowan
>>> *Sent:* den 2 juni 2014 21:54
>>> *To:* jenkin...@googlegroups.com
>>> *Subject:* form-based auth script
>>>
>>>
>>>
>>> I've followed the "Java example with httpclient 4.1.2" section of
>>> https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+
>>> clients and been able to successfully authenticate a client with a
>>> Jenkins deployed in Winstone, but I haven't been able to do so when it's
>>> deployed in Tomcat and access control is "Delegate to servlet container".
>>> A GET on "http://localhost:8080/jenkins"; with user/pass in basic auth
>>> scheme returns a "HTTP/1.1 500 Internal Server Error" with the explanation,
>>> "anonymous is missing the Overall/Read permission".  I've enabled
>>> "Matrix-based security" and given no permissions to Anonymous.
>>>
>>> I noticed the auth-method in the jenkins web.xml is FORM, whether
>>> deployed in Winstone or Tomcat.  Can a client authenticate with this
>>> configuration?  Can a client negotiate a form-based authentication some
>>> how?  Does anyone have an example script to do this?
>>>
>>> Thanks in advance,
>>> Scott
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving

Re: My released plugin doesn't show up in the list of available plugins in Jenkins

[Slide]

Has your Jenkins server contacted and received the update list? If not,
then it won't show up in the update center.


On Thu, Jun 12, 2014 at 9:39 AM, Phong Nguyen Le  wrote:

> Hi there,
>
> I have successfully released my plugin also a day ago and the release does
> show up in Jenkins Update Center
> https://updates.jenkins-ci.org/download/plugins/elasticbox/. However, the
> plugin ElasticBox doesn't show up in the list of available plugins in
> Manage Plugins page of Jenkins server.
>
> This is the first time I released a Jenkins plugin. Do I miss something?
>
> Thanks,
> Phong.
>
> --
> 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.
>



-- 
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.

My released plugin doesn't show up in the list of available plugins in Jenkins

[Phong Nguyen Le]

Hi there,

I have successfully released my plugin also a day ago and the release does 
show up in Jenkins Update 
Center https://updates.jenkins-ci.org/download/plugins/elasticbox/. 
However, the plugin ElasticBox doesn't show up in the list of available 
plugins in Manage Plugins page of Jenkins server. 

This is the first time I released a Jenkins plugin. Do I miss something?

Thanks,
Phong.

-- 
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 Perforce

[Jesse Glick]

On Thu, Jun 12, 2014 at 11:13 AM, Rob Petti  wrote:
> publish to the beta update center under
> the same namespace, though I admit some ignorance as to how that would work
> with the release plugins and tagging.

I think everything would “just work” if (1) the new code is in a
branch such as ‘v2’, (2) it uses a newer version, and (3) that new
version includes ‘beta’ in the name: so start with
2.0-beta-1-SNAPSHOT. You can still cut 1.x releases from the ‘master’
branch as usual, but if you

git checkout v2 && mvn -B release:{prepare,perform}

then you will produce 2.0-beta-1, 2.0-beta-2, etc. tagged
appropriately on the branch and visible only on the experimental
update center. maven-release-plugin is smart enough to stay on the
current branch, and update only the last numeric component. If and
when you want to switch to v2 for real, just merge to master, change
2.0-beta--SNAPSHOT to 2.0-SNAPSHOT, and release.

-- 
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: Permission denied pushing plugin to GitHub

[Randy Coulman]

It worked this time.  Thanks so much for your help!

Randy


On Thu, Jun 12, 2014 at 8:48 AM, Slide  wrote:

> Please try again, I (re)added you as a committer for that repo.
>
>
> On Thu, Jun 12, 2014 at 7:42 AM,  wrote:
>
>> I’m using SSH. I am able to push to my other GitHub repositories, so I
>> believe the key is set up correctly. Do I need a different key or
>> credentials for this repository?
>>
>> I’m on a Mac, running OS/X 10.9.3.
>>
>> Here is the error message I’m getting:
>>
>> ERROR: Permission to jenkinsci/visualworks-store-plugin.git denied to 
>> randycoulman.
>> fatal: Could not read from remote repository.
>>
>> Please make sure you have the correct access rights
>> and the repository exists.
>>
>> An earlier thread on the list showed someone else with a very similar
>> problem, and it turned out to be incorrect permissions on the account.
>>
>> Thanks,
>> Randy
>>
>> On Thursday, June 12, 2014 7:14:30 AM UTC-7, slide wrote:
>>
>> What URL did you clone from and what error are you getting? If you are
>>> using the ssh URL, do you have your key setup correctly? Are you using
>>> Windows, *NIX, or Mac? Please give more details in the issue you are seeing.
>>>
>>> On Thu, Jun 12, 2014 at 6:57 AM,  wrote:
>>>

 Ping?  Is there anyone available that can check my commit permissions
 or suggest what I might be doing wrong?  I'd really like to get this plugin
 update released.

 Thanks!

 Randy


 On Tuesday, June 10, 2014 1:13:16 PM UTC-7, Randy Coulman wrote:

>  Hi, Jesse,
>
> Just tried again - no luck.  I'm able to pull, just not push.
>
> Thanks,
> Randy
>
>
> On Tue, Jun 10, 2014 at 11:35 AM, Jesse Glick 
> wrote:
>
>> On Tue, Jun 10, 2014 at 12:36 PM, Randy Coulman 
>> wrote:
>> > I'm trying to push a new version of the visualworks-store-plugin to
>> GitHub
>> > and getting a permission denied error.
>>
>> Try again; there was a GH outage.
>>
>> --
>> 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/y4rh7ponuE0/unsubscribe.
>>  To unsubscribe from this group and all its topics, send an email to
>> jenkinsci-de...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Randy Coulman
> Email: rcou...@gmail.com
> Home: http://randycoulman.com
> Twitter: @randycoulman  GitHub: randycoulman
>
  --
 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-dev+unsubscr...@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 a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/y4rh7ponuE0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Randy Coulman
Email: rcoul...@gmail.com
Home: http://randycoulman.com
Twitter: @randycoulman  GitHub: randycoulman

-- 
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: Permission denied pushing plugin to GitHub

[Slide]

Please try again, I (re)added you as a committer for that repo.


On Thu, Jun 12, 2014 at 7:42 AM,  wrote:

> I’m using SSH. I am able to push to my other GitHub repositories, so I
> believe the key is set up correctly. Do I need a different key or
> credentials for this repository?
>
> I’m on a Mac, running OS/X 10.9.3.
>
> Here is the error message I’m getting:
>
> ERROR: Permission to jenkinsci/visualworks-store-plugin.git denied to 
> randycoulman.
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> An earlier thread on the list showed someone else with a very similar
> problem, and it turned out to be incorrect permissions on the account.
>
> Thanks,
> Randy
>
> On Thursday, June 12, 2014 7:14:30 AM UTC-7, slide wrote:
>
> What URL did you clone from and what error are you getting? If you are
>> using the ssh URL, do you have your key setup correctly? Are you using
>> Windows, *NIX, or Mac? Please give more details in the issue you are seeing.
>>
>> On Thu, Jun 12, 2014 at 6:57 AM,  wrote:
>>
>>>
>>> Ping?  Is there anyone available that can check my commit permissions or
>>> suggest what I might be doing wrong?  I'd really like to get this plugin
>>> update released.
>>>
>>> Thanks!
>>>
>>> Randy
>>>
>>>
>>> On Tuesday, June 10, 2014 1:13:16 PM UTC-7, Randy Coulman wrote:
>>>
 Hi, Jesse,

 Just tried again - no luck.  I'm able to pull, just not push.

 Thanks,
 Randy


 On Tue, Jun 10, 2014 at 11:35 AM, Jesse Glick 
 wrote:

> On Tue, Jun 10, 2014 at 12:36 PM, Randy Coulman 
> wrote:
> > I'm trying to push a new version of the visualworks-store-plugin to
> GitHub
> > and getting a permission denied error.
>
> Try again; there was a GH outage.
>
> --
> 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/y4rh7ponuE0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-de...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>



 --
 Randy Coulman
 Email: rcou...@gmail.com
 Home: http://randycoulman.com
 Twitter: @randycoulman  GitHub: randycoulman

>>>  --
>>> 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-dev+unsubscr...@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-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New plugin Perforce

[Rob Petti]

We'll need it in github before we can really do anything at all with it, so
that's still the first step.

Personally, I think it should be put into a separate branch within the
perforce-plugin repo, and have it publish to the beta update center under
the same namespace, though I admit some ignorance as to how that would work
with the release plugins and tagging. If nobody sees any issues with this
plan, then I say go ahead with it.


On Thu, Jun 12, 2014 at 4:21 AM, Paul Allen  wrote:

> Hi Guys,
>
> I have done some more work on the new Perforce plugin (see:
> https://swarm.workshop.perforce.com/projects/p4-jenkins/files/main).
>
> I hope that this now brings it up to the same level of features as the old
> one.  Please take a few minutes to skim through the user guide (there are
> lots of screen shots, so it won't take log):
>
>
> https://swarm.workshop.perforce.com/projects/p4-jenkins/view/main/docs/UserGuide.pdf
>
> I would like to get this out into the Jenkins community, but I am going to
> need your help.
>
> If any one is keen to use the existing 'Perforce' name space then I will
> need help to deploy this (whether under the beta update centre, or as a
> branch).  Alternatively, I could use a new 'p4' name space, but again I
> would appreciate help with deploying this.
>
> Kind regards,
> Paul
>
> On 21 May 2014, at 10:06, Paul Allen  wrote:
>
> > Hi Oleg,
> >
> > Sorry for any delay in communication; I have been out on holiday and
> catching up with some other projects.
> >
> > For the moment we are releasing the beta version of the plugin from our
> own Workshop for early adopters to try out and provide feedback.  My
> current focus is to provide feature parade with the old plugin and to look
> at a way to ease the migration process.
> >
> > With some maturing of the new plugin, I still hope to be able to release
> it under the Jenkins community.  If you have identified missing features or
> have suggestions on the migration please let me know.  I am keen to bring
> in as much help as possible.
> >
> > Kind regards,
> > Paul
> >
> > On 20 May 2014, at 20:22, Oleg Nenashev  wrote:
> >
> >> Hi Paul,
> >>
> >> Is there any update on the topic?
> >>  • I don't see any new Perforce plugins in the repo, the
> development is not very active as well
> >>  • I still think that usage of the same [plugin name/id] is a good
> idea. All users with a default update center won't be able to select from
> various versions. Since you don't provide migration features, such approach
> will destroy many Jenkins installations with P4 when you release the plugin
> to the main repo
> >>  • As you know, we've decided to continue the development of the
> original Perforce plugin.
> >> In my company several groups concluded that the new P4 plugin cannot be
> adopted in the medium-term perspective.
> >> Probably, you should reconsider your approach if you want to improve
> the overall user experience of existing customers.
> >>
> >> Best regards,
> >> Oleg Nenashev
> >>
> >> понедельник, 28 апреля 2014 г., 13:35:34 UTC+4 пользователь pallen
> написал:
> >> Hi Guys,
> >>
> >> I know there has been a lot of discussion around the new plugin, but
> referring to Kawaguchi-san's email (below) I am happy to go with option 3
> and distribute through the beta update centre for the time being.
> >>
> >> Please let me know where to deploy the code and any changes that are
> need in the POM.
> >>
> >> Kind regards,
> >> Paul
> >>
> >>
> >> On 18 Apr 2014, at 18:31, Kohsuke Kawaguchi 
> wrote:
> >>
> >>>
> >>> I'm waiting for Rob and Paul to agree on the approach forward. I think
> we'd be happy to honor that, since you guys are the ones that are doing the
> actual work.
> >>>
> >>>
> >>> Where Jesse and I are coming from is to try to understand the message
> to the existing users, because Perforce plugin is widely used.
> >>>
> >>>
> >>> If you expect both current and new plugins to co-exist going forward,
> that's the least preferable outcome from users' PoV.
> >>>
> >>> The next better one is that you expect the current plugin to become
> dormant and all the efforts to go to the new plugin. It's still disruptive
> for users, but at least there's a clarity in the direction.
> >>>
> >>> The next better one is that you two agree that the current plugin will
> become dormant and the new one will take over, then we work out the data
> migration compatibility between the current and new plugin, without
> preserving code compatibility. This is pretty good for users, as they don't
> have to go through disruptive changes.
> >>>
> >>> Then the final one is to try to maintain some/all of the code
> compatibility. If there are plugin out there that depends on the perforce
> plugin, this will make their users happy.
> >>>
> >>>
> >>> Without much experience of Perforce, what I'd like to encourage you to
> consider is the third option, and here is one way of doing it.
> >>>
> >>> We could put both current and the new in the same repo, a

Re: form-based auth script

[Scott Cowan]

Thank you Robert and Ben for your tips.

This is the closest I've been able to come to reproducing the form-based 
authentication captured with wireshark.

curl -v -c cookies.txt http://localhost:8080/jenkins/
   200 OK
curl -v -c cookies.txt -b cookies.txt 
http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F
200 OK
curl -v -c cookies.txt -b cookies.txt -H "Referer: 
http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F\r\n"; -d 
"j_username=admin&j_password=admin" 
http://localhost:8080/jenkins/j_security_check
302 Found
curl -v -c cookies.txt -b cookies.txt -X POST 
http://localhost:8080/jenkins/job/test/build?delay=0sec
403 Forbidden  (authenticated as anonymous)

So, I'm unsure if my POST to j_security_check didn't work, or if the roles 
in my tomcat-users.xml aren't being mapped auto-magically.  I've read 
through some tomcat docs (http://tomcat.apache.org/tomcat-7.0-doc/), but 
I'm really not sure what I'm looking for.

Scott

tomcat-users.xml
...


...

In Jenkins' Configure Global Security > Access Control > Authorization > 
Matrix-based security, the admin user has every authorization checked.


On Wednesday, June 4, 2014 8:54:36 PM UTC-4, Ben Castellucci wrote:
>
> Robert is correct - when delegating you are entirely subject to 
> authentication against the container. Jenkins handles no part of 
> authentication in this situation. It only handles authorization via 
> roles/groups which you sometimes have to tell the container to map. For 
> example, you have a user scott defined in tomcat-users.xml. scott is a 
> member of admin role (also defined in tomcat-users.xml). You should have no 
> problems authenticating scott against the container trouble is telling the 
> container that it's 'admin' role means the same 'admin' group in the 
> jenkins app deployed in it. Until you do that scott cannot log into jenkins.
>
> It has been a while since I dealt with tomcat. In weblogic, for example, 
> you would pick the combination deployment descriptors and container 
> security policy then create either per-app or global role to group 
> mappings. I am sure there is some sort of tomcat equivalent. Tomcat may 
> just do this auto-magically. In fact, according to [1] it looks like it may 
> 'just work' with only what is in tomcat-users.xml.
>
> [1] https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
>  On Jun 3, 2014 3:52 AM, "Sandell, Robert"  > wrote:
>
>> Jenkins has a servlet filter [1] that last time I checked accepts http 
>> basic auth. But I’m not sure how/if this works when delegating to the 
>> servlet container, you’d probably need to authenticate the way the 
>> container dictates in that case.
>>
>>  
>>
>> [1] 
>> https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/security/HudsonFilter.java
>>
>>  
>>
>>  
>>
>> *Robert Sandell*
>>
>> Software Tools Engineer - SW Environment and Product Configuration
>>
>> Sony Mobile Communications
>>
>>  
>>
>> *From:* jenkin...@googlegroups.com  [mailto:
>> jenkin...@googlegroups.com ] *On Behalf Of *Scott Cowan
>> *Sent:* den 2 juni 2014 21:54
>> *To:* jenkin...@googlegroups.com 
>> *Subject:* form-based auth script
>>
>>  
>>
>> I've followed the "Java example with httpclient 4.1.2" section of 
>> https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients 
>> and been able to successfully authenticate a client with a Jenkins deployed 
>> in Winstone, but I haven't been able to do so when it's deployed in Tomcat 
>> and access control is "Delegate to servlet container".  A GET on "
>> http://localhost:8080/jenkins"; with user/pass in basic auth scheme 
>> returns a "HTTP/1.1 500 Internal Server Error" with the explanation, 
>> "anonymous is missing the Overall/Read permission".  I've enabled 
>> "Matrix-based security" and given no permissions to Anonymous.
>>
>> I noticed the auth-method in the jenkins web.xml is FORM, whether 
>> deployed in Winstone or Tomcat.  Can a client authenticate with this 
>> configuration?  Can a client negotiate a form-based authentication some 
>> how?  Does anyone have an example script to do this?
>>
>> Thanks in advance,
>> Scott
>>
>> -- 
>> 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...@google

Re: Permission denied pushing plugin to GitHub

[rcoulman]

I’m using SSH. I am able to push to my other GitHub repositories, so I 
believe the key is set up correctly. Do I need a different key or 
credentials for this repository?

I’m on a Mac, running OS/X 10.9.3.

Here is the error message I’m getting:

ERROR: Permission to jenkinsci/visualworks-store-plugin.git denied to 
randycoulman.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

An earlier thread on the list showed someone else with a very similar 
problem, and it turned out to be incorrect permissions on the account.

Thanks,
Randy

On Thursday, June 12, 2014 7:14:30 AM UTC-7, slide wrote:

What URL did you clone from and what error are you getting? If you are 
> using the ssh URL, do you have your key setup correctly? Are you using 
> Windows, *NIX, or Mac? Please give more details in the issue you are seeing.
>
> On Thu, Jun 12, 2014 at 6:57 AM, > wrote:
>
>>
>> Ping?  Is there anyone available that can check my commit permissions or 
>> suggest what I might be doing wrong?  I'd really like to get this plugin 
>> update released.
>>
>> Thanks!
>>
>> Randy
>>
>>
>> On Tuesday, June 10, 2014 1:13:16 PM UTC-7, Randy Coulman wrote:
>>>
>>> Hi, Jesse,
>>>
>>> Just tried again - no luck.  I'm able to pull, just not push.
>>>
>>> Thanks,
>>> Randy
>>>
>>>
>>> On Tue, Jun 10, 2014 at 11:35 AM, Jesse Glick >> > wrote:
>>>
 On Tue, Jun 10, 2014 at 12:36 PM, Randy Coulman >>> > wrote:
 > I'm trying to push a new version of the visualworks-store-plugin to 
 GitHub
 > and getting a permission denied error.

 Try again; there was a GH outage.

 --
 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/y4rh7ponuE0/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 jenkinsci-de...@googlegroups.com .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> -- 
>>> Randy Coulman
>>> Email: rcou...@gmail.com 
>>> Home: http://randycoulman.com
>>> Twitter: @randycoulman  GitHub: randycoulman
>>>  
>>  -- 
>> 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-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Permission denied pushing plugin to GitHub

[Slide]

What URL did you clone from and what error are you getting? If you are
using the ssh URL, do you have your key setup correctly? Are you using
Windows, *NIX, or Mac? Please give more details in the issue you are seeing.


On Thu, Jun 12, 2014 at 6:57 AM,  wrote:

>
> Ping?  Is there anyone available that can check my commit permissions or
> suggest what I might be doing wrong?  I'd really like to get this plugin
> update released.
>
> Thanks!
>
> Randy
>
>
> On Tuesday, June 10, 2014 1:13:16 PM UTC-7, Randy Coulman wrote:
>>
>> Hi, Jesse,
>>
>> Just tried again - no luck.  I'm able to pull, just not push.
>>
>> Thanks,
>> Randy
>>
>>
>> On Tue, Jun 10, 2014 at 11:35 AM, Jesse Glick 
>> wrote:
>>
>>> On Tue, Jun 10, 2014 at 12:36 PM, Randy Coulman 
>>> wrote:
>>> > I'm trying to push a new version of the visualworks-store-plugin to
>>> GitHub
>>> > and getting a permission denied error.
>>>
>>> Try again; there was a GH outage.
>>>
>>> --
>>> 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/y4rh7ponuE0/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> jenkinsci-dev+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Randy Coulman
>> Email: rcoul...@gmail.com
>> Home: http://randycoulman.com
>> Twitter: @randycoulman  GitHub: randycoulman
>>
>  --
> 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.
>



-- 
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: Jenkins plugin for HPC job systems

[Jesse Glick]

On Wed, Jun 11, 2014 at 8:29 PM, 'Bruno P. Kinoshita' via Jenkins
Developers  wrote:
> I thought about re-using the monitor-external-job plug-in

It makes for pretty weak integration since it does not let Jenkins
*initiate* the build. Cf.

http://developer-blog.cloudbees.com/2014/03/support-for-long-running-builds-in.html

> Any advice on how to add items created in the cluster to the build queue in 
> Jenkins?

I guess you could create a dummy FlyweightTask (tied to the master
label) whose Executable does nothing but sleep, and schedule it when
the cluster item is created, but have it claim to be “blocked” (with a
new cause you define) until the cluster actually starts running it.

I am not sure if that is really intuitive, or if you would better
define a new Widget showing cluster status in a specialized manner.

James Hetherington wrote:
> I don't think I understand the durable-task solution, as to me that sounds 
> like one would not be able to move existing freestyle jobs
> back and forth between conventional nodes and batch system nodes

Correct; freestyle projects are incapable of surviving Jenkins
restarts, and I do not think that can be changed. Thus in Jenkins
Enterprise we added a new project type superficially similar to
freestyle but using durable-task-plugin for the main build step and
which does survive restarts. Analogously, workflow builds (using a
very different UI) can survive restarts and can also use
durable-task-plugin to manage running your external build process
during this time.

-- 
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: Permission denied pushing plugin to GitHub

[rcoulman]

Ping?  Is there anyone available that can check my commit permissions or 
suggest what I might be doing wrong?  I'd really like to get this plugin 
update released.

Thanks!

Randy

On Tuesday, June 10, 2014 1:13:16 PM UTC-7, Randy Coulman wrote:
>
> Hi, Jesse,
>
> Just tried again - no luck.  I'm able to pull, just not push.
>
> Thanks,
> Randy
>
>
> On Tue, Jun 10, 2014 at 11:35 AM, Jesse Glick  
> wrote:
>
>> On Tue, Jun 10, 2014 at 12:36 PM, Randy Coulman  
>> wrote:
>> > I'm trying to push a new version of the visualworks-store-plugin to 
>> GitHub
>> > and getting a permission denied error.
>>
>> Try again; there was a GH outage.
>>
>> --
>> 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/y4rh7ponuE0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkinsci-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Randy Coulman
> Email: rcoul...@gmail.com
> Home: http://randycoulman.com
> Twitter: @randycoulman  GitHub: randycoulman
>  

-- 
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: Plugin which will create new job type.

[Jesse Glick]

On Wed, Jun 11, 2014 at 8:39 PM, Rob Terpilowski
 wrote:
> I've created a class which [extends] 
> AbstractProject.AbstractProjectDescriptor, and have annotated this
> class with the @Extension annotation.  In addition I've added
> newJobDetail.jelly file to the project.  However when I deploy the plugin
> and restart Jenkins, nothing appears to happen.

mvn clean hpi:run

and if it is still not there, check the script console for

Jenkins.instance.getExtensionList(TopLevelItemDescriptor)

-- 
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: Jenkins plugin for HPC job systems

[James Hetherington]

I had a look at Bruno's plugin -- it looks like a great starting point for
what we need.

I think generalising Bruno's PBS Java API to support other similar systems
with qsub/qstat type commands should work well: it seems that a
PBSSlaveComputer could be generalised into a BatchSystemSlave.

Regarding the problem of Jenkins going offline, my feeling would be to
mitigate this risk by: (1) Warning and doing a qdel on all
Jenkins-submitted jobs when Jenkins shuts down cleanly. (2) Warning and
doing a qdel on all lingering Jenkins jobs when Jenkins comes back up after
an unclean shutdown.

I don't think I understand the durable-task solution, as to me that sounds
like one would not be able to move existing freestyle jobs back and forth
between conventional nodes and batch system nodes... It seems to me that
the right solution would be a new kind of slave node, rather than a new
kind of job, though I'm happy to be corrected...



On Thu, Jun 12, 2014 at 1:29 AM, 'Bruno P. Kinoshita' via Jenkins
Developers  wrote:

> Hi Jesse,
>
> I'm waiting for the workflow plugin but hadn't heard about the durable
> tasks plugin.
>
> The current implementation of the pbs plugin [1] was a POC to submit jobs
> via the qsub command to a PBS Torque server. In our tests a PBS job was
> triggered from a Freestyle project to the server via a SSH jump box in a
> university cluster. It is working and creating new jobs.
>
> However, indeed if Jenkins goes offline the build stops running, even
> though the PBS job might still be running. I thought about re-using the
> monitor-external-job plug-in, but in some places qsub might be the only
> option to submit jobs.
>
> I will experiment with the durable task plugin. Any advice on how to add
> items created in the cluster to the build queue in Jenkins?
>
> The current implementation creates a PBSSlaveComputer that represents a
> PBS Server. A Widget is created to retrieve the list of queues and its jobs
> from the server.
>
> Thanks!
> Bruno
>
> [1] https://github.com/biouno/pbs-plugin
>
>   --
>  *From:* Jesse Glick 
> *To:* jenkinsci-dev@googlegroups.com
> *Sent:* Wednesday, June 11, 2014 1:11 PM
> *Subject:* Re: Jenkins plugin for HPC job systems
>
> On Wed, Jun 11, 2014 at 10:05 AM, James Hetherington 
> wrote:
> > Is anyone aware of a plugin which already does this?
>
> No but I have heard of someone interested in SGE support. My idea was
> to implement the durable-task-plugin API, at which point any client of
> that plugin can use the system (and Jenkins does not need to be
> continuously running while the scheduling system runs your batch job).
> Jenkins Enterprise by CloudBees has one such client, which looks and
> feels like a freestyle project; the upcoming Workflow plugin suite has
> another caller, which is used routinely for running forked commands
> like shell scripts.
>
>
> --
> 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 a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/nLOBkO8ttVM/unsubscribe.
> To unsubscribe from this group and all its topics, 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: New plugin Perforce

[Paul Allen]

Hi Guys,

I have done some more work on the new Perforce plugin (see: 
https://swarm.workshop.perforce.com/projects/p4-jenkins/files/main).

I hope that this now brings it up to the same level of features as the old one. 
 Please take a few minutes to skim through the user guide (there are lots of 
screen shots, so it won't take log):

   
https://swarm.workshop.perforce.com/projects/p4-jenkins/view/main/docs/UserGuide.pdf

I would like to get this out into the Jenkins community, but I am going to need 
your help.  

If any one is keen to use the existing 'Perforce' name space then I will need 
help to deploy this (whether under the beta update centre, or as a branch).  
Alternatively, I could use a new 'p4' name space, but again I would appreciate 
help with deploying this.

Kind regards,
Paul

On 21 May 2014, at 10:06, Paul Allen  wrote:

> Hi Oleg,
> 
> Sorry for any delay in communication; I have been out on holiday and catching 
> up with some other projects.
> 
> For the moment we are releasing the beta version of the plugin from our own 
> Workshop for early adopters to try out and provide feedback.  My current 
> focus is to provide feature parade with the old plugin and to look at a way 
> to ease the migration process.
> 
> With some maturing of the new plugin, I still hope to be able to release it 
> under the Jenkins community.  If you have identified missing features or have 
> suggestions on the migration please let me know.  I am keen to bring in as 
> much help as possible.
> 
> Kind regards,
> Paul
> 
> On 20 May 2014, at 20:22, Oleg Nenashev  wrote:
> 
>> Hi Paul,
>> 
>> Is there any update on the topic?
>>  • I don't see any new Perforce plugins in the repo, the development is 
>> not very active as well
>>  • I still think that usage of the same [plugin name/id] is a good idea. 
>> All users with a default update center won't be able to select from various 
>> versions. Since you don't provide migration features, such approach will 
>> destroy many Jenkins installations with P4 when you release the plugin to 
>> the main repo
>>  • As you know, we've decided to continue the development of the 
>> original Perforce plugin. 
>> In my company several groups concluded that the new P4 plugin cannot be 
>> adopted in the medium-term perspective. 
>> Probably, you should reconsider your approach if you want to improve the 
>> overall user experience of existing customers.
>> 
>> Best regards,
>> Oleg Nenashev
>> 
>> понедельник, 28 апреля 2014 г., 13:35:34 UTC+4 пользователь pallen написал:
>> Hi Guys, 
>> 
>> I know there has been a lot of discussion around the new plugin, but 
>> referring to Kawaguchi-san's email (below) I am happy to go with option 3 
>> and distribute through the beta update centre for the time being. 
>> 
>> Please let me know where to deploy the code and any changes that are need in 
>> the POM. 
>> 
>> Kind regards, 
>> Paul 
>> 
>> 
>> On 18 Apr 2014, at 18:31, Kohsuke Kawaguchi  wrote: 
>> 
>>> 
>>> I'm waiting for Rob and Paul to agree on the approach forward. I think we'd 
>>> be happy to honor that, since you guys are the ones that are doing the 
>>> actual work. 
>>> 
>>> 
>>> Where Jesse and I are coming from is to try to understand the message to 
>>> the existing users, because Perforce plugin is widely used. 
>>> 
>>> 
>>> If you expect both current and new plugins to co-exist going forward, 
>>> that's the least preferable outcome from users' PoV. 
>>> 
>>> The next better one is that you expect the current plugin to become dormant 
>>> and all the efforts to go to the new plugin. It's still disruptive for 
>>> users, but at least there's a clarity in the direction. 
>>> 
>>> The next better one is that you two agree that the current plugin will 
>>> become dormant and the new one will take over, then we work out the data 
>>> migration compatibility between the current and new plugin, without 
>>> preserving code compatibility. This is pretty good for users, as they don't 
>>> have to go through disruptive changes. 
>>> 
>>> Then the final one is to try to maintain some/all of the code 
>>> compatibility. If there are plugin out there that depends on the perforce 
>>> plugin, this will make their users happy. 
>>> 
>>> 
>>> Without much experience of Perforce, what I'd like to encourage you to 
>>> consider is the third option, and here is one way of doing it. 
>>> 
>>> We could put both current and the new in the same repo, and call the new 
>>> one "perforce plugin 2.0." They need not share the code at all. 2.0 would 
>>> work toward feature parity with 1.0. Existing Jenkins devs can help create 
>>> migration shim in the 2.0 branch. 
>>> 
>>> We can have alpha/beta releases of 2.0 in parallel to updates to 1.x 
>>> releases. People on the beta update center will get this 2.0 beta versions. 
>>> When 2.0 is in feature parity, we can have the official 2.0 release. 
>>> 
>>> Or if we discover that feature parity is unattainable, we can rename th