Re: Company plugins in Jenkins org

['Daniel Beck' via Jenkins Developers]

On Thu, Oct 21, 2021 at 3:47 PM Baptiste Mathus  wrote:

> Care to elaborate what you mean and how that would work? IIUC, what you're
> describing would quite entail refactoring all existing "xyz-plugin
> developer" groups on GitHub side?
> And as you know we currently have close to no notion of github on RPU
> side, like the names there are only artifactory's ones.
>

Yup, these realms are independent so unless you find a way to have a
tamper-proof bi-directional mapping, there's no need to worry about GH
permissions while dealing with upload permissions. Note that I only
responded to the part around RPU.


>  Do you mean we should improve RPU to better manage multi-modules? In that
> case, I don't disagree, but I think we should put it in a separate bucket
> so we can improve the situation iteratively.
> I think what James describes can be done in a very quick way (still
> clean), and what you describe here seems bigger.
>

I am just pointing out that the use case goes beyond multiple plugins
maintained by the same group, and this change can also benefit others while
the mentioned limitation exists.

-- 
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/CAMo7PtLs27A9ODjSe537Ar3pRwkTYNiFr8WHX88Kd7EQtvUSow%40mail.gmail.com.

Re: Creating a testcontainer for Jenkins Update Center

['Jesse Glick' via Jenkins Developers]

On Wed, Oct 20, 2021 at 10:05 AM Oleg Nenashev 
wrote:

>
>- What would everyone say about introducing dependency on
>testcontainers into Jenkins Test Harness directly?
>
> Why would you need that when you can already add such a test dep yourself?

>
>- Should we go ahead and deprecate Docker Fixtures in favor of
>Testcontainers?
>
> It already basically is, if not formally:
https://github.com/jenkinsci/docker-fixtures#overview If you feel like
actually filing PRs to replace existing usages, go ahead.

-- 
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/CANfRfr3DnOHTZ%2BVz%2BZj0TMk_6TM3mBvHHOq9_fPGQk%2B5JBE_3g%40mail.gmail.com.

Re: Company plugins in Jenkins org

[Tim Jacomb]

Sounds good, could probably have one for the Jenkins core team too in RPU.

On Thu, 21 Oct 2021 at 14:47, Baptiste Mathus  wrote:

>
>
> Le jeu. 21 oct. 2021 à 13:58, 'Daniel Beck' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> a écrit :
>
>>
>>
>> On Thu, Oct 21, 2021 at 1:47 PM 'jn...@cloudbees.com' via Jenkins
>> Developers  wrote:
>>
>>> Additionally to make RPU easier, we are planning to add support for
>>> groups of users so that we would just need to modify a single "group
>>> definition file" to update permissions in artifactory.
>>>
>>
>> Sounds great. I would put the permissions declarations in RPU itself
>> though, to make this just a layer of abstraction on top of the current
>> definitions.
>>
>
> Care to elaborate what you mean and how that would work? IIUC, what you're
> describing would quite entail refactoring all existing "xyz-plugin
> developer" groups on GitHub side?
> And as you know we currently have close to no notion of github on RPU
> side, like the names there are only artifactory's ones.
>
>
>>
>> Another use case, while RPU has purely artifact-based configuration
>> (something I've wanted to change for a while but haven't found the time),
>> would be multimodule projects deploying multiple artifacts. You don't need
>> to be a company maintaining multiple plugins to have trouble with
>> permissions.
>>
>
> Do you mean we should improve RPU to better manage multi-modules? In that
> case, I don't disagree, but I think we should put it in a separate bucket
> so we can improve the situation iteratively.
> I think what James describes can be done in a very quick way (still
> clean), and what you describe here seems bigger.
>
> Still, I certainly agree it makes sense to define the full & final
> "desired state" we want to be in. I _think_ this is what you're talking
> about Daniel.
>
> --
>> 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/CAMo7PtLX-wWQXYaX6RAR2DWXzU-_ABEHBNDF%3D7Tu8zNCbWYJKw%40mail.gmail.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS53HetnKcjS%2BZWRanidi0wL5uDNvh%3De7gUyOu1gbFUb_A%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bif4_3ryMaEnDOgH50jnvaUpUM%3DRyz7WYVm3B6yoOMhNMA%40mail.gmail.com.

