Re: Advisor plugin ownership

[timja...@gmail.com]

Only the repo permission PR is needed :)

sorting for you

On Thursday, 8 October 2020 at 08:55:38 UTC+1 pib...@gmail.com wrote:

> Hello
>
> I'd like to be added to the maintainers of the cloudbees-jenkins-advisor. 
> Arnaud, one of the maintainers, agrees with this request as visible in 
> https://github.com/jenkinsci/cloudbees-jenkins-advisor-plugin/pull/76#issue-499668972
>
>- 
>
>Plugin: https://github.com/jenkinsci/cloudbees-jenkins-advisor-plugin
>- 
>
>GitHub username: PierreBtz
>- 
>
>Infra account: pierrebtz
>
> I also filled the repo permission updater PR: 
> https://github.com/jenkins-infra/repository-permissions-updater/pull/1692
>

-- 
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/3d69bf8b-1317-4ced-8def-c45fdb33d3e3n%40googlegroups.com.

Re: Adopt Post Build Task Plugin

[timja...@gmail.com]

Two week timeout completed, I'll proceed with this adoption request

On Sunday, 1 November 2020 at 09:11:02 UTC timja...@gmail.com wrote:

> Hi
>
> I would like to adopt https://github.com/jenkinsci/postbuild-task-plugin/
>
> Last adopted here https://groups.google.com/g/jenkinsci-dev/c/0l0443e10hc 
> but seems nothing was done on it.
>
> I just plan to deliver a fix for 
> https://issues.jenkins-ci.org/browse/JENKINS-64088
>
> 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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/713dd1de-44fb-45b8-8d42-92824e5b2b00n%40googlegroups.com.

Re: Future of Jenkins CLI apps: args4j vs. picocli or other CLI libs

[timja...@gmail.com]

+100 to moving to picocli

On Monday, 23 November 2020 at 21:02:06 UTC msi...@cloudbees.com wrote:

