Re: sec-170: What need plugins to do to declare vars they provide?

> On 12.05.2016, at 11:03, Robert Sandell wrote: > > so I'm going to try to hack my way to adding to the safeParameters field > instead Are you trying to force me into removing it? -- You received this message because you are subscribed to the Google Groups "Jenkins

Re: sec-170: What need plugins to do to declare vars they provide?

> On 12.05.2016, at 10:48, 'Björn Pedersen' via Jenkins Developers > wrote: > > Since sec-170 all unknown variables will get dropped. What needs to be done > in a plugin to correctly declare the vars they provide? My blog post mentions a few options towards

Re: sec-170: What need plugins to do to declare vars they provide?

> On 12.05.2016, at 15:08, Robert Sandell wrote: > > System.setProperty("hudson.model.ParametersAction.safeParameters", existing + > "MY,OWN") > seems like a valid option without breaking anything to me? May just be me, but this looks like a clear abuse of the escape

Re: sec-170: What need plugins to do to declare vars they provide?

On Thu, May 12, 2016 at 2:33 PM, Daniel Beck wrote: > > > On 12.05.2016, at 11:03, Robert Sandell wrote: > > > > so I'm going to try to hack my way to adding to the safeParameters field > instead > > Are you trying to force me into removing it? >

Re: sec-170: What need plugins to do to declare vars they provide?

On Thu, May 12, 2016 at 3:52 PM, Daniel Beck wrote: > > > On 12.05.2016, at 15:08, Robert Sandell wrote: > > > > System.setProperty("hudson.model.ParametersAction.safeParameters", > existing + "MY,OWN") > > seems like a valid option without breaking

Re: sec-170: What need plugins to do to declare vars they provide?

> On 12.05.2016, at 16:47, Robert Sandell wrote: > > But at the same time I need to get a fix out for my users. I fear that early implementations to handle this new restriction will be heavily copy/pasted. So even if you intend to switch to a different approach as

Re: sec-170: What need plugins to do to declare vars they provide?

EnvironmentContributor is the worst thing for trigger plugins imho. Trigger plugins injecting known and safe named variables, they should never be filtered out from job variables. Hiding vars for already setuped envs sounds like a disaster. On Thursday, May 12, 2016 at 5:54:26 PM UTC+3, Daniel

sec-170: What need plugins to do to declare vars they provide?

Hi, Since sec-170 all unknown variables will get dropped. What needs to be done in a plugin to correctly declare the vars they provide? Björn -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop

Re: sec-170: What need plugins to do to declare vars they provide?

One alternative is to implement and EnvironmentContributor, one example here https://github.com/jenkinsci/ghprb-plugin/pull/336 If I'm reading the code correctly on ParametersAction the above alternative would still print nasty warnings in the Jenkins log though, so I'm going to try to hack my

Re: About a Jenkins Plugin for my java project(Framework)

What would your plugin need to do? If your framework uses java, selenium and cucumber then testers can use maven, gradle, ant or commandline scripts to run the tests. If your framework outputs test results in cucumber format then there are multiple jenkins plugins available to display test

Re: [GSOC 2016] Support core plugin improvements

+1 from me.. On May 13, 2016 6:13 AM, "Steve Christou" wrote: > @Arnaud @Minudika if you want we can do 8AM On Sunday for you which is > 11:30 AM (GMT +5:30) and 2 AM for me. > > On Wed, May 11, 2016 at 5:43 PM Arnaud Héritier > wrote: > >> I will try

Re: improving WorkspaceCleanupThread in a multi-branch world

So talking in code instead, this could be done in the computed folder: https://github.com/jenkinsci/cloudbees-folder-plugin/pull/62 https://issues.jenkins-ci.org/browse/JENKINS-34781 (doing similar work to what the cleanup thread does, but when it removes the orphaned item). On Friday, May

Re: improving WorkspaceCleanupThread in a multi-branch world

On 05/11/2016 08:47 PM, Jesse Glick wrote: On Wed, May 11, 2016 at 8:30 AM, Oliver Gondža wrote: There is no easy way to map workspace directory to Job(s) that used that No, but you can easily map `Job` to a workspace on a given `Node`. So when a job is deleted, it should

Re: [GSOC 2016] Support core plugin improvements

@Arnaud @Minudika if you want we can do 8AM On Sunday for you which is 11:30 AM (GMT +5:30) and 2 AM for me. On Wed, May 11, 2016 at 5:43 PM Arnaud Héritier wrote: > I will try to be available but it is often less easy for me the WE with my > kids > If it's not between

Re: sec-170: What need plugins to do to declare vars they provide?

Just set variables according to a `Cause` or similar. -- 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

Re: improving WorkspaceCleanupThread in a multi-branch world

On Thu, May 12, 2016 at 5:17 AM, Oliver Gondža wrote: > The workspace can be used by another job's build via custom workspace feature The custom workspace (mis)feature should not be abused to reuse a valid workspace. Anyway we could always check `WorkspaceList` to see if we

Re: improving WorkspaceCleanupThread in a multi-branch world

On Thu, May 12, 2016 at 6:36 PM, Jesse Glick wrote: >> it will not cover any changes to item name > > Sure, but there is only so much we can do. …though we could have an `ItemListener.onLocationChanged` which deletes workspaces from the old location too. -- You received