Re: Company plugins in Jenkins org

[Baptiste Mathus]

Le jeu. 21 oct. 2021 à 13:58, 'Daniel Beck' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> a écrit :

>
>
> On Thu, Oct 21, 2021 at 1:47 PM 'jn...@cloudbees.com' via Jenkins
> Developers  wrote:
>
>> Additionally to make RPU easier, we are planning to add support for
>> groups of users so that we would just need to modify a single "group
>> definition file" to update permissions in artifactory.
>>
>
> Sounds great. I would put the permissions declarations in RPU itself
> though, to make this just a layer of abstraction on top of the current
> definitions.
>

Care to elaborate what you mean and how that would work? IIUC, what you're
describing would quite entail refactoring all existing "xyz-plugin
developer" groups on GitHub side?
And as you know we currently have close to no notion of github on RPU side,
like the names there are only artifactory's ones.


>
> Another use case, while RPU has purely artifact-based configuration
> (something I've wanted to change for a while but haven't found the time),
> would be multimodule projects deploying multiple artifacts. You don't need
> to be a company maintaining multiple plugins to have trouble with
> permissions.
>

Do you mean we should improve RPU to better manage multi-modules? In that
case, I don't disagree, but I think we should put it in a separate bucket
so we can improve the situation iteratively.
I think what James describes can be done in a very quick way (still clean),
and what you describe here seems bigger.

Still, I certainly agree it makes sense to define the full & final "desired
state" we want to be in. I _think_ this is what you're talking about Daniel.

-- 
> 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/CAMo7PtLX-wWQXYaX6RAR2DWXzU-_ABEHBNDF%3D7Tu8zNCbWYJKw%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS53HetnKcjS%2BZWRanidi0wL5uDNvh%3De7gUyOu1gbFUb_A%40mail.gmail.com.

Request to adopt TestNG result reporter plugin

[Mark Waite]

Darin Pope and I have been live streaming a series of small steps to 
improve a plugin while preparing to adopt the plugin.  We'd like to adopt 
the TestNG result reporter plugin so that we can use it to show how the 
plugin bill of materials makes plugin maintenance easier.

Plugin: https://plugins.jenkins.io/testng-plugin/
Adopters: markewaite, darinpope

I've submitted pull request 2136 
 
requesting 
permissions.

Mark Waite

-- 
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/53f65f1e-1eb3-41b4-96aa-ec504211f542n%40googlegroups.com.

Re: Company plugins in Jenkins org

['Daniel Beck' via Jenkins Developers]

On Thu, Oct 21, 2021 at 1:47 PM 'jn...@cloudbees.com' via Jenkins
Developers  wrote:

> Additionally to make RPU easier, we are planning to add support for groups
> of users so that we would just need to modify a single "group definition
> file" to update permissions in artifactory.
>

Sounds great. I would put the permissions declarations in RPU itself
though, to make this just a layer of abstraction on top of the current
definitions.

Another use case, while RPU has purely artifact-based configuration
(something I've wanted to change for a while but haven't found the time),
would be multimodule projects deploying multiple artifacts. You don't need
to be a company maintaining multiple plugins to have trouble with
permissions.

-- 
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/CAMo7PtLX-wWQXYaX6RAR2DWXzU-_ABEHBNDF%3D7Tu8zNCbWYJKw%40mail.gmail.com.

Re: Company plugins in Jenkins org

['Olblak' via Jenkins Developers]

While I don't know yet how it would work with our existing tooling, I am in 
favor of that approach and that would also be useful for other companies as 
well

On Thursday, 21 October 2021 at 13:47:24 UTC+2 jn...@cloudbees.com wrote:

> Hi all,
>
> CloudBees has a number of plugins in jenkins-ci organisation that we are 
> maintainers of.
>
> Currently when our internal teams change we need to modify multiple GitHub 
> repo settings and associated permissions RPU.  This is cumbersome (and 
> error prone) for us, and for the reviewers of the RPU PRs.
>
> I would like to propose (and ask for) a "CloudBees plugin developers" 
> group in the jenkinsci or that we can add CloudBees developers to and then 
> grant permissions to on the plugins that we maintain.  This will allow us 
> to just modify a single GitHub group and have the permissions updated in 
> all our plugins.
>
> Additionally to make RPU easier, we are planning to add support for groups 
> of users so that we would just need to modify a single "group definition 
> file" to update permissions in artifactory.
>
> This approach would then also be available to other companies with 
> multiple plugins in the Future.
>
> WDYT?
>
> /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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/2b63810e-2f5b-4a39-aea8-872419a6857en%40googlegroups.com.

Company plugins in Jenkins org

['jn...@cloudbees.com' via Jenkins Developers]

Hi all,

CloudBees has a number of plugins in jenkins-ci organisation that we are 
maintainers of.

Currently when our internal teams change we need to modify multiple GitHub 
repo settings and associated permissions RPU.  This is cumbersome (and 
error prone) for us, and for the reviewers of the RPU PRs.

I would like to propose (and ask for) a "CloudBees plugin developers" group 
in the jenkinsci or that we can add CloudBees developers to and then grant 
permissions to on the plugins that we maintain.  This will allow us to just 
modify a single GitHub group and have the permissions updated in all our 
plugins.

Additionally to make RPU easier, we are planning to add support for groups 
of users so that we would just need to modify a single "group definition 
file" to update permissions in artifactory.

This approach would then also be available to other companies with multiple 
plugins in the Future.

WDYT?

/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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/b7504af8-a9ff-4430-ace8-63c6e0250edan%40googlegroups.com.

Re: New LTS baseline selection

[Oleg Nenashev]

2.317 looks good to me. No objections w.r.t 2.318 too, but we do not know a 
full scope yet.
Personally I would be happy to get Winstone BOM into it 
(https://github.com/jenkinsci/winstone/pull/172), but I do not think it is 
a justification on its own.
This patch is just a quality of life improvement for Jenkinsfile Runner

Best regards,
Oleg

On Wednesday, October 20, 2021 at 9:24:46 PM UTC+2 Mark Waite wrote:

> The changelist in 2.317 makes it very attractive to me, including:
>
>- JENKINS-66753 - Ongoing build disappears from build history
>- JENKINS-61212 - Agent handshake fix for websockets on Java 11
>
> Anything older than 2.317 and later than 2.313 would require a backport of 
> JENKINS-66753.
>
> Mark Waite
>
> On Wed, Oct 20, 2021 at 12:31 PM Tim Jacomb  wrote:
>
>> Hi all,
>>
>> It's time to select the next LTS baseline.
>> The best candidate right now appears to be 2.317 or the upcoming 2.318
>>
>> 2.317 fixed JENKINS-66753 
>>  which was reported as a 
>> major issue across a few versions.
>>
>> Thanks
>> Tim
>>
>> -- 
>> 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/CAH-3Bifbmg5g8FXeW_ArLDHqj0BRZkLJuwcUOVBeE9%3DgHCnsYA%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/f44dba88-0682-401e-b9f8-7275de079ba2n%40googlegroups.com.

Re: Jenkins plug-in

['Björn Pedersen' via Jenkins Developers]

ullrich...@gmail.com schrieb am Mittwoch, 20. Oktober 2021 um 17:03:02 
UTC+2:

> As Jim already mentioned, you should use the Git Client Plugin to access 
> the Git repositories. If you need an example on how to use that you can 
> look into the tests of the Git Client Plugin (
> https://plugins.jenkins.io/git-client/) or into the implementation of the 
> Git Forensics Plugin (https://github.com/jenkinsci/git-forensics-plugin).
>
>
>
And maybe also check the git-changelog plugin 
(https://plugins.jenkins.io/git-changelog/).

 

-- 
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/661721ef-5625-4ed3-929b-6126a667898en%40googlegroups.com.