> I'd be hugely in favor of using picocli. It's what I use in my own CLI
> tools, and the original author of the library is someone I know and
> have worked on OSS projects with (Log4j2 in particular) in the past.
> I'm generally in favor of migrating to maintained libraries,
> especially if it means maintaining less forks in the org or at least
> adopting more commonly used libraries in the modern day.
>
> On Mon, Nov 23, 2020 at 2:57 PM Oleg Nenashev  wrote:
> >
> > Hi all,
> >
> > I am currently working on supporting sub-commands in Jenkinsfile Runner 
> (issue #429). Apart from JFR, the Plugin Installation Manager Tool is also 
> a component which implements multiple commands at the moment, and hence 
> could benefit from sub-commands that could simplify the API. There are also 
> other projects which could use sub-commands (e.g. Custom WAR Packager, 
> Plugin Compatibility Tester, maybe even Jenkins core).
> >
> > Currently JFR, as the most of the Jenkins ecosystem, uses the args4j 
> library created by Kohsuke: https://github.com/kohsuke/args4j . The 
> library does the CLI management job quite well, and it is not actively 
> developed at the moment. It does not support sub-commands, auto-completion 
> or advanced help generation (e.g. entry ordering). All of that could be 
> implemented or worked around, but I wonder whether it makes sense to invest 
> much time in that when there are other libraries which support such "more 
> advanced" functionality. It would be great to get opinions of other 
> contributors.
> >
> > There are 2 ways:
> >
> > Keep updating the args4j library. Again, it does the job quite well and 
> can be updated if needed. Kohsuke is still around when a release is needed. 
> It would save time in short term, but in longer term it may create 
> obstacles. The library development is not very active at the moment.
> > Gradually adopt another CLI library (e.g. 
> https://github.com/remkop/picocli) in components which need advanced CLI. 
> Contribute fixes there if needed. This way would allow to save time on 
> implementing features, but it will likely split the tools between 2 
> libraries. It may complicate contributions. Also, migration to a new lib in 
> existing components would require time investment.
> >
> > I would appreciate feedback from others. In JFR I am experimenting with 
> picocli at the moment, but I will fall back to args4j if there is a 
> consensus that we want to focus on it.
> >
> > Best regards,
> > Oleg
> >
> > --
> > 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/9447af42-6a78-4625-a23e-f8d18c4e1890n%40googlegroups.com
> .
>
>
>
> -- 
> Matt Sicker
> Senior Software Engineer, CloudBees
>

-- 
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/210b27b5-c6cf-489b-be1e-722bda9c0152n%40googlegroups.com.

Re: Core Baseline Java8 -> Java11?

[timja...@gmail.com]

Initial attempt here to fix most of the warnings:
https://github.com/jenkinsci/jenkins/pull/5110

Rest of the warnings are caused by groovy and guice, at least on the 
controller startup.

On Tuesday, 8 December 2020 at 03:18:39 UTC msi...@cloudbees.com wrote:

> Jetty 10 requires Java 11, so there’s one concrete reason to upgrade 
> sometime.
>
> On Mon, Dec 7, 2020 at 13:14 Matt Sicker  wrote:
>
>> Oh neat, that's good news! I hope they backport their ChaCha cipher
>> code, too, because that's still only supported by BouncyCastle
>> otherwise for Java 8 as far as I'm aware.
>>
>> On Mon, Dec 7, 2020 at 12:26 PM James Nord  wrote:
>> >
>> > >   and it also natively supports TLS 1.3 which is fairly important
>> > for HTTPS as well as for securing inbound remoting agents.
>> >
>> > FTR that should be available in recent OpenJDK releases.
>> > https://bugs.openjdk.java.net/browse/JDK-8245466
>> >
>> >
>> > On Fri, 4 Dec 2020 at 16:35, Matt Sicker  wrote:
>> >>
>> >> It may be important to note that requiring Java 11 to run Jenkins
>> >> doesn't mean you can't still use it to build Java 8 (or older!)
>> >> projects.
>> >>
>> >> From a user point of view, I'd prefer that we can at least ensure that
>> >> Jenkins runs properly in the latest Java releases. Running a newer JVM
>> >> brings with it all the performance improvements over the past few
>> >> years, and it also natively supports TLS 1.3 which is fairly important
>> >> for HTTPS as well as for securing inbound remoting agents. The
>> >> HttpClient API is one of the nifty features provided since Java 11,
>> >> too, as already mentioned. Project Loom may turn out to be incredibly
>> >> useful for Jenkins. And then there's also potential that the JPMS API
>> >> might be useful for enhancing plugin class loader isolation.
>> >>
>> >> On Fri, Dec 4, 2020 at 4:55 AM jn...@cloudbees.com <
>> jn...@cloudbees.com> wrote:
>> >> >
>> >> > >  is there any advantages in java 11 your looking forward to
>> >> >
>> >> > Personally I would change my code to use a HTTP client library that 
>> has async support, SNI, (all the things you expect) and not rely on a third 
>> party API that does not have stellar backwards compatibility :)
>> >> > 
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html
>> >> >
>> >> >
>> >> > On Friday, December 4, 2020 at 9:03:57 AM UTC ga...@gavinmogan.com 
>> wrote:
>> >> >>
>> >> >> As a non java person, Is there any advantages in java 11 your 
>> looking forward to? ones that might encourage people to upgrade? I know 
>> streams and lambdas were nice in 8(?)
>> >> >>
>> >> >> its my understanding that most things should now compile with java 
>> 11, but not bumping the minimum version yet.
>> >> >>
>> >> >> Gavin
>> >> >>
>> >> >>
>> >> >> On Fri, Dec 4, 2020 at 12:43 AM Ullrich Hafner <
>> ullrich...@gmail.com> wrote:
>> >> >>>
>> >> >>> Ok, I understand that. I wasn’t aware that so may people are still 
>> using Java 8. My students just ask me every time they want to contribute to 
>> my Jenkins plugins why they still need to use that old Java version ;-)
>> >> >>>
>> >> >>> Am 04.12.2020 um 08:34 schrieb Tim Jacomb :
>> >> >>>
>> >> >>> I would be definitely +1 for switching defaults and encouraging 
>> people to use jdk11
>> >> >>>
>> >> >>> And not against updating the minimum version, people will move 
>> when they have to.
>> >> >>>
>> >> >>>
>> >> >>> The problem is that Oracle will provide support until 2030, that 
>> means nobody will be forced in the near future…
>> >> >>>
>> >> >>> At my previous work we moved from 7 to 8 when we had to and it was 
>> no issue...
>> >> >>>
>> >> >>> We’ve been on 11 for awhile here...
>> >> >>>
>> >> >>> Java 8 is 6 years older at this point, yes a lots been backported 
>> but that doesn’t mean we should stay at it forever
>> >> >>>
>> >> >>> Sonarqube recently moved to require java 11 as an example of one 
>> development tool that has gone there before us
>> >> >>>
>> >> >>> Thanks
>> >> >>> Tim
>> >> >>>
>> >> >>>
>> >> >>> On Fri, 4 Dec 2020 at 00:33, Oleg Nenashev  
>> wrote:
>> >> 
>> >>  Yes, the Java 11 adoption is still very low. It was around 30% 
>> last time I have seen the stats. Around 60% of users still run Java 8. With 
>> such a state it does not make sense to drop the Java 8 compatibility 
>> without really serious reasons which we IMHO do not have.
>> >> 
>> >>  On a separate note, a few weeks ago we discussed moving to Java 
>> 11 in the default container tags (`latest`, `stable` and so on). Even in 
>> this case we were far from having a consensus, because it would require a 
>> coordinate update of agents and controllers by many Jenkins users.
>> >> 
>> >>  BR, Oleg
>> >> 
>> >>  On Thursday, December 3, 2020 at 6:40:01 PM UTC+1 Mark Waite 
>> wrote:
>> >> >
>> >> > There are not.  Considering the relatively low adoption rate of 
>> Java 11, I'd personally resist a move to make Java 11 the b

Re: Adopt database-mysql plugin request

[timja...@gmail.com]

Hi David

I would also like to update the database-mysql plugin
Is that fine too?

Thanks
Tim
On Monday, 17 August 2020 at 15:24:33 UTC+1 da...@vanlaatum.id.au wrote:

> Sure
>
> Sent from my iPad
>
> On 17 Aug 2020, at 4:52 pm, Tim Jacomb  wrote:
>
> 
>
> Hi
>
> I would like to adopt https://plugins.jenkins.io/database/
>
> I'm working on pluggable storage for the Junit plugin and would like to 
> refresh the plugin and make some minor improvements.
>
> 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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/e36377d8-360e-4c2c-861e-8f6c88159778n%40googlegroups.com.

Re: Core Baseline Java8 -> Java11?

[timja...@gmail.com]

