Hosting Request for Selenium Builder plugin

[Ross Rowe]

Hi, can I please request the following plugin be hosted within the Jenkins 
github:

https://github.com/rossrowe/selenium-builder-plugin - Allows invocation of 
Selenium Builder JSON scripts

Both my github and Jenkins Jira user id is rossrowe.

Cheers,

Ross

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hosting request: visualworks-store-plugin

[Randy Coulman]

I'd like to request hosting for a new plugin for Cincom Visualworks
Smalltalk Store.

The plugin is currently hosted on GitHub at:
https://github.com/randycoulman/visualworks-store-plugin.git

My GitHub and jenkins-ci.org id's are both randycoulman.

Thanks!

Randy
-- 
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/groups/opt_out.

Re: Commit Access for plugin

[Brian]

https://github.com/btelintelo/joeyvotto-plugin

On Saturday, February 23, 2013 11:22:23 AM UTC-5, R Tyler Croy wrote:
>
>
> On Sat, 23 Feb 2013, Brian wrote: 
>
> > I would like commit access for my plugin. 
>
>
> Without knowing what plugin is "my plugin", I'm not sure we can do 
> anything. 
>
> What plugin are you talking about? 
>
> - R. Tyler Croy 
> -- 
> Code: https://github.com/rtyler 
>  Chatter: https://twitter.com/agentdero 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proper way to do permission checks

[JoelJ]

