repo access for non plugin stuff

[James Nord]

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

[Daniel Beck]

>
> On 20. Sep 2017, at 22:31, James Nord <jn...@cloudbees.com> 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?

[James Nord]

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