Brief update on this:

* Mark has updated the website to use Java 11 install instructions
* Core caused illegal reflective access warnings PR is merged
* Stapler illegal reflective access was released in 2.273
* Remaining warnings are mostly caused by groovy which requires some work 
to 
upgrade, https://github.com/jenkinsci/jenkins/pull/5112#issuecomment-744429487 
and https://github.com/jenkinsci/jenkins/pull/5116#issuecomment-744526638 
for background
* I've updated a bunch of old plugins to build and test on java 11 as part 
of tables to divs fixes
* I'm running on java 11 entirely now, and fixing any issue I hit, mostly 
very minor.

I agree with Jesse that we should start testing against Java 17 when the 
previews are released and I'm happy to help with the infra side of that

Thanks
Tim

On Sunday, 13 December 2020 at 11:21:35 UTC timja...@gmail.com wrote:

> Initial attempt here to fix most of the warnings:
> https://github.com/jenkinsci/jenkins/pull/5110
>
> Rest of the warnings are caused by groovy and guice, at least on the 
> controller startup.
>
> On Tuesday, 8 December 2020 at 03:18:39 UTC msi...@cloudbees.com wrote:
>
>> Jetty 10 requires Java 11, so there’s one concrete reason to upgrade 
>> sometime.
>>
>> On Mon, Dec 7, 2020 at 13:14 Matt Sicker  wrote:
>>
>>> Oh neat, that's good news! I hope they backport their ChaCha cipher
>>> code, too, because that's still only supported by BouncyCastle
>>> otherwise for Java 8 as far as I'm aware.
>>>
>>> On Mon, Dec 7, 2020 at 12:26 PM James Nord  wrote:
>>> >
>>> > >   and it also natively supports TLS 1.3 which is fairly important
>>> > for HTTPS as well as for securing inbound remoting agents.
>>> >
>>> > FTR that should be available in recent OpenJDK releases.
>>> > https://bugs.openjdk.java.net/browse/JDK-8245466
>>> >
>>> >
>>> > On Fri, 4 Dec 2020 at 16:35, Matt Sicker  wrote:
>>> >>
>>> >> It may be important to note that requiring Java 11 to run Jenkins
>>> >> doesn't mean you can't still use it to build Java 8 (or older!)
>>> >> projects.
>>> >>
>>> >> From a user point of view, I'd prefer that we can at least ensure that
>>> >> Jenkins runs properly in the latest Java releases. Running a newer JVM
>>> >> brings with it all the performance improvements over the past few
>>> >> years, and it also natively supports TLS 1.3 which is fairly important
>>> >> for HTTPS as well as for securing inbound remoting agents. The
>>> >> HttpClient API is one of the nifty features provided since Java 11,
>>> >> too, as already mentioned. Project Loom may turn out to be incredibly
>>> >> useful for Jenkins. And then there's also potential that the JPMS API
>>> >> might be useful for enhancing plugin class loader isolation.
>>> >>
>>> >> On Fri, Dec 4, 2020 at 4:55 AM jn...@cloudbees.com <
>>> jn...@cloudbees.com> wrote:
>>> >> >
>>> >> > >  is there any advantages in java 11 your looking forward to
>>> >> >
>>> >> > Personally I would change my code to use a HTTP client library that 
>>> has async support, SNI, (all the things you expect) and not rely on a third 
>>> party API that does not have stellar backwards compatibility :)
>>> >> > 
>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html
>>> >> >
>>> >> >
>>> >> > On Friday, December 4, 2020 at 9:03:57 AM UTC ga...@gavinmogan.com 
>>> wrote:
>>> >> >>
>>> >> >> As a non java person, Is there any advantages in java 11 your 
>>> looking forward to? ones that might encourage people to upgrade? I know 
>>> streams and lambdas were nice in 8(?)
>>> >> >>
>>> >> >> its my understanding that most things should now compile with java 
>>> 11, but not bumping the minimum version yet.
>>> >> >>
>>> >> >> Gavin
>>> >> >>
>>> >> >>
>>> >> >> On Fri, Dec 4, 2020 at 12:43 AM Ullrich Hafner <
>>> ullrich...@gmail.com> wrote:
>>> >> >>>
>>> >> >>> Ok, I understand that. I wasn’t aware that so may people are 
>>> still using Java 8. My students just ask me every time they want to 
>>> contribu

Re: Build status vs. checks on jenkins.io

[timja...@gmail.com]

Done

On Wednesday, 6 January 2021 at 21:55:26 UTC Jesse Glick wrote:

> I filed INFRA-2866 to track.
>

-- 
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/84a0504d-74ce-43e0-b650-70d2a49e2aefn%40googlegroups.com.

Re: LTS 2.277.4 RC

[timja...@gmail.com]

Hello 

If you have time please create a PR for the backports

> PD: Something else, I saw that we are not publishing release candidate 
wars into http://mirrors.jenkins-ci.org/war-stable-rc/, Does the process 
change and we are not publishing anymore?

No, there didn't seem to be any point, I've been uploading them to 
artifactory as part of publishing it.

Thanks
Tim

On Wednesday, 21 April 2021 at 10:37:20 UTC+1 Oleg Nenashev wrote:

> Hi Beatriz,
>
> With the recent .3 security release, the entire Release team was quite 
> busy with the out-of-band work.
> AFAICT we do not even have a release lead identified for .4 yet. We need 
> volunteers, right?
>
> P.S: I would be happy to volunteer, but I am snowed under other work 
> threads. If I have spare time, I will help with Hosting request handling 
> which needs a makeshift solution
>
> BR, Oleg
>
> On Wednesday, April 21, 2021 at 10:14:23 AM UTC+2 bmu...@cloudbees.com 
> wrote:
>
>> Hi devs!
>>
>> Next LTS will be on 5th May, Today is the day for RC, but I cannot see it 
>> any PR in the repository with the backports. I’ve just checked 
>> https://issues.jenkins.io/browse/JENKINS-65021?filter=12146 and there 
>> are 6 tickets there:
>>
>> - https://issues.jenkins.io/browse/JENKINS-65021
>> - https://issues.jenkins.io/browse/JENKINS-65327
>> - https://issues.jenkins.io/browse/JENKINS-65308
>> - https://issues.jenkins.io/browse/JENKINS-65336
>> - https://issues.jenkins.io/browse/JENKINS-56934
>> - https://issues.jenkins.io/browse/JENKINS-65281
>>
>> There is something else that needs to be included? Please just let me 
>> know.  I will create the PR for the backports.
>>
>> PD: Something else, I saw that we are not publishing release candidate 
>> wars into http://mirrors.jenkins-ci.org/war-stable-rc/, Does the process 
>> change and we are not publishing anymore?
>>
>> Thanks
>>
>>
>> Beatriz Muñoz Manso
>> Sr Software Engineer 
>> CloudBees, Inc.
>>
>>
>>

-- 
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/703f7ea2-455d-4333-83d8-5a7fdf042d56n%40googlegroups.com.

Re: Jenkins 2.289.3 LTS RC testing started

[timja...@gmail.com]

This 
works: 
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/jenkins-war/2.289.3-SNAPSHOT/jenkins-war-2.289.3-20210716.091232-1.war


On Monday, 19 July 2021 at 09:10:47 UTC+1 imon...@cloudbees.com wrote:

> Go for it Mark! :-)
>
> On Fri, Jul 16, 2021 at 6:27 PM Mark Waite  wrote:
>
>> Do you mind if I create a GitHub release entry for it so that we could 
>> upload the war file to GitHub?  That may simplify the download process for 
>> other testers and provides a record of the version used to build the 
>> release candidate?
>>
>> It would look something like 
>> https://github.com/jenkinsci/jenkins/releases/tag/jenkins-2.289.2-rc
>>
>> On Fri, Jul 16, 2021 at 10:03 AM Ildefonso Montero  
>> wrote:
>>
>>> Yes, Artifactory UI was updated recently and navigation seems not 
>>> working as expected. 
>>>
>>> Go through 
>>> https://repo.jenkins-ci.org/ui/native/snapshots/org/jenkins-ci/main/jenkins-war/2.289.3-SNAPSHOT
>>>  
>>> to get the war file
>>>
>>> Thanks for the heads up Mark!
>>>
>>> On Fri, Jul 16, 2021 at 5:58 PM Baptiste Mathus  wrote:
>>>
 I see the same as you from the phone Mark.

 Le ven. 16 juil. 2021 à 17:50, Mark Waite  a 
 écrit :

> I wasn't able to download the release candidate from 
> https://repo.jenkins-ci.org/native/snapshots/org/jenkins-ci/main/jenkins-war/2.289.3-SNAPSHOT/jenkins-war-2.289.3-20210716.091232-1.war
>  
> with wget or curl or my web browser.  They all replied with a JSON file 
> that contained the text "404".
>
> I was able to download if I open a web browser to 
> https://repo.jenkins-ci.org/ui/native/snapshots/org/jenkins-ci/main/jenkins-war/2.289.3-SNAPSHOT
>  
> and then click the jenkins-war-2.289.3 hyperlink.
>
> I don't understand the difference between those two download methods.  
> My Windows based web browser is somehow smarter than my Linux command 
> line 
> utilities.
>
> Have others seen the same issue?
>
> On Fri, Jul 16, 2021 at 3:20 AM Ildefonso Montero <
> imon...@cloudbees.com> wrote:
>
>> Hello everyone,
>>
>> Latest LTS RC was made public and it is ready to be tested. The final 
>> release is scheduled for 2021-07-28.
>>
>> Please, report your findings in this thread.
>>
>> Download the release from 
>> https://repo.jenkins-ci.org/native/snapshots/org/jenkins-ci/main/jenkins-war/2.289.3-SNAPSHOT/jenkins-war-2.289.3-20210716.091232-1.war
>>
>> Thanks!
>>
>> -- 
>>
>> Ildefonso Montero Pérez
>> Senior Software Engineer
>>
>> CloudBees, Inc
>>
>>
>>
>> E: imon...@cloudbees.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-de...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BUGhi_FjZ-ahDo79M11QxXEo-PgPc-tKxX04hUeKLx5oF4ZSg%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-de...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEyq0vOSX7pgQFirqOfa_9STdbuLj38ZM2ZBcQ-LAPJZw%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-de...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6DJfXHkJnOgcSEpuBbg%2BxyB8AMBUF1Er79hYrOK0afKg%40mail.gmail.com
  
 
 .

>>>
>>>
>>> -- 
>>>
>>> Ildefonso Montero Pérez
>>> Senior Software Engineer
>>>
>>> CloudBees, Inc
>>>
>>>
>>>
>>> E: imon...@cloudbees.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-de...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/j