Ok, I found this 
(https://wiki.jenkins-ci.org/display/JENKINS/Making+your+plugin+behave+in+secured+Jenkins)
 
right after I posted here (naturally). So I changed my check to look like 
this:

private boolean userHasPermission(Permission permission) {
ACL acl = Jenkins.getInstance().getACL();
return acl.hasPermission(Jenkins.getAuthentication(), permission);
}

Now I have the opposite problem: When logged in as the Readonly user, and I 
pass Permission.READ into that method, it returns "false". However, the 
Admin user has access as expected.

Any ideas?

On Saturday, February 23, 2013 2:29:04 PM UTC-7, JoelJ wrote:
>
> After searching around on Google and asking in IRC (it's saturday, I 
> wasn't really expecting much activity ;) ), I've decided I should ask here.
>
> What's the proper way to check if a user has permissions to do something? 
> Here's what I have:
>
> if(currentUser.hasPermission(Permission.DELETE)) {
>
> //procede with delete
>
> } 
>
>
> So on my test Jenkins instance I set up Matrix security and a readonly 
> user. Here's what it looks like:
>
>
> 
>  
> However, the above check always returns true. In fact, with a debugger I 
> tried every different Permission and it always returns true.
>
> I'm writing a plugin that allows users to upload files to Jenkins and if 
> you have access to delete, you see a little "Delete" button, but I 
> obviously don't want just anyone to do that.
>
> It seems like I'm completely missing something here. Any ideas?
>
> Thanks,
>
> -Joel
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Proper way to do permission checks

[JoelJ]

After searching around on Google and asking in IRC (it's saturday, I wasn't 
really expecting much activity ;) ), I've decided I should ask here.

What's the proper way to check if a user has permissions to do something? 
Here's what I have:

if(currentUser.hasPermission(Permission.DELETE)) {

//procede with delete

} 


So on my test Jenkins instance I set up Matrix security and a readonly 
user. Here's what it looks like:


 
However, the above check always returns true. In fact, with a debugger I 
tried every different Permission and it always returns true.

I'm writing a plugin that allows users to upload files to Jenkins and if 
you have access to delete, you see a little "Delete" button, but I 
obviously don't want just anyone to do that.

It seems like I'm completely missing something here. Any ideas?

Thanks,

-Joel

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Experimenting with building an alternative Jenkins UI

[Kohsuke Kawaguchi]

Thanks for your thoughts.

I actually think the abstraction behind how we expose data via JSON is
fundamentally sane --- it's basically the same object graph that the server
has,

I think the problem you are seeing is that the default behavior of
"traverse this graph depth-first to the depth 1" isn't particularly useful.
Instead, you should use the tree parameter to select what portions of the
object graph you want to retrieve.

I've been meaning to add the object graph navigator, and I think something
like that makes it clearer what the underlying data model is.


2013/2/23 R. Tyler Croy 

> At the FOSDEM Developer Meetup, I suggested that building a better UI on
> top of
> Jenkins would likely be easiest by ripping the UI out of the Java layer and
> going the more common API + JavaScript application approach which is
> commonly
> used for web applications today.
>
>
> I spent some time experimenting with this while traveling across Europe and
> here are the biggest issues I've identified:
>
>   * The Jenkins remote API is CRAZY (not good). The data you will find on
> the
> /api version of a URL often times doesn't
> map ot what you see on the page.
>
> Take the "home page" for example, whose API response has:
>   * Some information about executors on the master, but nothing on the
> slaves
>   * Contains information about slave ports?
>   * Lists jobss that, if you have a different default view, are not the
> same as the default view (not sure if this is good or bad)
>
> There isn't a clear "object model" being exposed for jobs, depending on
> your depth, you might get a lot more information which /seems/
> relatively
> haphazardly put together, instead of exposing a logical Job object
> over the
> API
>
>   * To work effectively, an alternate API would *have* to run as a plugin,
> to
> run on the same domain to avoid needing to use the JSONP API which
> would
> make write operations difficult. This would make (IMHO) things a bit
> tricky
> for distribution/updates of the UI App.
>
>   * Exposing plugin views is going to be a scary/difficult. Right now you
> have
> Jelly/Groovy views that get smattered onto the page, and in many cases
> can
> and *will* break the page (configuration pages, lookin' at you). I'm
> looking at other examples of "JS SDKs" (e.g.  >)
> for inspiration on how to make JS views/functionality more pluggable,
> while
> maintaining some semblance of safety, to protect the page from bad code
> injected by plugins
>
>
> My current mode of thinking (and why I asked about Groovy plugins before)
> is
> that what is needed is a plugin that provides a more suitable API for the
> task
> at hand, but also can bundle up the UI App and serve it off of Jenkins
> itself.
>
>
> Time permitting I'll be exploring that a bit more, I just wanted to let
> everybody know where my head was at after some experimentation.
>
>
> Cheers
> - R. Tyler Croy
> --
> Code: https://github.com/rtyler
>  Chatter: https://twitter.com/agentdero
>



-- 
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/groups/opt_out.

Re: Commit Access for plugin

[R. Tyler Croy]

On Sat, 23 Feb 2013, Brian wrote:

> I would like commit access for my plugin.


Without knowing what plugin is "my plugin", I'm not sure we can do anything.

What plugin are you talking about?

- R. Tyler Croy
--
Code: https://github.com/rtyler
 Chatter: https://twitter.com/agentdero


signature.asc
Description: Digital signature

Commit Access for plugin

[Brian]

I would like commit access for my plugin.

user: btelintelo

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Experimenting with building an alternative Jenkins UI

[R. Tyler Croy]

At the FOSDEM Developer Meetup, I suggested that building a better UI on top of
Jenkins would likely be easiest by ripping the UI out of the Java layer and
going the more common API + JavaScript application approach which is commonly
used for web applications today.


I spent some time experimenting with this while traveling across Europe and
here are the biggest issues I've identified:

  * The Jenkins remote API is CRAZY (not good). The data you will find on the
/api version of a URL often times doesn't
map ot what you see on the page.

Take the "home page" for example, whose API response has:
  * Some information about executors on the master, but nothing on the
slaves
  * Contains information about slave ports?
  * Lists jobss that, if you have a different default view, are not the
same as the default view (not sure if this is good or bad)

There isn't a clear "object model" being exposed for jobs, depending on
your depth, you might get a lot more information which /seems/ relatively
haphazardly put together, instead of exposing a logical Job object over the
API

  * To work effectively, an alternate API would *have* to run as a plugin, to
run on the same domain to avoid needing to use the JSONP API which would
make write operations difficult. This would make (IMHO) things a bit tricky
for distribution/updates of the UI App.

  * Exposing plugin views is going to be a scary/difficult. Right now you have
Jelly/Groovy views that get smattered onto the page, and in many cases can
and *will* break the page (configuration pages, lookin' at you). I'm
looking at other examples of "JS SDKs" (e.g. )
for inspiration on how to make JS views/functionality more pluggable, while
maintaining some semblance of safety, to protect the page from bad code
injected by plugins


My current mode of thinking (and why I asked about Groovy plugins before) is
that what is needed is a plugin that provides a more suitable API for the task
at hand, but also can bundle up the UI App and serve it off of Jenkins itself.


Time permitting I'll be exploring that a bit more, I just wanted to let
everybody know where my head was at after some experimentation.


Cheers
- R. Tyler Croy
--
Code: https://github.com/rtyler
 Chatter: https://twitter.com/agentdero


signature.asc
Description: Digital signature

Re: Weblogic plugin question

[RCR]

Hi Thibault,

Loonie said me the 1.4 version has fixed his issue.

Can you send me the job log?
 
Did you try to leave "Repertoire où trouver la ressource à deployer" blank. By 
default the plugin lookups for job workspace.
 
Regards,
 
> Message du 22/02/13 15:18
> De : "tduchateau" 
> A : jenkinsci-dev@googlegroups.com
> Copie à : 
> Objet : Re: Weblogic plugin question
> 
> Hi Raph,
> 
> I'm testing the last release (1.4) with a freestyle project and I'm facing
> the same issue as Lonnie.
> 
> ERROR: [WeblogicDeploymentPlugin] - Failed to get artifact from archive
> directory : [WeblogicDeploymentPlugin] - No artifact to deploy found.
> 
> I tried filling in the "Built resource To deploy" regex and leaving it
> blank.
> 
> Actually, my EAR is generated in workspace/target. So I filled in the
> "Repertoire où trouver la ressource à deployer" field with "target" but I
> still can't get it working.
> 
> Any idea ?
> Thanks !
> 
> 
> 
> --
> View this message in context: 
> http://jenkins.361315.n4.nabble.com/Weblogic-plugin-question-tp4654759p4656438.html
> Sent from the Jenkins dev mailing list archive at Nabble.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/groups/opt_out.
> 
> 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.