repo access for non plugin stuff

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

repo access for non plugin stuff

James Nord-3
Hi all,

I am working on upgrading stapler to use the servlet 3.1 API (https://github.com/stapler/stapler/pull/131)

In order to demonstrate the changes in Jenkins I would like to be able to push a snapshot of stapler to our repo so the PR can consume it.

I would also like to be able to push a custom version (0) or the old servlet-api ( javax.servlet:servlet-api:0) to prevent any plugins from getting a version of it when using a new core.

(and at the same time a version zero of commons-logging for the same reason)

Is this possible - seems like its not a HOSTING request nor an INFRA request so not sure what route to go down to ask for this...

Regards

/James

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a66aaeee-36ac-45e4-96d0-cdf2a39c49b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: repo access for non plugin stuff

Daniel Beck
>
> On 20. Sep 2017, at 22:31, James Nord <[hidden email]> wrote:
>
> In order to demonstrate the changes in Jenkins I would like to be able to push a snapshot of stapler to our repo so the PR can consume it.
>

Any registered user can deploy any snapshot. (This was changed shortly after introduction of per-artifact permissions as it wasn't really necessary to ensure no unauthorized bits get distributed, and it makes multi-repo PRs easier.)

> I would also like to be able to push a custom version (0) or the old servlet-api ( javax.servlet:servlet-api:0) to prevent any plugins from getting a version of it when using a new core.
>
> (and at the same time a version zero of commons-logging for the same reason)
>
> Is this possible - seems like its not a HOSTING request nor an INFRA request so not sure what route to go down to ask for this...


File a PR to https://github.com/jenkins-infra/repository-permissions-updater/ (prefix probably "component" instead of "plugin") and explain it in the PR description.

Similar recently changed files were for example https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/component-docker-java-shaded.yml or https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/component-trilead-ssh2.yml -- while unusual it's not unprecedented.

Is this something better resolved by JENKINS-30685 and/or JENKINS-28942?

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1D58B4F4-85E9-4F6C-8F66-16EE1C6B6F8C%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: repo access for non plugin stuff

James Nord-3


On Thursday, September 21, 2017 at 12:28:01 AM UTC+1, Daniel Beck wrote:
>
> On 20. Sep 2017, at 22:31, James Nord <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="0Y4G_1pyBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jn...@...> wrote:
>
> In order to demonstrate the changes in Jenkins I would like to be able to push a snapshot of stapler to our repo so the PR can consume it.
>

Any registered user can deploy any snapshot. (This was changed shortly after introduction of per-artifact permissions as it wasn't really necessary to ensure no unauthorized bits get distributed, and it makes multi-repo PRs easier.)

> I would also like to be able to push a custom version (0) or the old servlet-api ( javax.servlet:servlet-api:0) to prevent any plugins from getting a version of it when using a new core.
>
> (and at the same time a version zero of commons-logging for the same reason)
>
> Is this possible - seems like its not a HOSTING request nor an INFRA request so not sure what route to go down to ask for this...


File a PR to <a href="https://github.com/jenkins-infra/repository-permissions-updater/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkins-infra%2Frepository-permissions-updater%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFcWVq8KHaUItF9eFurQcXeiQVuGw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkins-infra%2Frepository-permissions-updater%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFcWVq8KHaUItF9eFurQcXeiQVuGw&#39;;return true;">https://github.com/jenkins-infra/repository-permissions-updater/ (prefix probably "component" instead of "plugin") and explain it in the PR description.

Similar recently changed files were for example <a href="https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/component-docker-java-shaded.yml" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkins-infra%2Frepository-permissions-updater%2Fblob%2Fmaster%2Fpermissions%2Fcomponent-docker-java-shaded.yml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHxzxlNQa1UA9-ua2InDDbwuky99w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkins-infra%2Frepository-permissions-updater%2Fblob%2Fmaster%2Fpermissions%2Fcomponent-docker-java-shaded.yml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHxzxlNQa1UA9-ua2InDDbwuky99w&#39;;return true;">https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/component-docker-java-shaded.yml or <a href="https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/component-trilead-ssh2.yml" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkins-infra%2Frepository-permissions-updater%2Fblob%2Fmaster%2Fpermissions%2Fcomponent-trilead-ssh2.yml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF7p31LxzQPhnxLB7mppcZ9EEn4Nw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkins-infra%2Frepository-permissions-updater%2Fblob%2Fmaster%2Fpermissions%2Fcomponent-trilead-ssh2.yml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF7p31LxzQPhnxLB7mppcZ9EEn4Nw&#39;;return true;">https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/component-trilead-ssh2.yml -- while unusual it's not unprecedented.


Thanks - will do.

 
Is this something better resolved by JENKINS-30685 and/or JENKINS-28942?

Not really but it means at least with this madness you will never have a servlet-api < 3.1 on your classpath.
which causes compilation errors if you try and use any of the new APIs :-)
A similar route may also be used to fix the issue Jesse was reporting here

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3f4a6ce6-2d15-47ce-9555-4da3899b8328%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.