Re: Forked repositories in GitHub

[timja...@gmail.com]

Seem's like GitHub won't break the fork relationship anymore without both 
sides agreeing to it?
They've done it in the past for me but wouldn't do it yesterday.

GH> In the two scenarios you have:

DB>> It is possible to invert the fork relationship. This requires approval 
from both repo owners (i.e. jenkinsci and whoever we forked from).

GH> This is correct.

DB> It is possible to cut the fork relationship. This requires approval 
from the forked repo owner (i.e. jenkinsci).

GH>>This would only be the case of the fork network is private. However, 
the fork network in question is public, so we'll need the repository owner 
to contact us and approve this request.

GH>>I hope this helps clarify.


Thanks

Tim
On Thursday, 20 August 2020 at 08:39:22 UTC+1 bma...@gmail.com wrote:

> +1. All for it. 
>
> Le mar. 18 août 2020 à 13:38, Daniel Beck  a écrit :
>
>> Hi everyone,
>>
>> I'd like to propose a cleanup of 'fork' relationships of the repositories 
>> in the jenkinsci GitHub organization.
>>
>> Background:
>> For many years, the plugin hosting process has forked existing 
>> repositories. The expectation was always that the new repo in jenkinsci was 
>> the canonical 'main' repository, but that wasn't enforced. For the past 
>> year or two, we've even asked maintainers to delete their repository after 
>> forking unless there were useful PRs and issues in there already, so that 
>> the jenkinsci repo became the 'main' repo (with occasional mishaps if 
>> someone else had forked before us).
>>
>> Some people enjoy the "branding" effect that having the source repository 
>> creates. But this comes with downsides: Sometimes GitHub code search 
>> doesn't work, depending on the popularity of the repository. Links to 
>> create pull requests sometimes don't work quite right, and INFRA-2697 notes 
>> that the GitHub CLI cannot really handle networks where a fork is the 
>> "main" repo, probably for the same reason. Having a different repo than 
>> what we consider canonical as the "root" repository confuses users trying 
>> to file pull requests or issues on GitHub. It'll get worse once GitHub adds 
>> repo-level discussions[1]. Basically, the more stuff is attached to a 
>> repository that isn't trivially cloned/mirrored to forks, the worse it gets.
>>
>> In terms of security, GitHub for quite some time did not support security 
>> warnings for forks. LGTM.com / GitHub Security Labs still does not 
>> recognize forked repositories. Earlier this year a security researcher 
>> recently used its CodeQL functionality to identify and submit fixes to 
>> pom.xml files referencing plain HTTP Maven repositories, but couldn't do 
>> that for forked repos. In many cases, the source repositories are much less 
>> active than the repo in jenkinsci, or the maintainers have moved on 
>> entirely, making this feature unavailable to (other) current maintainers, 
>> or the Jenkins security team.
>>
>> The way we create forks is simply not a well-supported use case.
>>
>> My proposal therefore is to "unfork" plugin and similar repositories in 
>> the jenkinsci organization. Only repositories that clearly are forks (e.g. 
>> some libraries not maintained by us) would remain forks.
>>
>> After checking with GitHub support, the following options exist:
>>
>> 1. It is possible to invert the fork relationship. This requires approval 
>> from both repo owners (i.e. jenkinsci and whoever we forked from).
>> 2. It is possible to cut the fork relationship. This requires approval 
>> from the forked repo owner (i.e. jenkinsci).
>>
>> And while it is technically possible to re-attach repos to a network / 
>> merge networks, GH support would rather not do that.
>>
>> Therefore I propose we implement the following steps:
>>
>> 1. We try to contact, wherever possible, whoever we forked from, and ask 
>> them to contact GitHub support. I'll grant blanket permission on behalf of 
>> jenkinsci and will tell everyone the support ticket number to reference so 
>> this goes as smoothly as possible.
>> 2. We wait a while while folks ask GH support for an inversion of the 
>> fork relationship.
>> 3. We ask GitHub support to cut the fork relationship of everything 
>> that's left over.
>>
>> Additionally, we should change the hosting process to work with repo 
>> transfers, or creation of repos without the fork relationship. That can be 
>> done at any time though; as even now we don't really want that fork 
>> relationship we create to exist.
>>
>> To understand the scope of this, I've written a script that periodically 
>> updates a list of forked repositories in jenkinsci, you can see the result 
>> at 
>> https://www.jenkins.io/doc/developer/publishing/source-code-hosting/forks/
>>
>> One potential problem are plugins that are actively maintained outside 
>> the jenkinsci organization and only have an outdated fork in jenkinsci that 
>> isn't being used. I think it makes sense to ask maintainers to move their 
>> activity into jenkinsci (inc

Re: Request to adopt Job DSL Plugin

[timja...@gmail.com]

Thanks for stepping up, I've merged the adoption request

Welcome aboard.

On Tuesday, 12 October 2021 at 15:50:53 UTC+1 jn...@cloudbees.com wrote:

> Hi Jamie,
>
> incase you are not aware, there are a few acceptance tests for the Job DSL 
> plugin that have been failing for a while.  If you would like to pick them 
> up to ensure the plugin stays healthy that would be great!
>
>
> https://ci.jenkins.io/job/Core/job/acceptance-test-harness/job/master/lastCompletedBuild/testReport/plugins/JobDslPluginTest/
> https://github.com/jenkinsci/acceptance-test-harness#readme
>
> /James
> On Monday, October 11, 2021 at 5:05:09 PM UTC+1 timja...@gmail.com wrote:
>
>> Adding Daniel to cc
>>
>> On Mon, 11 Oct 2021 at 16:45, Jamie Tanna  wrote:
>>
>>> Hi Gavin,
>>>
>>> Thanks for the reply - it's helpuful to understand the process fully!
>>>
>>> Yes, that's a good point, this wouldn't be a takeover, more that I'm 
>>> volunteering to be an additional developer.
>>>
>>> I've raised 
>>> https://github.com/jenkins-infra/repository-permissions-updater/pull/2126 
>>> for the permissions changes.
>>>
>>> (I see it's failing, and will retrigger the build in a week or so)
>>>
>>> On Sunday, October 10, 2021 at 5:33:39 PM UTC+1 ga...@gavinmogan.com 
>>> wrote:
>>>
>>>> Thanks for stepping up. Since the plugin is not marked for adoption 
>>>> you'll want to follow either the takeover or  I guess it's additional user 
>>>> procedure?
>>>>
>>>> We need a PR to 
>>>> https://github.com/jenkins-infra/repository-permissions-updater with 
>>>> any of the existing maintainers tagged. And this mailing list post cc'd to 
>>>> any email addresses you can find for existing maintainers.
>>>>
>>>> If nobody responds in two weeks you'll be able to take over.
>>>>
>>>> On a personal note, it's a super busy and popular plugin, so thanks for 
>>>> stepping up, but also all the issues will be a bit daunting.
>>>>
>>>> Gavin
>>>>
>>>> On Sun., Oct. 10, 2021, 4:00 a.m. Jamie Tanna,  
>>>> wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to volunteer myself to become a maintainer of the Jenkins 
>>>>> Job DSL plugin.
>>>>>
>>>>>
>>>>>- 
>>>>>
>>>>>Link to a plugin you want to adopt: 
>>>>>https://plugins.jenkins.io/job-dsl/
>>>>>- 
>>>>>
>>>>>Link(s) to pull requests you want to deliver, if applicable: 
>>>>>https://github.com/jenkinsci/job-dsl-plugin/pull/1232, 
>>>>>https://github.com/jenkinsci/job-dsl-plugin/pull/1238
>>>>>- 
>>>>>
>>>>>Your GitHub username/id - jamietanna
>>>>>- 
>>>>>
>>>>>Your Jenkins infrastructure account id. - jamietanna
>>>>>
>>>>> I have contributed a PR above (1232) which the community sorely need 
>>>>> support for, and am happy to get involved in the project to support a bit 
>>>>> more.
>>>>>
>>>>> I've also blogged a fair bit about Job DSL 
>>>>> <https://www.jvt.me/tags/job-dsl/>.
>>>>>
>>>>> I'd be happy to help get some of the higher priority PRs over the 
>>>>> line, and supporting others in the future.
>>>>>
>>>>> Thanks,
>>>>> Jamie
>>>>>
>>>>> -- 
>>>>> 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/3ee6c613-17b4-425e-9972-364f03771a35n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/3ee6c613-17b4-425e-9972-364f03771a35n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> -- 
>>> 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/2bf4ad64-ce87-41a5-add5-29e76dcb7140n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/2bf4ad64-ce87-41a5-add5-29e76dcb7140n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
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/78359769-68f4-4b73-a1ab-1086850a2e3en%40googlegroups.com.

Re: Dropping support for IE 11

[timja...@gmail.com]

PR raised,
see https://github.com/jenkins-infra/jenkins.io/pull/4827

and preview:
https://deploy-preview-4827--jenkins-io-site-pr.netlify.app/doc/administration/requirements/web-browsers/

On Friday, 21 January 2022 at 09:15:02 UTC jn...@cloudbees.com wrote:

> The only issue I would have in early removal is if a plugin dropped 
> compatability whilst it was still supported for a supported LTS version, 
> that said we have no stake in what a plugin does or does not do.  So I 
> guess I have no issue with dropping IE today and promoting Edge to T1.
>
> it could make any backports harder to versions that still support IE 
> (should they be needed for any security or regression, but that would be 
> the same for any change) so I doubt it has any impact on this descision..
>
> /James
>
> On Monday, January 17, 2022 at 7:37:32 AM UTC timja...@gmail.com wrote:
>
>> Fine to promote edge,
>>
>> I don’t think IE should stay on any level.
>>
>> It will get broken very quickly if we remove the compat we have added for 
>> it or stop enforcing PRs be compatible with it.
>>
>> Realistically that’s unlikely to hit the LTS version till June so will 
>> match up with EOL anyway, but I don’t think we need to keep it there till 
>> then?
>>
>> On Sun, 16 Jan 2022 at 23:13, James Nord  wrote:
>>
>>> Given Edge is Chromium based would it make sense to promote that to tier 
>>> 1
>>> at the same time to leave a platform default browser with T1 
>>> comparability / support?
>>>
>>> It's much less likely to be broken than Safari based on comparability 
>>> charts.
>>>
>>> As such I would have no issue dropping IE support should edge be 
>>> promoted.
>>>
>>> /James
>>> On Sunday, 16 January 2022 at 21:47:32 UTC ullrich...@gmail.com wrote:
>>>
>>>> Yes, it makes sense to drop support (or use Tier 3). I’m also using JS 
>>>> features that do not work in IE. 
>>>>
>>>>
>>>> Am 16.01.2022 um 22:41 schrieb Oleg Nenashev :
>>>>
>>>> I would suggest explicitly moving IE 11 to "Tier 3" for now until the 
>>>> official end of life, with explicit statement it is deprecated. It would 
>>>> have the same effect as removing it, because Tier 3 states that there're 
>>>> " No guarantees. We will accept patches, but only if they are low risk. 
>>>> *This 
>>>> is the default unless a browser/version is listed below*". Having 
>>>> explicit support tier would be useful for those users who look into 
>>>> migration.
>>>>
>>>> I also suggest promoting Microsoft Edge to Tier 1 in the same patch 
>>>>
>>>> IIUC with removal of IE 11 support we will be also able to cleanup all 
>>>> CSS style default hacks, right? If so, maybe dropping IE11 right away is 
>>>> justified
>>>>  
>>>>
>>>> On Sunday, January 16, 2022 at 10:39:27 PM UTC+1 ga...@gavinmogan.com 
>>>> wrote:
>>>>
>>>>> Absolutely on board with this. The fact that some companies decide to 
>>>>> keep this old legacy broken browser around shouldn't hold anyone else 
>>>>> back. 
>>>>>
>>>>> > Bootstrap 5 doesn't support it (I assume warnings-ng is already 
>>>>> incompatible with IE 11) 
>>>>>
>>>>> Css not working is very different than javascript not working 
>>>>>
>>>>> > Drop IE support completely from the support table on 
>>>>> https://www.jenkins.io/doc/administration/requirements/web-browsers/ 
>>>>>
>>>>> I know I had to use my open source saucelabs account when I was 
>>>>> helping out with blueocean, its so hard to test these days. 
>>>>>
>>>>> Gavin 
>>>>>
>>>>> On Sun, Jan 16, 2022 at 12:13 PM Tim Jacomb  
>>>>> wrote: 
>>>>> > 
>>>>> > Hello 
>>>>> > 
>>>>> > I think it's time that we drop support for IE 11. 
>>>>> > 
>>>>> > There's some really good background information for the why's and 
>>>>> what's in the angular RFC: 
>>>>> > https://github.com/angular/angular/issues/41840 
>>>>> > 
>>>>> > Some useful reasons why: 
>>>>> > - IE 11 was released in 2013 and has only received bug and security 
>>

Re: Backporting for LTS 2.319.3 started

[timja...@gmail.com]

There's been a request for https://issues.jenkins.io/browse/JENKINS-67635 
to be backported

Just merged in https://github.com/jenkinsci/jenkins/pull/6193

Any thoughts?

On Monday, 17 January 2022 at 15:24:27 UTC imon...@cloudbees.com wrote:

> Backporting has started and the RC is scheduled for next Wednesday 
> 2022-01-26
>
> Candidates: https://issues.jenkins-ci.org/issues/?filter=12146
> Fixed: 
> https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.319.3-fixed
> Rejected: 
> https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.319.3-rejected
>
>
>
> -- 
>
> Ildefonso Montero Pérez
> Senior Software Engineer
>
> CloudBees, Inc
>
>
>
> E: imon...@cloudbees.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/079fc51e-91d8-4292-ab16-682a8b5e6bf3n%40googlegroups.com.

Re: Periodic rebuilding of core PRs on ci.jenkins.io through branch indexing

[timja...@gmail.com]

I've switched it to pr-head for a trial run. (Core and Tools folders only)

Jesse has been advocating it for over 4 years now.
Let's give it a go.

Easy to revert back if we find pr-merge was better

On Wednesday, 6 July 2022 at 18:44:38 UTC+1 Jesse Glick wrote:

> On Sun, Jul 3, 2022 at 5:13 AM Alexander Brandes  
> wrote:
>
>> Maybe I'm missing something, but I can see downsides only for this 
>> [PR-merge] strategy
>>
>
> The upside is that the commit status will reflect whether the PR would 
> allow trunk to continue passing if it were merged *now*. With the simpler 
> PR-head strategy, a PR might pass in its original form, and have no textual 
> merge conflicts (edits within ~3 lines) yet actually be broken relative to 
> the current trunk. Thus by merging it you might inadvertently break trunk, 
> which would be disruptive.
>
> In practice this is not a very common problem, and the downsides are very 
> real, so I recommend switching to PR-head: 
> https://github.com/jenkins-infra/helpdesk/issues/1355
>

-- 
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/64510df1-dc57-4185-ab1a-1a080d9f9c8fn%40googlegroups.com.

Re: Request for access to YouTube account

[timja...@gmail.com]

+1

On Wednesday, 26 October 2022 at 13:18:13 UTC+1 goun...@gmail.com wrote:

> Hi group,
>
> I sometimes run the Platform SIG meeting (like 
> https://www.youtube.com/watch?v=R2322YxIciQ) and would like to be able to 
> post the resulting video to YouTube when Mark is on PTO for example.
> Therefore I'm asking the authorization to be granted access to the Youtube 
> account/channel (to upload the recording to the channel).
>
> Best wishes,
>
> Bruno Verachten
>

-- 
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/77f08589-693b-46cd-96e4-cb665587b9a9n%40googlegroups.com.

Re: Requesting Admin access to the jenkinsci organization

[timja...@gmail.com]

I've granted Alex admin access 

On Monday, 5 June 2023 at 15:25:46 UTC+1 wfoll...@cloudbees.com wrote:

> +1
>
> Thanks Alex for your continued effort in the project :-)
>
> On Monday, June 5, 2023 at 1:15:42 PM UTC+2 timja...@gmail.com wrote:
>
>> +1 
>>
>> On Mon, 5 Jun 2023 at 10:05, Ullrich Hafner  wrote:
>>
>>> +1 from me
>>>
>>> Am 05.06.2023 um 09:50 schrieb Alexander Brandes :
>>>
>>> Hey everyone,
>>>
>>> I would like to increase my involvement within the Jenkins project 
>>> beyond a maintainer scope, and would like to request admin access to the 
>>> jenkinsci GitHub organization.
>>>
>>> Besides my seat on the Jenkins governance board, I am one of the core 
>>> maintainers within the jenkinsci GitHub organization.
>>> The recent sponsorship of the project coming from GitHub and the 
>>> adoption of enterprise features, like autolink references you can find in 
>>> core repositories already, are one of the examples of my work, which 
>>> wouldn't be possible without me bothering Tim Jacomb constantly to click 
>>> the right buttons for me.
>>> I have admin access to various core component and plugin repositories 
>>> within the jenkinsci organization, plus the jenkins-infra organization, 
>>> including jenkins.io or the plugin site. Having admin permissions in 
>>> the jenkinsci organization would allow me to help to facilitate 
>>> contributions of these kinds to the Jenkins project.
>>>
>>> My GitHub account is configured securely, and I have an ICLA signed.
>>>
>>> Would the project be fine with such a request?
>>> Thanks in advance,
>>> Alexander Brandes
>>>
>>> -- 
>>> 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/CAP9joaHYsQEvPKLQpxdWPW_OR92O98F8Xt1AWMyDsO-03tYiQg%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAP9joaHYsQEvPKLQpxdWPW_OR92O98F8Xt1AWMyDsO-03tYiQg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>>
>>> -- 
>>> 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/E1D85BB2-8BC6-4346-B134-5035E20B4B32%40gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/E1D85BB2-8BC6-4346-B134-5035E20B4B32%40gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
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/874653b3-82cb-4273-b0b0-01cd6fb72c33n%40googlegroups.com.

Re: Enable Renovate app on `scoring-load-balancer-plugin` and `additional-identities-plugin`

[timja...@gmail.com]

Approved

On Tuesday 12 March 2024 at 11:12:38 UTC michael...@visualon.de wrote:

> Hi,
>
> i like to use renovate on my two adopted repos.
> Can someone with organization admin permissions enable it for me?
>
> - https://github.com/jenkinsci/additional-identities-plugin
> - https://github.com/jenkinsci/scoring-load-balancer-plugin
>
> Regards
> Michael
>

-- 
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/76d3d127-ecaa-4b86-8df6-0ae7849c22fen%40googlegroups.com.

Re: Plugin with Java 17 minimum dependencies

[timja...@gmail.com]

Hi

as Jesse said in the PR, this change should be safe to do now so +1 from me.

On Tuesday 7 May 2024 at 14:25:55 UTC+1 lemeurher...@gmail.com wrote:

> Hello,
>
> I should have probably let existing maintainers opening a pull request for 
> that but here is a proposed change to bump the Java version used by the cd 
> GitHub Action:
>
>
> https://github.com/jenkins-infra/github-reusable-workflows/issues/30#issuecomment-2098397213
> https://github.com/jenkins-infra/github-reusable-workflows/pull/31
>
> WDYT?
>
> If accepted, we could plan a new release of 
> https://github.com/jenkins-infra/github-reusable-workflows
>
> Le mardi 7 mai 2024 à 06:53:15 UTC+2, jone...@gmail.com a écrit :
>
>> Hi,
>>
>> Just did it : 
>> https://github.com/jenkins-infra/github-reusable-workflows/issues/30
>>
>> Regards,
>>
>> On Monday, May 6, 2024 at 6:12:47 PM UTC+2 m...@basilcrow.com wrote:
>>
>>> On Saturday, April 27, 2024 at 11:56:06 AM UTC-7 ull...@gmail.com wrote:
>>>
>>> At least it makes sense to rise an issue for the CD toolchain so this 
>>> problem will not be forgotten when we switch to Java 17 in September.
>>>
>>>
>>> Have we filed an issue for the CD toolchain?
>>>
>>

-- 
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/34381ccd-de3d-4514-930c-27ac2d9fb1a3n%40googlegroups.com.

Re: Plugin with Java 17 minimum dependencies

[timja...@gmail.com]

v1 of the reusable workflows is now running on Java 17, thanks all

On Wednesday 8 May 2024 at 05:47:52 UTC+1 jone...@gmail.com wrote:

> +1
>
> On Tuesday, May 7, 2024 at 8:41:48 PM UTC+2 m...@basilcrow.com wrote:
>
>> Yes, I think the default should be changed to Java 17 and a new 
>> version released for the reasons already given. Why wasn't the 
>> adoption of such a release (along with updating the Java version value 
>> in the Jenkins security scan workflow, pending 
>> https://github.com/jenkins-infra/jenkins-security-scan/issues/29) 
>> performed when we swept through the ecosystem adding Java 17/21 builds 
>> to Jenkinsfiles? 
>>
>

-- 
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/ea0a41e0-5324-459c-a1a1-ccd628218bafn%40googlegroups.com.