Re: Guidance on how to release a new version of a plugin with a breaking change

[Gavin Mogan]

I took a bit more of an automatic approach. It updates on startup

https://github.com/jenkinsci/sauce-ondemand-plugin/blob/e67c8573775be8222a5784d85d9fcca980be92d6/src/main/java/hudson/plugins/sauce_ondemand/SauceOnDemandBuildWrapper.java#L1011-L1063

On Wednesday, November 30, 2016 at 10:43:57 AM UTC-8, Jesse Glick wrote:
>
> On Tue, Nov 29, 2016 at 3:04 PM, 'Claudiu Guiman' via Jenkins 
> Developers  wrote: 
> > We’re currently working on storing the credentials of Azure storage 
> plugin 
> > in the Credentials Manager. When we’ll release, upgrading from an older 
> > version to the latest will remove existing credentials and the users 
> will 
> > have to manually add them again. 
>
> Plugins are routinely switched to Credentials with compatibility code 
> that automatically migrates existing secrets. There are numerous 
> examples you can find; here is one: 
>
>
> https://github.com/jenkinsci/ssh-slaves-plugin/blob/ae2d6dee1a03a155c991809a4fcac11c5537bdd9/src/main/java/hudson/plugins/sshslaves/SSHLauncher.java#L512-L546
>  
>

-- 
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/db32a0f6-3586-4c3f-87ea-b0a588f26ff3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Blue Ocean] API and UI URL mismatch behind reverse proxy

[James Dumay]

A fix should be available in Blue Ocean beta 13 next week.

On Wednesday, November 30, 2016 at 5:58:17 PM UTC+11, James Dumay wrote:
>
> I've re-opened JENKINS-36907 
>  and submitted a pull 
> request  that 
> should fix this regardless of any errors in the translation. If all goes 
> well it should be in next weeks Blue Ocean beta.
>
> On Wednesday, November 30, 2016 at 4:09:33 AM UTC+11, Baptiste Mathus 
> wrote:
>>
>> This issue was fixed in 2.16 cf. 
>> https://github.com/jenkinsci/jenkins/commit/3956994c286941dab2da810c649269d637dc98d9
>>
>> So, if you're seeing something close or similar, please file an issue and 
>> use the users ML instead.
>>
>>
>> 2016-11-29 13:38 GMT+01:00 :
>>
>>> I'm using Jenkins 2.19.4 and still has this issue while on Spanish 
>>> language.
>>>
>>> When will this issue be fixed?
>>>
>>>
>>> El lunes, 25 de julio de 2016, 8:45:18 (UTC+2), Ivan Meredith escribió:
>>>
 Hi there,

 It is because your Jenkins instance is in spanish!.

 There is this bit of code 
 https://github.com/jenkinsci/blueocean-plugin/blob/master/blueocean-rest-impl/src/main/java/io/jenkins/blueocean/service/embedded/rest/OrganizationImpl.java#L40
  
 And a quick grep

 ivan@MacBook-Pro ~/w/jenkins/core/src/main/resources/jenkins/model 
 (master)$ grep -R -E 'Hudson.DisplayName=.* $' .
 ./Messages_es.properties:Hudson.DisplayName=Jenkins

 I created PR https://github.com/jenkinsci/jenkins/pull/2471 to fix it 
 in Jenkins, 

 and also JENKINS-36907 
  to track it in 
 Blue Ocean.

 Switching your language should fix this.I imagine this will be changed 
 in Blue Ocean quickly too.

 On Thursday, July 21, 2016 at 8:31:43 PM UTC+12, Javier Martín Caro 
 BEEVA wrote:
>
> Hi there!
>
> We have set up jenkins blue ocean behind a nginx reverse proxy and 
> configured successfully the prefix in the url to /jenkins. Despite 
> of 
> this, when we access to the blue ocean ui in /jenkins/blue and try 
> to 
> access some pipeline, a 422 (unprocessable entity error) is displayed in 
> the browser debugging console and a white screen is shown.
>
> The URL in the browser is like the following (note the encoded space):
>
> https:///jenkins/blue/organizations/*jenkins%20*
> //activity
>
>
>
> When we call the blue ocean API for organizations the following 
> information is shown (https:///jenkins/blue/rest/organizations/):
>
>
> [{"_class":"io.jenkins.blueocean.service.embedded.rest.OrganizationImpl","_links":{"pipelines":{"_class":"io.jenkins.blueocean.rest.hal.Link","href":"/blue/rest/organizations/jenkins
>  
> /pipelines/"},"self":{"_class":"io.jenkins.blueocean.rest.hal.Link","href":"/blue/rest/organizations/jenkins
>  
> /"},"user":{"_class":"io.jenkins.blueocean.rest.hal.Link","href":"/blue/rest/organizations/jenkins
>  
> /user/"},"users":{"_class":"io.jenkins.blueocean.rest.hal.Link","href":"/blue/rest/organizations/jenkins
>  /users/"}},"name":"jenkins "}]
>
>
> Note the white space in the organizations href after /jenkins /pipelines.
>
>
> If we call to 
> https:///jenkins/blue/rest/organizations/jenkins/pipelines//runs/
>  the following message is shown:
>
>
> {
>
>   "message" : "Organization jenkins not found",
>
>   "code" : 422,
>
>   "errors" : [ ]
>
> }
>
>
> But if we force the organization to be jenkins%20 
> (https:///jenkins/blue/rest/organizations/jenkins%20/pipelines//runs/)
>  the information is displayed correctly.
>
>
> Can someone help us to configure the proper name for the organization? We 
> thought it was the jenkins url in the settings page but this is set to 
> https:///jenkins/. 
>
>
> Old UI is working properly for all pipelines, folder organizations and 
> bitbucket team jobs.
>
>
> Thank you and regards!
>
>
> -- 
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/b7a849ac-b33c-4725-8c78-c7f205eb653c%40googlegroups.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 

Re: New Job Cacher plugin to cache dependencies of builds on docker based executors

[Peter Hayes]

Ok. Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/97781456-775b-4141-ae09-4b9f710c76b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New plugin request for feedback: parameterized scheduler

[Richard Bywater]

It would be best to redirect this query to the Jenkins User List as this
mailing list is used for development of plugins and not their use.

Richard.

On Thu, 1 Dec 2016 at 11:46 PC  wrote:

> Hi,
>
> I have installed this plugin and am trying to use it. This plugin is
> exactly what I need, as I need to to schedule multiple builds with
> different parameters at each build.
>
> For some reason, the build is not triggering at the scheduled periods. I
> tried various schedules. Attached are the screenshots from my sample job.
>
> Thanks,
> Pragya
>
>
>
> On Thursday, November 19, 2015 at 2:31:41 PM UTC-8, Baptiste Mathus wrote:
>
> Plugin released, any feedback welcome:
> https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Scheduler+Plugin
>
> 2015-11-18 6:22 GMT+01:00 Baptiste Mathus :
>
> OK, as we've tested it successfully, I'm going to fork it.
>
> Thanks
>
>
> 2015-11-17 11:14 GMT+01:00 Baptiste Mathus :
>
> Hi,
>
> Note: this is *not* a fork request.
>
> Just an email here to get potential feedback about that plugin [1]. I've
> already gotten some feedback from Daniel [2] and agreement from the
> original author to take ownership [3].
>
> This plugin adds a new trigger field which basically lets you plan simply
> many parameterized executions using the typical cron format + an additional
> list of parameters values.
>
> Example :
>
> */10 * * * * % param=X
> */15 * * * * % param=Y
> H * * * * [here it will execute with default values]
>
>
> If you think this plugin is interesting, or is actually a bad idea, please
> say it here!
>
> Depending on the feedback, I may fork it quite soon, in the next few days.
>
> Thanks
>
> [1] https://github.com/jwmach1/parameterized-scheduler
> [2] https://issues.jenkins-ci.org/browse/JENKINS-16352
> [3] https://github.com/jwmach1/parameterized-scheduler/issues/1
>
> --
> Baptiste
>
>
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>
>
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>
> --
> 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/db675dd5-e978-4a62-9c38-794ee90966e1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAMui947dvxfZwZBNcoCbT1V-vr08wU8JQSgA%3DmdYghUi4cc3oA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Job Cacher plugin to cache dependencies of builds on docker based executors

[Jesse Glick]

Probably you are looking for the External Workspace Manager plugin.
Last I checked, it had not been extended to really support clouds. I
suggest you raise this as an RFE with the PSE team, rather than
discussing it here—unless you intend to try developing such an
extension yourself, in which case you would likely want to hang out in
https://gitter.im/jenkinsci/external-workspace-manager-plugin and ask
for advice.

-- 
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/CANfRfr3HMGUEPP9PRReGLvY-37VfaE%2BsGdqe1SM_GXvB1EaOKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: New plugin request for feedback: parameterized scheduler

[PC]

Hi,

I have installed this plugin and am trying to use it. This plugin is 
exactly what I need, as I need to to schedule multiple builds with 
different parameters at each build. 

For some reason, the build is not triggering at the scheduled periods. I 
tried various schedules. Attached are the screenshots from my sample job.

Thanks,
Pragya



On Thursday, November 19, 2015 at 2:31:41 PM UTC-8, Baptiste Mathus wrote:
>
> Plugin released, any feedback welcome: 
> https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Scheduler+Plugin
>
> 2015-11-18 6:22 GMT+01:00 Baptiste Mathus :
>
>> OK, as we've tested it successfully, I'm going to fork it.
>>
>> Thanks
>>
>> 2015-11-17 11:14 GMT+01:00 Baptiste Mathus > >:
>>
>>> Hi,
>>>
>>> Note: this is *not* a fork request. 
>>>
>>> Just an email here to get potential feedback about that plugin [1]. I've 
>>> already gotten some feedback from Daniel [2] and agreement from the 
>>> original author to take ownership [3].
>>>
>>> This plugin adds a new trigger field which basically lets you plan 
>>> simply many parameterized executions using the typical cron format + an 
>>> additional list of parameters values.
>>>
>>> Example : 
>>>
>>> */10 * * * * % param=X
>>> */15 * * * * % param=Y
>>> H * * * * [here it will execute with default values]
>>>
>>>
>>> If you think this plugin is interesting, or is actually a bad idea, 
>>> please say it here! 
>>>
>>> Depending on the feedback, I may fork it quite soon, in the next few 
>>> days.
>>>
>>> Thanks
>>>
>>> [1] https://github.com/jwmach1/parameterized-scheduler
>>> [2] https://issues.jenkins-ci.org/browse/JENKINS-16352
>>> [3] https://github.com/jwmach1/parameterized-scheduler/issues/1
>>>
>>> -- 
>>> Baptiste
>>>
>>
>>
>>
>> -- 
>> Baptiste  MATHUS - http://batmat.net
>> Sauvez un arbre,
>> Mangez un castor !
>>
>
>
>
> -- 
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>

-- 
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/db675dd5-e978-4a62-9c38-794ee90966e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Job Cacher plugin to cache dependencies of builds on docker based executors

[Peter Hayes]

Continuing to think on this a bit more - FilePath abstraction doesn't look 
like it would work as it assumes a computer on the other end. What if there 
was an "External Storage Plugin" extension point that could be backed by S3 
and leveraged by other plugins for managing large files associated with 
jobs.  Ideally it would share a job lifecycle so that when jobs are renamed 
/ deleted, the related external storage area for the jobs would be managed 
as well.  Is there an extension point for something like that?

On Wednesday, November 30, 2016 at 3:36:43 PM UTC-5, Peter Hayes wrote:
>
> Thanks for the insight.  I do see that this will cause a burden on the 
> master node.  Since we are using CJP-PSE, that is mitigated somewhat as we 
> will be running quite a few masters so the ratio of jobs to masters won't 
> be terribly high.  
>
> Reusing workspaces isn't an option for us due to the architecture of 
> CJP-PSE at the moment. I actually did start using an externally mounted 
> volume but as you note, we will run into concurrency issues with shared 
> caches on the host instance and there is no reliable way to separate the 
> caches while still getting the benefit of caches as there is no distinct 
> executor number (always 1). If there was some enhancement to CJP to 
> transparently manage workspaces across executor (and support parallel build 
> execution) then we could look at that.  I did raise this with the PSE team 
> in any event a while back and I imagine that this will need to be addressed 
> as it is a step back in performance from classic persistent Jenkins 
> executors.
>
> The other thought that crossed my mind since we are running in AWS is to 
> leverage a more scalable file store within AWS like S3.  Both artifact 
> archiving and dependency caching could be good candidates. It would be cool 
> if there was an S3 backing of FilePath abstraction and plugin developers 
> could seamlessly access it via Project.getStoragePath() or something like 
> that.  Then a plugin like I am proposing could provide a more scalable 
> solution without hardwiring to S3.  I'm guessing I'm not the first to think 
> of it so there are likely challenges in doing so. 
>
> On Wednesday, November 30, 2016 at 2:04:03 PM UTC-5, Jesse Glick wrote:
>>
>> On Wed, Nov 30, 2016 at 10:18 AM, Peter Hayes  wrote: 
>> > each time you run a job, you 
>> > start with a fresh container without any previously cached dependencies 
>> (we 
>> > use gradle generally).  This increases the length of the build and adds 
>> > network traffic to our Artifactory instance.  I looked around for 
>> existing 
>> > plugins but didn't find any so I have started a plugin[1] based on 
>> > SimpleBuildWrapper that stores a configured set of files on the master 
>> at 
>> > the end of the build and then on the next build downloads them to 
>> master in 
>> > the original location. 
>>
>> This seems like a poor approach; rather than overloading Artifactory, 
>> you will be overloading the Jenkins master. Archiving artifacts via 
>> the Remoting channel can already wreck performance; you are talking 
>> about potentially orders of magnitude more traffic than that. 
>>
>> There are two basic approaches to this kind of problem. One, which 
>> assumes that the agents reuse workspaces between builds, is to set the 
>> local repository/cache location to a workspace location. The 
>> `docker-workflow` demo does this: 
>>
>>
>> https://github.com/jenkinsci/docker-workflow-plugin/blob/46432bbe36af17dac93cfedcc93ffa51beba1343/demo/repo/flow.groovy#L20-L22
>>  
>>
>> The other approach is to mount a volume containing the cache, letting 
>> the Docker daemon handle the storage, which the 
>> `parallel-test-executor` demo does: 
>>
>>
>> https://github.com/jenkinsci/parallel-test-executor-plugin/blob/3961df3784045df1f6f285bc2b685ead4bc8593b/demo/Makefile#L3-L27
>>  
>>
>> The volume-based approach is probably the more scalable, though there 
>> are two points to beware: at least Maven’s `install:install` will dump 
>> locally built artifacts into the repository alongside downloaded 
>> releases (probably Gradle does something similar); and Maven’s Aether 
>> repository manager is by default not thread-safe (Takari fixes this). 
>> Maven 5 may allow the cache to be properly separated (again I am not 
>> sure how Gradle fares here); in the meantime you may need to ensure 
>> that there is a distinct volume for every potentially concurrent 
>> build, for example keyed by `${JOB_NAME}/${EXECUTOR_NUMBER}`. 
>>
>> At any rate the exact solution chosen is going to depend on details of 
>> how agents are provisioned and workspaces managed, so at root this 
>> might simply be an RFE for CJP-PSE. 
>>
>

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

Re: New Job Cacher plugin to cache dependencies of builds on docker based executors

[Peter Hayes]

Thanks for the insight.  I do see that this will cause a burden on the 
master node.  Since we are using CJP-PSE, that is mitigated somewhat as we 
will be running quite a few masters so the ratio of jobs to masters won't 
be terribly high.  

Reusing workspaces isn't an option for us due to the architecture of 
CJP-PSE at the moment. I actually did start using an externally mounted 
volume but as you note, we will run into concurrency issues with shared 
caches on the host instance and there is no reliable way to separate the 
caches while still getting the benefit of caches as there is no distinct 
executor number (always 1). If there was some enhancement to CJP to 
transparently manage workspaces across executor (and support parallel build 
execution) then we could look at that.  I did raise this with the PSE team 
in any event a while back and I imagine that this will need to be addressed 
as it is a step back in performance from classic persistent Jenkins 
executors.

The other thought that crossed my mind since we are running in AWS is to 
leverage a more scalable file store within AWS like S3.  Both artifact 
archiving and dependency caching could be good candidates. It would be cool 
if there was an S3 backing of FilePath abstraction and plugin developers 
could seamlessly access it via Project.getStoragePath() or something like 
that.  Then a plugin like I am proposing could provide a more scalable 
solution without hardwiring to S3.  I'm guessing I'm not the first to think 
of it so there are likely challenges in doing so. 

On Wednesday, November 30, 2016 at 2:04:03 PM UTC-5, Jesse Glick wrote:
>
> On Wed, Nov 30, 2016 at 10:18 AM, Peter Hayes  > wrote: 
> > each time you run a job, you 
> > start with a fresh container without any previously cached dependencies 
> (we 
> > use gradle generally).  This increases the length of the build and adds 
> > network traffic to our Artifactory instance.  I looked around for 
> existing 
> > plugins but didn't find any so I have started a plugin[1] based on 
> > SimpleBuildWrapper that stores a configured set of files on the master 
> at 
> > the end of the build and then on the next build downloads them to master 
> in 
> > the original location. 
>
> This seems like a poor approach; rather than overloading Artifactory, 
> you will be overloading the Jenkins master. Archiving artifacts via 
> the Remoting channel can already wreck performance; you are talking 
> about potentially orders of magnitude more traffic than that. 
>
> There are two basic approaches to this kind of problem. One, which 
> assumes that the agents reuse workspaces between builds, is to set the 
> local repository/cache location to a workspace location. The 
> `docker-workflow` demo does this: 
>
>
> https://github.com/jenkinsci/docker-workflow-plugin/blob/46432bbe36af17dac93cfedcc93ffa51beba1343/demo/repo/flow.groovy#L20-L22
>  
>
> The other approach is to mount a volume containing the cache, letting 
> the Docker daemon handle the storage, which the 
> `parallel-test-executor` demo does: 
>
>
> https://github.com/jenkinsci/parallel-test-executor-plugin/blob/3961df3784045df1f6f285bc2b685ead4bc8593b/demo/Makefile#L3-L27
>  
>
> The volume-based approach is probably the more scalable, though there 
> are two points to beware: at least Maven’s `install:install` will dump 
> locally built artifacts into the repository alongside downloaded 
> releases (probably Gradle does something similar); and Maven’s Aether 
> repository manager is by default not thread-safe (Takari fixes this). 
> Maven 5 may allow the cache to be properly separated (again I am not 
> sure how Gradle fares here); in the meantime you may need to ensure 
> that there is a distinct volume for every potentially concurrent 
> build, for example keyed by `${JOB_NAME}/${EXECUTOR_NUMBER}`. 
>
> At any rate the exact solution chosen is going to depend on details of 
> how agents are provisioned and workspaces managed, so at root this 
> might simply be an RFE for CJP-PSE. 
>

-- 
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/0ab8e598-1bc9-4602-ab00-1fcdd33590d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Job Cacher plugin to cache dependencies of builds on docker based executors

[Jesse Glick]

On Wed, Nov 30, 2016 at 10:18 AM, Peter Hayes  wrote:
> each time you run a job, you
> start with a fresh container without any previously cached dependencies (we
> use gradle generally).  This increases the length of the build and adds
> network traffic to our Artifactory instance.  I looked around for existing
> plugins but didn't find any so I have started a plugin[1] based on
> SimpleBuildWrapper that stores a configured set of files on the master at
> the end of the build and then on the next build downloads them to master in
> the original location.

This seems like a poor approach; rather than overloading Artifactory,
you will be overloading the Jenkins master. Archiving artifacts via
the Remoting channel can already wreck performance; you are talking
about potentially orders of magnitude more traffic than that.

There are two basic approaches to this kind of problem. One, which
assumes that the agents reuse workspaces between builds, is to set the
local repository/cache location to a workspace location. The
`docker-workflow` demo does this:

https://github.com/jenkinsci/docker-workflow-plugin/blob/46432bbe36af17dac93cfedcc93ffa51beba1343/demo/repo/flow.groovy#L20-L22

The other approach is to mount a volume containing the cache, letting
the Docker daemon handle the storage, which the
`parallel-test-executor` demo does:

https://github.com/jenkinsci/parallel-test-executor-plugin/blob/3961df3784045df1f6f285bc2b685ead4bc8593b/demo/Makefile#L3-L27

The volume-based approach is probably the more scalable, though there
are two points to beware: at least Maven’s `install:install` will dump
locally built artifacts into the repository alongside downloaded
releases (probably Gradle does something similar); and Maven’s Aether
repository manager is by default not thread-safe (Takari fixes this).
Maven 5 may allow the cache to be properly separated (again I am not
sure how Gradle fares here); in the meantime you may need to ensure
that there is a distinct volume for every potentially concurrent
build, for example keyed by `${JOB_NAME}/${EXECUTOR_NUMBER}`.

At any rate the exact solution chosen is going to depend on details of
how agents are provisioned and workspaces managed, so at root this
might simply be an RFE for CJP-PSE.

-- 
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/CANfRfr3pkMzJ9MzMFhUPNRkePJCM3EeyDd3C1KrgAtXvnnZnWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request ownership/action for a plugin (klocwork)

[Daniel Beck]

> On 28.11.2016, at 17:44, Jacob Larfors  wrote:
> 
> Awesome, and thanks Daniel & Gregory.

We have control over the klocwork plugin. It currently resides in

https://github.com/jenkinsci-transfer/klocwork-plugin

I'll rename the existing repo and move this one into jenkinsci as soon as you 
acknowledge; as it'll be the same remote URL in Git and could cause confusion 
when I do this unexpectedly.

-- 
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/EF9A65AD-9341-4319-952B-C31A255C54C9%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Guidance on how to release a new version of a plugin with a breaking change

[Jesse Glick]

On Tue, Nov 29, 2016 at 3:04 PM, 'Claudiu Guiman' via Jenkins
Developers  wrote:
> We’re currently working on storing the credentials of Azure storage plugin
> in the Credentials Manager. When we’ll release, upgrading from an older
> version to the latest will remove existing credentials and the users will
> have to manually add them again.

Plugins are routinely switched to Credentials with compatibility code
that automatically migrates existing secrets. There are numerous
examples you can find; here is one:

https://github.com/jenkinsci/ssh-slaves-plugin/blob/ae2d6dee1a03a155c991809a4fcac11c5537bdd9/src/main/java/hudson/plugins/sshslaves/SSHLauncher.java#L512-L546

-- 
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/CANfRfr3UoeQfQ2vkGM-Gr6UXa7NP2dv%2BtGvypaLatOnErt96zA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

New Job Cacher plugin to cache dependencies of builds on docker based executors

[Peter Hayes]

Hi,

We are using Cloudbees Private SaaS Edition which utilizes docker 
containers as executors.  A side effect of this is that each time you run a 
job, you start with a fresh container without any previously cached 
dependencies (we use gradle generally).  This increases the length of the 
build and adds network traffic to our Artifactory instance.  I looked 
around for existing plugins but didn't find any so I have started a 
plugin[1] based on SimpleBuildWrapper that stores a configured set of files 
on the master at the end of the build and then on the next build downloads 
them to master in the original location. 

I still have more work remaining but prior to investing more time, I wanted 
to check with this group to see if it makes sense to complete this or if 
there is a better option. I also had seen a post[2] on the user's list a 
few months ago looking for a similar capability that didn't come up with 
anything.

Thanks,
Pete

[1] https://github.com/petehayes/jobcacher-plugin
[2] https://groups.google.com/forum/#!topic/jenkinsci-users/n0A1qBLe2Is

-- 
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/381ee609-3568-4b4d-9930-978ec2378c7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin wiki page is not updated

[Daniel Beck]

> On 30.11.2016, at 15:46, Вячеслав Гайдаржи  
> wrote:
> 
> I saved the edit and captcha was correct. Tried 2 times.

Well, I tried, including captcha, and my edits show up.

Note that in my experience the wiki cannot handle editing multiple wiki pages 
in parallel. Start one wiki page edit, and finish it, before moving on to 
another wiki page.

-- 
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/2B53C382-F3DE-4D4A-B9A1-F3CAFFB72F4D%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin wiki page is not updated

[Вячеслав Гайдаржи]

Ok, I tried one more time and it worked. 
Yesterday, for some reason, edit weren't applied on wiki page.

Thanks.

On Wednesday, November 30, 2016 at 4:46:56 PM UTC+2, Вячеслав Гайдаржи 
wrote:
>
> I saved the edit and captcha was correct. Tried 2 times.
>
> On Wednesday, November 30, 2016 at 3:34:43 PM UTC+2, Daniel Beck wrote:
>>
>>
>> > On 30.11.2016, at 11:30, Вячеслав Гайдаржи  
>> wrote: 
>> > 
>> > is this issue related to Confluence cache again 
>>
>> I don't think so, there are no new page versions: 
>>
>>
>> https://wiki.jenkins-ci.org/pages/viewpreviousversions.action?pageId=73532169
>>  
>>
>> I don't know what you edited, but it appears you didn't save. 
>>
>>

-- 
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/26b939b2-8908-4613-bdcb-13356d02a3e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin wiki page is not updated

[Вячеслав Гайдаржи]

I saved the edit and captcha was correct. Tried 2 times.

On Wednesday, November 30, 2016 at 3:34:43 PM UTC+2, Daniel Beck wrote:
>
>
> > On 30.11.2016, at 11:30, Вячеслав Гайдаржи  > wrote: 
> > 
> > is this issue related to Confluence cache again 
>
> I don't think so, there are no new page versions: 
>
>
> https://wiki.jenkins-ci.org/pages/viewpreviousversions.action?pageId=73532169 
>
> I don't know what you edited, but it appears you didn't save. 
>
>

-- 
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/c414ae99-ed91-48fa-8739-baa6ba53c906%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Develop a custom step that would make pipeline wait for a webhook

[Julien HENRY]

Hi Jesse,

Thanks for the pointers.

2016-11-29 0:51 GMT+01:00 Jesse Glick :

> On Fri, Nov 25, 2016 at 4:14 AM, Julien HENRY
>  wrote:
> > I found this ticket https://issues.jenkins-ci.org/browse/JENKINS-27127
> that
> > is really close to what we need.
>
> Yes, sounds like it. The issue needs to be “defuzzed” somewhat:
> concrete proposals written up, possibly broken into multiple features.
>
> > Is there any progress on that topic?
>
> Not currently.
>
> > Waiting for this generic step, do you think it would be possible to
> > implement the feature with a custom step?
>
> Sure, there is nothing stopping you from writing a limited version of
> this feature tailored to your needs.
>
> https://github.com/jenkinsci/workflow-step-api-plugin/#
> creating-an-asynchronous-step
>
> plus probably an `UnprotectedRootAction` (take care to consider
> malicious payloads).
>
> --
> 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/C3rixeHrSrY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CANfRfr0eoqDrV_sMtvN7XR3aPExECjwki4Ckzqg8O93H
> LKL08A%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAD9wyxHWayrhCVTAz_j%3DS%3DgJXpzQgRuO47%3DOZoUtASuPpHXfRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin wiki page is not updated

[Daniel Beck]

> On 30.11.2016, at 11:30, Вячеслав Гайдаржи  
> wrote:
> 
> is this issue related to Confluence cache again

I don't think so, there are no new page versions:

https://wiki.jenkins-ci.org/pages/viewpreviousversions.action?pageId=73532169

I don't know what you edited, but it appears you didn't save.

-- 
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/8AFE20F9-D0AF-4777-BBFA-2F1CE531E943%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin wiki page is not updated

[Вячеслав Гайдаржи]

I've successfully released 0.3.0 version of the plugin (LIFX notifier 
plugin) and it's available in Jenkins plugins update list.
In https://updates.jenkins-ci.org/current/update-center.json file 0.3.0 
version of plugin is listed as well.
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/lifx-notifier/ - 
new version is published in Jenkins repo.

I've edited the *wiki* page of the plugin (
https://wiki.jenkins-ci.org/display/JENKINS/LIFX+notifier+plugin), but my 
*edits 
don't appear*. 

Daniel Beck, is this issue related to Confluence cache again?

-- 
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/d3f36507-9810-4f46-8b74-fe5c36034e25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Credentials Provider

[iwarapter]

hi,stephen,

i have a working system provider now, and i can add a credential which gets 
retrieved from a backend on use. its still got some ways to go but id certainly 
appreciate any guides!

-- 
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/5810b298-16ef-4b00-8583-bdc438b84f68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.