Re: Java 11 as minimum? (Jetty 9.4.x EOL)

[Matt Sicker]

I’ll note the illegal reflection is only an issue starting with Java 16, and 
that can be “fixed” with some add-opens CLI options to Java. See for example 
how the ErrorProne compiler plugin requires several of those flags in a build 
with recent Java versions (and I’d expect similar for Lombok and other projects 
that access JDK internals).

—
Matt Sicker

> On Jan 4, 2022, at 09:34, Basil Crow  wrote:
> 
> On Mon, Jan 3, 2022 at 12:48 PM Mark Waite  wrote:
>> 
>> I think there are changes that are as yet undiscovered on the removal of 
>> Java 8 support.  I believe that finding and fixing those surprises will need 
>> more time.
> 
> We are already aware of issues with WebSockets (fixed), JAXB (fixed in
> all but the least used plugins), Linux agent installers (nobody seems
> to care), and illegal reflective access warnings (not blocking). I
> doubt we will discover many new issues with switching the _runtime_ to
> Java 11 in any but the least used plugins.
> 
> On the other hand, switching _builds_ and _tests_ to Java 11 does
> often require the usual plugin refresh process: updating the plugin
> parent POM and plugin BOM, dealing with Enforcer, updating the
> Jenkinsfile, adjusting annotations, tweaking mocks, suppressing
> SpotBugs false positives that only show up on Java 11, triaging
> miscellaneous test failures, etc. This seems to be the majority of the
> remaining work, but it does not affect end users.
> 
> I am not sure that additional time will incentivize the completion of
> the remaining work, whether it be production changes to long-tail
> plugins or build metadata updates. If a plugin is unmaintained or its
> maintainer has not yet refreshed it by June 2022, I doubt that this
> status will change by September 2022. If anything, delaying the
> release until September may (ironically) decrease the perceived need
> to take action on the part of plugin maintainers.
> 
> My point is not that risk does not exist, but that additional time is
> not likely to reduce risk. Therefore, I see no reason to wait until
> September.
> 
> -- 
> 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/CAFwNDjpespJqVCcHCqGUVK4QUQvv1UPd3Y%2BtM%2B2Ek5Hq39-rBA%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/870E34A5-9F72-4CAA-A00F-B03E7BA04CC6%40gmail.com.

Re: How to re-sync credentials for publishing plugin updates?

[Matt Sicker]

The CD approach sounds good. I’ll look into that, thanks.

—
Matt Sicker

> On Dec 13, 2021, at 15:13, 'Gavin Mogan' via Jenkins Developers 
>  wrote:
> 
> 
> You shouldn't need to sync anything. Unless you're talking about syncing 
> artifactory and maven.
> 
> I don't think you can currently log into artifactory to pull down your 
> credentials while the account services are down
> 
> You can enable cd like the other threads mention though
> 
>> On Mon., Dec. 13, 2021, 12:55 p.m. Matt Sicker,  wrote:
>> Hey all, I was wondering what I needed to do to re-sync my credentials for 
>> publishing plugins, especially after changing my password? I’d like to cut a 
>> release of a plugin affected by CVE-2021-44228 (log4j-core).
>> --
>> Matt Sicker
>> 
>> -- 
>> 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/37B7F059-E4C4-4697-8B5C-E85157943CE6%40gmail.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/CAG%3D_DutsFPDuOBHcEuM9h1S3CKkodkSo0ZpBWMgAK%3D8hv5AMqA%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/C5DE29C6-DFDB-4B41-9E53-17C4C0B2A702%40gmail.com.

How to re-sync credentials for publishing plugin updates?

[Matt Sicker]

Hey all, I was wondering what I needed to do to re-sync my credentials for 
publishing plugins, especially after changing my password? I’d like to cut a 
release of a plugin affected by CVE-2021-44228 (log4j-core).
--
Matt Sicker

-- 
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/37B7F059-E4C4-4697-8B5C-E85157943CE6%40gmail.com.

Re: Feedback on some analysis I'm doing

[Matt Sicker]

Note that some plugins (like audit-log) use log4j-api due to slf4j-api
not supporting non-String messages (e.g., audit log structured data
messages, syslog metadata, etc.). Promoting logging APIs to an API
plugin may require some care in implementation. Also, Jenkins' UI for
recording and viewing logs is currently tied to the java.util.logging
API, not SLF4J or Log4j2, so if logging is further consolidated, that
may also need to be updated.

On Mon, Dec 13, 2021 at 1:48 PM Basil Crow  wrote:
>
> On Mon, Dec 13, 2021 at 11:22 AM 'rsomas...@netflix.com' via Jenkins
> Developers  wrote:
> >
> > While sometimes […] it is about security […]
> > Other times, it's mostly about reducing redundant libraries […]
>
> Indeed.
>
> > Other common libraries are
> > com.google.code.gson  gson  2.8.5   45
>
> Ought to be made into an API plugin I think.
>
> > org.apache.commonscommons-lang3 3.4 33
>
> Ditto.
>
> On Mon, Dec 13, 2021 at 10:35 AM 'rsomas...@netflix.com' via Jenkins
> Developers  wrote:
> >
> > The maven-hpi-plugin could do some linting of the plugins
>
> Would certainly be nice to issue warnings to plugin developers
> directing them to use API plugins when possible. Another common
> mistake I have seen is mistakenly bundling test libraries in
> production, which in some cases results in memory leaks that can take
> down a controller (cf. JENKINS-65650 and JENKINS-65771).
>
> > only get it as a transitive from the provided dependency on jenkins-core
>
> Might be interesting to look into avoiding the bundling of
> dependencies that are provided by Jenkins core. These are unused at
> runtime: 
> https://github.com/jenkinsci/jenkins/blob/165d559469c7a58af581931bd1b89e5b9ed4a9af/core/src/main/java/hudson/ClassicPluginStrategy.java#L247
>
> --
> 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/CAFwNDjoGO%3DrHhqttnUJ_--eLq_BE2qq%3DXNnvi8FK_fkJfXgFEg%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/CACmp6krmvcr6K%3DM5jqt3LYbtZJv8AyuSWohUfn25%2BEXnyOmXSg%40mail.gmail.com.

Re: Proposal: Changing the Contributor License Agreement Process

[Matt Sicker]

I think simplifying the ICLA process is a fantastic idea. It’s something I’d 
like to implement at Apache at some point, too. Reducing contributor friction 
is usually a great idea.

Matt Sicker

> On Nov 8, 2021, at 05:20, Mark Waite  wrote:
> 
> 
> +1 from me.  Thanks very much for doing it.
> 
>> On Mon, Nov 8, 2021 at 2:38 AM Oleg Nenashev wrote:
>> Hi all,
>> 
>> I would like to proceed with  https://github.com/jenkinsci/infra-cla and to 
>> build a new process around this repository for now (TL;DR: ditching PDFs for 
>> new CLAs and gradually migrating old ones). Any objections?
>> 
>> Best rgeards,
>> 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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtE_xBY3S__MB%2BkRdXML2-WRbDDz-3LkyUh11OApSCfm7w%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/CE462CA9-2E76-4FBF-BCA5-AAFE36551366%40gmail.com.

Re: 1Password tram for Jenkins passwords?

[Matt Sicker]

Definitely a good idea. Credentials sharing should always use a
dedicated password management or vault style service. 1password is
fairly easy to use, too.

On Tue, Nov 2, 2021 at 4:42 AM Oleg Nenashev  wrote:
>
> Hi all,
>
> 1Password launched a free offering open source teams: 
> https://github.com/1Password/1password-teams-open-source. From what I see we 
> are compliant with sponsorship conditions.
>
> We have quite a lot of passwords we use, especially in Advocacy & Outreach 
> (Zoom, Twitter accounts, etc.). It would be generally useful if we could 
> transfer these passwords to a shared storage so that we could share them with 
> people, track access and credential leaks.
>
> The same might be useful for infrastructure accounts if it don't have SSO, 
> and for various test accounts we have.
>
> WDYT? I thin
>
> 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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCk0iSK2yHE6GujCj361Cexwo3QhXcO6y7f6o2Okp08ww%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/CACmp6koTJrcz633KvgBMVFZPLDWjrxxzfTQv3Or4QbrVFhg_pw%40mail.gmail.com.

Re: Emeritus concept for Jenkins developers (was: Re: Proposal: Adding Basil Crow to the Jenkins Core maintainers team)

[Matt Sicker]

At Apache, emeritus status is typically requested by the individual.
That might be hard to emulate here if some otherwise emeritus members
of Jenkins aren't here to request emeritus. Some forms of active
versus inactive members could be useful, though, for code review
purposes and other bookkeeping.

On Thu, Sep 23, 2021 at 5:08 AM Tim Jacomb  wrote:
>
> +1 we have this in jenkins-infra
>
> On Thu, 23 Sep 2021 at 10:28, Baptiste Mathus  wrote:
>>
>> Hi all,
>>
>> Following up on Jesse's comment, and as I was reflecting on this a few days 
>> ago: I think we should introduce an Emeritus concept/status for Jenkins core 
>> team's inactive members.
>>
>> That would allow "cleaning up" the list for various reasons, while still 
>> recognizing the contributions of such individuals.
>>
>> I think, akin to Apache does in many projects, we should also have a 
>> straightforward way for such members to be reinstated inthe core list when 
>> they would request it.
>>
>> WDYT?
>>
>> Once we agree on this principle, we will also need to dicuss the "inactive 
>> member" definition, but that's a secondary concern for now IMO.
>>
>> Baptiste
>>
>> Le mer. 22 sept. 2021 à 14:10, wfoll...@cloudbees.com 
>>  a écrit :
>>>
>>> +1 as well, really involved in the community so it's just natural :-)
>>>
>>> On Wednesday, September 22, 2021 at 2:05:32 PM UTC+2 Jesse Glick wrote:

 If he is interested, absolutely +1!

 By the way there are a number of people in 
 https://github.com/orgs/jenkinsci/teams/core/members who are no longer 
 active in the Jenkins community and who should likely be removed.
>>>
>>> --
>>> 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/2735a776-6bdf-485c-bdb0-96d45175ab67n%40googlegroups.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/CANWgJS5RcWPCSPghkpyBL3TH8iwv96ogjSbunVBbAdQ0rsTh6A%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-3Bie4XJNJ_WNDmH%3DJsuid4g5w9X%3D%2B8%3DTn3odWs0gZoZLHhQ%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/CACmp6kpV8vE-8C%3D7mAE3DgcAA3O84Fgyqg0CpXUPCq5-CrZxpw%40mail.gmail.com.

Re: Docker LTS image: issue with locale, should we rebuild?

[Matt Sicker]

Just like the Helm chart version doesn’t match exactly with the Jenkins 
version. A rebuilt image should use a new version, but it would help to use a 
naming scheme that doesn’t conflict with real Jenkins release versions.

Matt Sicker

> On Sep 2, 2021, at 08:59, Raul Arabaolaza  wrote:
> 
> I do fully agree with James here, if there is a bug on a concrete image 
> rebuild it, put some classifier on the version so people can understand what 
> is happening and no tags are modified. I do not see the need to rebuild 
> everything but the docker images to generate a new release that is gonna be 
> exactly the same than the previous one but with a different version number  
> 
>> On Monday, August 30, 2021 at 10:34:35 AM UTC+2 damien@gmail.com wrote:
>> 
>> Hello dear developers and maintainers,
>> 
>> We (the Jenkins Infra team) were recently bitten by a change in the latest 
>> Docker image for Jenkins controller, in its LTS 2.303.1 (released last week).
>> 
>> The issue is related to a change of locale from "C.UTF-8" to "POSIX" when 
>> using Debian image (as an upstream change from Debian bullseye).
>> 
>> A fix has already been made by a user in 
>> https://github.com/jenkinsci/docker/pull/1194 and is already merge in GitHub.
>> 
>> We (the Jenkins Infra team) would like to rebuild the Docker image for the 
>> LTS 2.303.1 to avoid our users to be annoyed by this issue.
>> - It should not imply any tagging version change (as the Docker image tags 
>> are only about the Core version of Jenkins used, not about the other 
>> dependencies on the image)
>> - It should only impact the Debian images (amd64 and arm64)
>> - It should not impact the weekly (next weekly will have the fix of course)
>> - It should make the image being advertised as updated a few days after the 
>> official LTS release
>> 
>> - Is there any issue or counter voice to this change?
>> - Is there any question or element unclear?
>> 
>> For the Jenkins infra team
>> 
>> Damien DUPORTAL
>> 
>> 
> 
> -- 
> 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/c43a5a95-4666-4601-9944-28614abcbe32n%40googlegroups.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/54D5C969-1320-4C4B-BBA6-4A768601729D%40gmail.com.

Re: LTS backporting policy

[Matt Sicker]

Are there specific libraries we can list for safe upgrades? Like XStream, 
Jackson, Commons, etc, for common upgrades. I wouldn’t be super comfortable 
with a blanket policy, but for all our more stable ones, I think it’s a good 
idea.

Matt Sicker

> On Aug 31, 2021, at 09:01, wfoll...@cloudbees.com  
> wrote:
> 
> Totally agree. Especially when the update is not a major bump of 3 versions. 
> Most of the time it's just a minor/bug version bump.
> That will greatly help on the security scanners area, where the "fear" 
> dominates the market :-)
> 
> Thanks James for the suggestion, great idea.
> 
> Wadeck
> 
>> On Tuesday, August 31, 2021 at 3:58:38 PM UTC+2 jn...@cloudbees.com wrote:
>> Hi all,
>> 
>> I would like to propose that we add to the list of eligible criteria for 
>> backporting the following
>> 
>> * is a dependency update with a known security issue
>> 
>> The reason for this if we have a dependency with a security issue that is 
>> exploitable from Jenkins we already do include that as a LTS issue via the 
>> current SECURITY process, however if the issue is not exploitable then we do 
>> not. (for example the recent XStream issues have not impacts Jenkins as we 
>> already use an allow list).
>> 
>> However as supply chain issues are becoming more prominent to our users, 
>> they are scanning software with automated tools that look at the 
>> dependencies, and these scanners do not understand how a library is used or  
>> configured, and has the potential to:
>> 
>> * make the software look insecure (thus be a barrier to adoption) 
>> or 
>> * cause extra nose asking about CVE-2021-123456
>> 
>> 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/6d65b90e-1e31-475c-b3f6-9920bb4ee33en%40googlegroups.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/4D6CAB91-D14F-4D5E-BF52-8E121013BADE%40gmail.com.

Re: Using JDK 11 instead of JDK 8 in default docker images

[Matt Sicker]

I mean there's a very real chance that regardless of how long Jenkins
attempts to keep Java 8 compatibility, eventually some dependency it
or a key plugin uses will stop supporting Java 8 and subsequently
publish CVEs that are only fixed in the Java 11 version. I don't
expect that to happen very soon, but it's definitely something to
consider in the longer term. The Java 17 release, being an LTS one,
will encourage some communities to move their base level of Java
support from Java 8 to 11 (which has already been slowly happening
with some projects).

On Wed, Aug 11, 2021 at 11:32 AM Bill Honaker  wrote:
>
> Matt,
>
>
>
> Oracle releases Java to the larger OS platforms (Windows, Linux, MacOS, IOS, 
> Android) directly.  However for other platforms (speaking specifically for 
> NonStop), the vendor has to do the deep port themselves and go through their 
> QA process, etc.  They do this with the support of Oracle (under paid license 
> and support), but it’s never going to be fast.  Java 11 has only been 
> released on NonStop for a few years now (not 10).  And there are actually 2  
> different underlying instruction sets.  The currently-sold versions NonStop 
> (‘X’ and ‘V’) run on Xeon processors or in VMs, and Java 11 exists for those. 
>  However, ‘E’ is an Itanium-based platform that is no longer sold but is 
> still supported for Enterprise customers.  It still has 3 years of support 
> remaining.
>
>
>
> I wouldn’t expect Java 17 to be available for NonStop for another 5-10 years.
>
>
>
> Building Java apps with Java 11 that run on an Java 8 RTE is not difficult at 
> all.  Where you may run into issues is with 3rd party packages.  But in the 
> Open Source world it’s at least theoretical that you have the source and can 
> rebuild the class files with the ability to run on Java 8, if the 
> functionality of the package you need is critical.
>
>
>
> Many of the Enterprise customers using NonStop, while not averse to change 
> (otherwise they wouldn’t be in the devops realm), but they are very skeptical 
> about changing things.  Their business critical apps run for years without an 
> outage.  (They use replication  and managed failover to avoid planned 
> outages, for example).  How to reach them and ask?  Those of us that work 
> with the platform do so with various publications and events.
>
>
>
> But the developers that use tools like git and Jenkins actually WILL be the 
> ones that are impacted if Jenkins won’t run (correctly) because the JRE is at 
> Java 8.
>
>
>
> I’ve heard of other platforms where the story is similar but am not an expert 
> on them.
>
>
>
>
>
> From: jenkinsci-dev@googlegroups.com  On 
> Behalf Of Matt Sicker
> Sent: Wednesday, August 11, 2021 10:03 AM
> To: jenkinsci-dev@googlegroups.com
> Subject: Re: Using JDK 11 instead of JDK 8 in default docker images
>
>
>
> Plus Java 17 comes out really soon. I can imagine that will inspire more 
> projects to set Java 11 as a baseline. Definitely start planning since most 
> people will probably be affected by some other dependencies well before they 
> hit Jenkins.
>
> Matt Sicker
>
>
>
> On Aug 11, 2021, at 09:18, jn...@cloudbees.com  wrote:
>
> Hi Bill (et al) for those that are running nonstop or the like and have an 
> update / test cycle in the order of 6 months :
>
>
> I would recommend that your customers probably want to start the planning / 
> validation to update to Java11 now even if this LTS version still runs on 
> Java8.  Java11 is going to happen at some point and I am not sure the project 
> will be able to give you all the advance notice you need.
>
>
>
> Jenkins has supported Java11 for a while now, and if there are any specifics 
> from you that cause it not to run we would like to be aware as early as 
> possible (it won;t help you if we find out after the switch has been made and 
> 7 days before a go live)
>
> >  Most of your customers don't spend time reviewing this group.  And many 
> > Enterprise decisionmakers don't participate in Twitter, which leaves the 
> > results of surveys in that platform somewhat questionable.
>
> On that note - where should we announce surveys / things like this - if users 
> are not in the user email / discored or the like how can we reach people to 
> inform them and have them participate?
>
> I also work for a company (CloudBees) that has Jenkins at its core for 
> Enterprise customers, so we have the statistics from these installations as 
> well - so this project is not blind of enterprises (and if a customer wants a 
> version of Jenkins that is supported for 9 months rather than the normal 3 we 
> can probably help you out, and there may be others)
>
>

Re: Using JDK 11 instead of JDK 8 in default docker images

[Matt Sicker]

Plus Java 17 comes out really soon. I can imagine that will inspire more 
projects to set Java 11 as a baseline. Definitely start planning since most 
people will probably be affected by some other dependencies well before they 
hit Jenkins.

Matt Sicker

> On Aug 11, 2021, at 09:18, jn...@cloudbees.com  wrote:
> 
> Hi Bill (et al) for those that are running nonstop or the like and have an 
> update / test cycle in the order of 6 months :
> 
> I would recommend that your customers probably want to start the planning / 
> validation to update to Java11 now even if this LTS version still runs on 
> Java8.  Java11 is going to happen at some point and I am not sure the project 
> will be able to give you all the advance notice you need.
> 
> Jenkins has supported Java11 for a while now, and if there are any specifics 
> from you that cause it not to run we would like to be aware as early as 
> possible (it won;t help you if we find out after the switch has been made and 
> 7 days before a go live)
> 
> >  Most of your customers don't spend time reviewing this group.  And many 
> > Enterprise decisionmakers don't participate in Twitter, which leaves the 
> > results of surveys in that platform somewhat questionable.
> 
> On that note - where should we announce surveys / things like this - if users 
> are not in the user email / discored or the like how can we reach people to 
> inform them and have them participate?
> 
> I also work for a company (CloudBees) that has Jenkins at its core for 
> Enterprise customers, so we have the statistics from these installations as 
> well - so this project is not blind of enterprises (and if a customer wants a 
> version of Jenkins that is supported for 9 months rather than the normal 3 we 
> can probably help you out, and there may be others) 
> 
> Regards
> 
> /James
>> On Wednesday, August 4, 2021 at 11:00:06 PM UTC+1 bhon...@xid.com wrote:
>> Mark,
>> 
>> Randall had pointed me to this thread.  I admit to only reading the last 
>> couple of dozen posts and, based only on that, share my concerns.  I should 
>> have spent more time reading the thread, but I was scheduled to do a code 
>> walkthrough with my customer and took the 'short' path, for which I 
>> apologize.
>> 
>> Your clarification does seem 100% the right thing to do, and I thank you for 
>> sharing it.  That's worth much  more than .02$US!
>>  
>> And my customers all never need know I ever had this concern, you had it  
>> covered. :-)
>> 
>> Bill
>>> On Wednesday, August 4, 2021 at 3:49:40 PM UTC-5 Mark Waite wrote:
>>> Thanks for sharing your insights.  Great to have participation in the 
>>> thread.  Comments are inline
>>> 
>>>> On Wednesday, August 4, 2021 at 2:39:05 PM UTC-6 bhon wrote:
>>>> Similar to Randall (the.n...), I have customers that use NonStop, but they 
>>>> also use various distros of Enterprise Linux.  Their corporate strategy 
>>>> for software development is to remain on Java 8 for the foreseeable 
>>>> future, primarily due to the JDK  11 licensing mentioned above.  They have 
>>>> a corporate support contract with Oracle to continue to get Java 8 
>>>> updates, so support is not an issue for them.  Shipping a version of 
>>>> Jenkins that won't do 'remoting' on those target platforms should require 
>>>> much longer than 5 months of advance notice, as those customers are on 
>>>> much longer strategic cycles.
>>>> 
>>> 
>>> I'm not sure where you're getting the idea that we would be shipping a 
>>> version of Jenkins that won't do 'remoting' on those target platforms.  The 
>>> proposal does not remove Java 8 support.  The proposal does not prevent 
>>> users from running agents or controllers or both with Java 8.  The proposal 
>>> does not change how 'remoting' operates.
>>> 
>>>  
>>>> Even though  the newer platforms and releases for NonStop  include both 
>>>> Java 8 and Java 11, customers on NonStop and Linux that are 
>>>> Enterprise-focused (and there are MANY) haven't installed Java 11 and have 
>>>> no plan to do so  this year or probably even next.  What was the 
>>>> penetration number above for Java 11, only 4%?  Expecting a large 
>>>> percentage of your customer base to make this move is short-sighted.
>>>> 
>>> 
>>> We're not expecting them to make a move.  We're changing the default in the 
>>> Jenkins Docker images so that users who choose to use the default Jenkins 
>>> Docker images will use Java 11 i

Re: Allowed licenses for libraries in Jenkins plugins?

[Matt Sicker]

I agree that security related dependencies should have an upstream security
policy. Not every popular project bothers to file CVEs, either, especially
solo projects that didn’t have any past CVEs. While GitHub’s vulnerability
reporting feature has helped improve this somewhat, it’s still hit or miss.

On Wed, Jul 21, 2021 at 05:15 'Daniel Beck' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

>
>
> > On 21. Jul 2021, at 04:39, Mark Waite  wrote:
> >
> > The maverick-synergy library is LGPL3 licensed.  Is it allowed to use an
> LGPL3 licensed library in a Jenkins plugin?
> >
>
> The governance document explicitly allows LGPL even for use in core.
>
> We don't care about plugins distributed by the project, as long as it's
> OSI approved.
>
> https://www.jenkins.io/project/governance/#license
>
> --
> 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/FE58146B-EDF8-4A85-888A-F2E5E4ACCD6F%40beckweb.net
> .
>

-- 
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/CACmp6krhzqUDakU5-Ha8%3DsTh8e4Xo%3D%2B-EZcKqR6YiOwKnCeGLA%40mail.gmail.com.

Re: ASM in core

[Matt Sicker]

I don't remember seeing formal docs about it, but I believe it was
changed for two reasons:

1. Dependency simplifications in general. That's been an ongoing
effort by multiple people, particularly in Jenkins Core.
2. ASM needs to be upgraded more often now that Java itself is
released more often. Even if you shade in ASM, you trade one problem
for another in that newer Java releases are unable to run Jenkins (I'd
give a pass for Java 16 since they changed some stuff related to
poking at internals).

I do think a JEP could be useful if it helped figure out a strategy
for packaging and updating ASM to avoid compatibility issues for both
ASM itself and Java.

On Thu, 10 Jun 2021 at 03:46, jn...@cloudbees.com  wrote:
>
> Hi all,
>
> I have just noticed a few PRs (some merged) to change ASM in core or 
> libraries that core depdns on (stapler).
>
> I think we need to revert these and have a bigger think about ASM.
>
> ASM historically (and I believe still true) evolved in a non compatible way.
>
> In the past I have seen that versions add support for new class opcodes, but 
> this requires the code to implement the new methods to handle them as a 
> no-op, or causes linkage failures depending on how you use ASM.
>
> We also have a complete mix of ASM versions required for Core.  (stapler / 
> BCT) can be aligned quite easily - but Guice also depends on ASM (our current 
> version of guice uses 5.0.3 (unshaded!)) and whilst newer versions of Guice 
> use 9, bumping to that may entail bumping Guava (which Guice also heavily 
> relies upon) and we are working towards that byut are not yet ready for it.
>
> I have not seen the ASM changes discussed before (sorry if I missed it).  
> Could we at least have a discussion here or via a JEP as I believe there are 
> several moving parts that need to align (and possible several things we 
> currently do that are also broken!).
>
> Thanks
>
> /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/8558ef90-cf4b-4edb-8c25-a33ab74c5f6bn%40googlegroups.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/CACmp6kr7qKzDLpViy3hbOiDE3tqa3AiN-YsS0rygwEq%2BUU5D5A%40mail.gmail.com.

Re: Handle all paths under an Action

[Matt Sicker]

This sounds like getDynamic stuff. Look at DirectoryBrowserSupport for
ideas.

On Sun, Jun 6, 2021 at 12:50 Tim Jacomb  wrote:

> Hello
>
> Is there a way to handle all paths under a pattern in an Action (or
> something else)?
>
> i.e. If I add an action 'GraphProxyAction'
>
> I would like to be able to route GraphProxy/v1.0/* to my GraphProxy class
> which will just check permissions, add a credential and proxy the calls to
> an external rest API.
>
> Alternatively how can I add nested actions to reflect the API I'm
> proxying? I tried returning a V1 action from my doIndex method in
> `GraphProxyAction`, but that just ended up with a white page.
>
> I've had a look around at some of the Stapler annotations but not really
> sure how to do this
>
> 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/CAH-3BicnOpMOLTe4uodrpqn0At-UT1CT054nuq5SvMSXZE9sBQ%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/CACmp6krt7ga2%2B5zJ%3D24076ykZA_icFCfRoVzg7wMdsHeLtCthA%40mail.gmail.com.

Re: Issues creating a ManagementLink on JDK 11

[Matt Sicker]

This looks like it needs the updates Basil has been working on:
https://github.com/stapler/stapler/pull/225

On Sat, 29 May 2021 at 07:42, Ivan Fernandez Calvo
 wrote:
>
> Hi,
>
> I am moving some configuration I have (that is working) to a new section in 
> the Manage Jenkins. I've adapted the code in the AWS Global configuration to 
> my needs, but it did not work completely, I can see the configuration options 
> but none of the checks URL works all launch the following exception when the 
> page is loaded. after a while I track the issue to the JDK 11, if I use JDK 8 
> everything works but with JDK 11 it fails. Do you have any idea how to 
> resolve it?
>
> 2021-05-29 11:57:27.759+ [id=28]WARNING 
> h.ExpressionFactory2$JexlExpression#evaluate: Caught exception evaluating: 
> h.calcCheckUrl(pattrs,  pattrs.checkUrl,descriptor,pattrs.field) in 
> /jenkins/elasticStack/. Reason: java.lang.IllegalArgumentException
> java.lang.IllegalArgumentException
> at org.kohsuke.asm5.ClassReader.(ClassReader.java:170)
> at org.kohsuke.asm5.ClassReader.(ClassReader.java:153)
> at org.kohsuke.asm5.ClassReader.(ClassReader.java:424)
> at 
> org.kohsuke.stapler.ClassDescriptor$ASM.loadParametersFromAsm(ClassDescriptor.java:312)
> at 
> org.kohsuke.stapler.ClassDescriptor$ASM.access$000(ClassDescriptor.java:300)
> at 
> org.kohsuke.stapler.ClassDescriptor.loadParameterNames(ClassDescriptor.java:196)
> at 
> hudson.util.ReflectionUtils$MethodInfo.names(ReflectionUtils.java:122)
> at 
> hudson.util.ReflectionUtils$Parameter.name(ReflectionUtils.java:180)
> at 
> hudson.util.FormValidation$CheckMethod.findParameters(FormValidation.java:601)
> at 
> hudson.util.FormValidation$CheckMethod.(FormValidation.java:587)
> at hudson.model.Descriptor.getCheckMethod(Descriptor.java:401)
> at hudson.Functions.calcCheckUrl(Functions.java:1917)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at 
> org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:258)
> at 
> org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104)
> at 
> org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83)
> at 
> org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57)
> at 
> org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51)
> at 
> org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80)
> at 
> hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:74)
> at 
> org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61)
> at 
> org.apache.commons.jelly.expression.ExpressionSupport.evaluateAsString(ExpressionSupport.java:46)
> at org.apache.commons.jelly.tags.core.ExprTag.doTag(ExprTag.java:42)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
> at 
> org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
> at 
> org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
> at 
> org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
> at 
> org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
> at 
> org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:100)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
> at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
> at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
> at 
> org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
> at 
> 

Re: Discourse as the default communication channel?

[Matt Sicker]

Ha, so I was. Oops!

On Tue, 25 May 2021 at 10:32, 'Gavin Mogan' via Jenkins Developers
 wrote:
>
> Matt. It's often a confusion point. Discourse is more like a form/mailing 
> list type thing. Discord is realtime communication. Sounds like your 
> describing discord.
>
> On Tue., May 25, 2021, 6:52 a.m. Matt Sicker,  wrote:
>>
>> I’ve never used Discourse outside of video games, but it seems easier to set 
>> up public communities on than Slack or other things we’ve tried here so far. 
>> While in theory I’d prefer something open like Matrix, I do agree that we 
>> should try to minimize the number of services to maintain ourselves.
>>
>> On Tue, May 25, 2021 at 07:45 Oleg Nenashev  wrote:
>>>
>>> Hi all,
>>>
>>> Thanks to Olivier for starting this discussion and for confirming 
>>> sponsorship for Discourse. This is definitely something we could use to 
>>> address the current sprawl of Jenkins communication channels. Many channels 
>>> like User Mailing list, some SIG mailing lists and many Gitter channels 
>>> could be replaced by discourse. So I am +1 for starting evaluation.
>>>
>>>
>>> > 2) Configure the right level of Categories, as a first iteration I would 
>>> > like to focus on Jenkins users but we could extend it to Jenkins 
>>> > contributors as well.
>>>
>>> As Bruce said above, setting up a proper structure and moderation process 
>>> is essential to the success of Discourse. Before we make it official, we 
>>> should try it out and see how to better structure the communication 
>>> channels. IMHO any interested contributor with Discourse expertise is 
>>> welcome to participate in this effort. And thanks for stepping up Bruce!
>>>
>>> My notes:
>>>
>>> I would recommend creating categories for SIGs, sub-projects and outreach 
>>> programs right away.
>>> It would be great to create generic categories like "Jenkins Pipeline" or 
>>> "Jenkins on Kubernetes". Plugins structure should be secondary there
>>> Some plugins and components may need sub-categories. Likely these would be 
>>> tool integration plugins (e.g. "Git plugins")
>>> TBD: Creating a Governance category? It is feasible, but I am not sure how 
>>> dit aligns with the current open governance approach through this mailing 
>>> list and meetings
>>>
>>> I am happy to be a guinea pig for some of the categories if needed.
>>>
>>>
>>> > 1) Delegating authentication to a third service, Github, keycloak, LDAP, 
>>> > etc...  My preferred approach would be to rely on Github SSO to 
>>> > authenticate with the tool. But we could still use our Jenkins account.
>>>
>>> I am -1 for using the Jenkins account. Last year we agreed that we want to 
>>> move away from running our own user identity, and I believe it was a right 
>>> decision. One of the interesting options would be using the Linux 
>>> Foundation SSO so that the forum is aligned with the Linux Foundation 
>>> identities. If technically feasible, this would be my preference.
>>>
>>> Best regards,
>>> Oleg Nenashev
>>>
>>> P.S: My personal experience with forums is very limited. Fun fact about me: 
>>> I was moderating a Lineage clan forum for a year or so. No, no further 
>>> comments :P
>>>
>>> On Tuesday, May 25, 2021 at 11:38:58 AM UTC+2 bruce...@gmail.com wrote:
>>>>
>>>> Hi all.
>>>>
>>>> long time lurker, but this is my time to speak up. I have maintained many 
>>>> instances of Jenkins, and just as many instances of Discourse - most 
>>>> recent one is defined here : 
>>>> https://github.com/EGI-Federation/community.egi.eu (I have since moved on).
>>>>
>>>> It is imho the right choice for this, but there are good ways to use it 
>>>> and better ways to use it. Beyond putting my vote for what it's worth 
>>>> behind this decision, I would also like to volunteer my time where 
>>>> possible to help setting up and moderating, etc.
>>>> Happy to help in whatever way.
>>>>
>>>> Thanks,
>>>> Bruce
>>>>
>>>> On Tuesday, May 25, 2021 at 11:02:15 AM UTC+2 Olblak wrote:
>>>>>
>>>>> Hi Everybody,
>>>>>
>>>>> I am really glad to share that "Civilized Discourse Construction Kit, 
>>>>> Inc", the company behi

Re: Discourse as the default communication channel?

[Matt Sicker]

I’ve never used Discourse outside of video games, but it seems easier to
set up public communities on than Slack or other things we’ve tried here so
far. While in theory I’d prefer something open like Matrix, I do agree that
we should try to minimize the number of services to maintain ourselves.

On Tue, May 25, 2021 at 07:45 Oleg Nenashev  wrote:

> Hi all,
>
> Thanks to Olivier for starting this discussion and for confirming
> sponsorship for Discourse. This is definitely something we could use to
> address the current sprawl of Jenkins communication channels. Many channels
> like User Mailing list, some SIG mailing lists and many Gitter channels
> could be replaced by discourse. So I am +1 for starting evaluation.
>
>
> > 2) Configure the right level of Categories, as a first iteration I would
> like to focus on Jenkins users but we could extend it to Jenkins
> contributors as well.
>
> As Bruce said above, setting up a proper structure and moderation process
> is essential to the success of Discourse. Before we make it official, we
> should try it out and see how to better structure the communication
> channels. IMHO any interested contributor with Discourse expertise is
> welcome to participate in this effort. And thanks for stepping up Bruce!
>
> My notes:
>
>- I would recommend creating categories for SIGs, sub-projects and
>outreach programs right away.
>- It would be great to create generic categories like "Jenkins
>Pipeline" or "Jenkins on Kubernetes". Plugins structure should be secondary
>there
>- Some plugins and components may need sub-categories. Likely these
>would be tool integration plugins (e.g. "Git plugins")
>- TBD: Creating a Governance category? It is feasible, but I am not
>sure how dit aligns with the current open governance approach through this
>mailing list and meetings
>
> I am happy to be a guinea pig for some of the categories if needed.
>
>
> > 1) Delegating authentication to a third service, Github, keycloak, LDAP,
> etc...  My preferred approach would be to rely on Github SSO to
> authenticate with the tool. But we could still use our Jenkins account.
>
> I am -1 for using the Jenkins account. Last year we agreed that we want to
> move away from running our own user identity, and I believe it was a right
> decision. One of the interesting options would be using the Linux
> Foundation SSO so that the forum is aligned with the Linux Foundation
> identities. If technically feasible, this would be my preference.
>
> Best regards,
> Oleg Nenashev
>
> P.S: My personal experience with forums is very limited. Fun fact about
> me: I was moderating a Lineage clan forum for a year or so. No, no further
> comments :P
>
> On Tuesday, May 25, 2021 at 11:38:58 AM UTC+2 bruce...@gmail.com wrote:
>
>> Hi all.
>>
>> long time lurker, but this is my time to speak up. I have maintained many
>> instances of Jenkins, and just as many instances of Discourse - most recent
>> one is defined here : https://github.com/EGI-Federation/community.egi.eu
>> (I have since moved on).
>>
>> It is imho the right choice for this, but there are good ways to use it
>> and *better* ways to use it. Beyond putting my vote for what it's worth
>> behind this decision, I would also like to volunteer my time where possible
>> to help setting up and moderating, etc.
>> Happy to help in whatever way.
>>
>> Thanks,
>> Bruce
>>
>> On Tuesday, May 25, 2021 at 11:02:15 AM UTC+2 Olblak wrote:
>>
>>> Hi Everybody,
>>>
>>> I am really glad to share that "Civilized Discourse Construction Kit,
>>> Inc", the company behind Discourse
>>> offered to sponsor the Jenkins project with the business "tier"
>>> -> https://www.discourse.org/pricing
>>>
>>> This is a very nice opportunity to "organize" discussions happening
>>> across the community.
>>> Different people have different expectations so feel free to raise your
>>> voice and share your ideas.
>>>
>>> What we want to achieve is better communication with the Jenkins
>>> community, at the moment a lot of valuable information is lost in the
>>> various mailing list, Gitter, IRC, etc.
>>> By using Discourse it would allow to centralize questions in one place
>>> and regroup them by categories
>>>
>>> At this stage, we are still in exploratory mode, so if you have any
>>> experience with the tool or just want to help
>>> feel free to reach out so I can send you an invite.
>>> The discourse will be one of the topics for today's infrastructure
>>> meeting.
>>>
>>> The service is available on "https://community.jenkins.io;.
>>>
>>> The next steps are:
>>>
>>> 1) Delegating authentication to a third service, Github, keycloak, LDAP,
>>> etc...
>>>
>>> My preferred approach would be to rely on Github SSO to authenticate
>>> with the tool. But we could still use our Jenkins account. Opinions are
>>> more than welcome.
>>>
>>> 2) Configure the right level of Categories, as a first iteration I would
>>> like to focus on Jenkins users but we could 

Re: GSoC 2021 - Please welcome Jenkins students!

[Matt Sicker]

Welcome, everyone!

On Mon, May 17, 2021 at 18:06 Oleg Nenashev  wrote:

> Dear all,
>
> The GSoC 2021 projects have been announced by Google today. The Continuous
> Delivery Foundation will have 6 projects this year, and five of them will
> be focused on Jenkins. You can find all the projects here
> .
> Please welcome the GSoC 2021 students!
>
>- Shruti Chaturvedi, "CloudEvents Plugin for Jenkins: Consume and Emit
>CloudEvents". Mentors: Vibhav Bobade, Jeff Pearce, Mauricio Salatino
>- Harshit Chopra, "Git credentials binding for sh, bat, and
>powershell", Mentors:  Mark Waite, Justin Harringa, Rishabh Budhouliya
>- Akihrio Kiuchi, "Jenkins Remoting Monitoring", Mentors: Oleg
>Nenashev, Sumit Sarin, Darshan Kansagara
>- Pulkit Sharma, "Security Validator for Jenkins Kubernetes Operator",
>Mentors: Bartek Antoniak, Sylwia Brant, Jakub Al-Khalili
>- Aditya Srivastava, "Semantic Versioning Plugin for Jenkins",
>Mentors: Gareth Evans, Kristin Whetstone, Olivier Vernin, Allan Burdajewicz
>- (+) In addition to 5 Jenkins projects, Daniel Ko will be working on
>try.spinnaker.io, Mentors: Dan Johnston, Fernando Freire, Cameron
>Motevasselani
>
> During the next 3 weeks the GSoC teams will work on the community bonding,
> including but not limited to: getting introduced to each other and the key
> stakeholders, setting up the communication channels, forming the project
> plan, and doing knowledge transfers. We invite all community members to
> reach out to the project teams if you are interested in a project and want
> to contribute there and/or to be informed about the progress. Any
> assistance to the students will be always appreciated.
>
> All the listed projects have high value to the Jenkins community,
> particularly for public cloud deployments and for the ongoing Jenkins
> software delivery pipelines rework. We are looking forward to working with
> the students and mentors this summer, welcome everyone!
>
> Best regards,
> Oleg Nenashev
> CDF GSoC Org Team
>
> P.S: See the GSoC sub-project mailing list to know more about the GSoC
> projects announcement:
> https://groups.google.com/g/jenkinsci-gsoc-all-public/c/EkwY7o2Jgzo . We
> will also have the regular office hours on Wednesday, 2PM UTC. See
> https://www.jenkins.io/events for the links
>
>
> --
> 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/CAPfivLALWHkiauVmRqUL2zqTLz4ufqo2%2BUm%2B6WPwA4rnFBj8Fw%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/CACmp6kqtsOAortf%3Dqfdo70rbNVqLFYWBgciPLuK__%3DtvsVcsDw%40mail.gmail.com.

Re: Proposal: Open Governance - Tracking key action items/requests in GitHub Issues

[Matt Sicker]

I think it's a good idea. I'm a huge fan of asynchronous
communications like that which make it easier for part time
contributors to keep up to date. (Of course, I'm biased since that's
what we do at Apache)

On Mon, 17 May 2021 at 17:00, Oleg Nenashev  wrote:
>
> Hi all,
>
> I would like to follow-up on a Jenkins governance help offer from Rick in 
> this thread.
>
> Currently we do the most of the planning and discussions via mailing lists 
> and governance meetings. For common community members, it might be difficult 
> to see what are the initiatives/projects being handled by the board at the 
> moment. It is also hard for potential contributors to see the governance 
> backlog and to contribute to the open items in our TODO list.
>
> What if we create a new public github repo like jenkinsci/governance and put 
> key issues/projects there, e.g. (Adoption of EasyCLA, CDF Project 
> representatives Elections, Contributor summit, etc.). It should not be a 
> replacement for the mailing lists OR a micromanagement tool, but we can use 
> it to provide a way to highlight key problems we are about working on. The 
> new repo can be also used as a public RFE tracker and maybe even a Q forum 
> for the governance matters though, again, it should not replace the mailing 
> discussions.
>
> Such approach would partially overlap with the Jenkins public roadmap, but 
> only for big initiatives which need to be represented there.
>
> What do you think?
>
> Best regards,
> Oleg Nenashev
>
> --
> 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/92e0af37-e7eb-49c8-8c10-599daf071928n%40googlegroups.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/CACmp6korOkdLg%2B_Q1j3-JUYcwmNPByPir2ZcLqPvQFkGHYdGug%40mail.gmail.com.

Re: CDF Technical Oversight Committee - Jenkins project representative nominations

[Matt Sicker]

I second that nomination!

On Fri, Apr 30, 2021 at 23:20 Rick  wrote:

> Hi the community,
>
> I’d like to nominate Oleg Nenashev to be the candidate of TOC.
>
> As we all know, he plays a very important role in the Jenkins community
> for a long time. He contributed his time a lot. I only know a part of those
> events, but it’s not all. Such as:
>
>
>- GSoC admin and mentor for almost every year (I didn’t participant
>all)
>- As a maintainer and reviewer among the Jenkins core and many plugin
>projects
>- He is super friendly for every single newcomer
>- He helped organized many online ( or offline) meetups
>- He helped to maintain Jenkins social media, such as twitter, LinkedIn
>- And more
>
>
> Best regards,
> Rick
>
>
>
>
> On 05/1/2021 05:20，Oleg Nenashev
>  wrote：
>
> Dear all,
>
> CDF has just announced the new elections for project representatives to
> the CDF Technical Oversight Committee
> . This entity facilitates
> communication and collaboration among the Technical Projects, and also
> makes key decisions on topics like project graduation. Four seats in the
> CDF TOC are dedicated to CDF project representatives. It is important to
> have a Jenkins representative in the CDF TOC so that the community
> interests are represented at the CDF level.
>
> Kohsuke is our current representative, and his term has expired in
> February 2021. There will be new elections, and now the Jenkins project is
> not guaranteed to have a TOC seat. Each of 6 projects is expected to
> nominate one candidate, and then there will be elections by CDF members (6
> candidates for four seats). We need to nominate a single candidate from the
> Jenkins project by May 14th, see the full timeline in the forwarded email
> below.
>
> The Jenkins Governance Board has discussed the nominations and agreed to
> follow the public nomination and confirmation process. Due to the short
> timeframe, we do not want to invent a new voting/nomination process.
>
>- We encourage all community members to submit nominations in this
>thread. All nominations are to be submitted by the governance meeting on
>May 05. The Jenkins Governance Board will also make a nomination this
>weekend.
>- Community members are welcome to cast their votes asynchronously in
>the mailing list or at the governance meeting (7PM UTC on May 05)
>- If there is a strong consensus about the candidate, we will make a
>final decision at the Governance meeting on May 05. Otherwise, we will run
>elections from May o5 to May 13 using the mailing list or CIVS (to be
>decided at the meeting).
>- As for governance board and officer elections, the Jenkins
>Governance Board reserves the right to vet candidates. We have never needed
>this right before though.
>
> Please submit nominations in this thread! If you have any concerns about
> the process or the candidates you'd like to share privately, please contact
> us using jenkinsci-bo...@googlegroups.com. If your concern is related to
> a board member, contact other board members using private email.
>
> Best regards and thanks for your time!
> Jenkins Governance Board
>
> -- Forwarded message -
> From: Tracy Miranda 
> Date: Tue, Apr 27, 2021 at 6:10 PM
> Subject: [cdf-toc] Elections for CDF TOC Project Seats
> To: cdf-toc 
>
>
> All,
>
> 4 of the 9 TOC seats are selected from CDF project representatives as per
> charter:
>
> i) four representatives nominated by, and voted upon, by the technical
> oversight body (e.g., a technical steering committee) of the TOC Projects
> (as defined herein). Each TOC Project may nominate a maximum of one project
> representative to run for these seats.
>
> We would like to kick off the election process for this, with a proposed
> timeline as:
>
> Date
>
> Event
>
> May 3
>
> Election announced, projects begin choosing candidates
>
> May 14
>
> Deadline for projects to choose candidate
>
> May 21
>
> Candidate profiles made public
>
> May 24
>
> Voting opens
>
> June 11
>
> Voting closes
>
> June 23
>
> Winners announced
>
> July 1
>
> New reps begin their term
>
>
>
> Further details in the proposal are captured here: CDF TOC Project Rep
> Elections Proposal
> 
>
> Based on feedback in the TOC meeting today we will start moving forward
> towards this timeline and will be reaching out to project communities to
> select their nominees.
>
> This is the first time we are running an election for the TOC project reps
> in this way and will be tracking here
> https://github.com/cdfoundation/foundation/issues/322. We will be working
> towards officially kicking off on May 3rd 2021!
>
> Regards,
>
> Tracy
> _._,_._,_
> --
> Links:
>
> You receive all messages sent to this group.
>
> View/Reply Online (#674)
> 

Re: Native build of Jenkins CLI

[Matt Sicker]

I'd expect the improvements in startup time for certain commands will
be useful at least.

On Fri, 30 Apr 2021 at 17:07, Oleg Nenashev  wrote:
>
> Just in case, do you have any performance metrics? I am not sure a native 
> build makes a huge difference w.r.t performance.
>
> Overall, it would be interesting to ship native binaries which do not require 
> Java. Maybe it's time to finally detach Jenkins CLI to a separate repo. It 
> would require a pretty big refactoring work, because the Jenkins core 
> declares dependency on Jenkins CLI to use its classes. We would need to 
> unravel a bunch of API classes into a separate library, but it should be good 
> for the codebase in general.
>
> On Friday, April 30, 2021 at 11:25:32 PM UTC+2 Jesse Glick wrote:
>>
>> If there is interest, could be moved to @jenkinsci via HOSTING request.
>>
>> https://github.com/jglick/jenkins-cli-native
>
> --
> 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/ce0afc56-c329-484b-aeb4-19dc3271f6b2n%40googlegroups.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/CACmp6kqjnp0o94VyAUVNrAjAReR%2BM4UL1wHX%3DHXnFLTyLGYc1w%40mail.gmail.com.

Re: Using JDK 11 instead of JDK 8 in default docker images

[Matt Sicker]

A transition period using Java 11 Docker images with Java 8
compatibility would be useful IMO.

On Tue, 27 Apr 2021 at 22:21, Raihaan Shouhell  wrote:
>
> Perhaps removal of java 8 support should come with a bump in major version 
> number so jenkins 3.x and an announcement ahead of time.
>
> Cheers,
> Raihaan
>
> On Wed, Apr 28, 2021, 7:42 AM Oleg Nenashev  wrote:
>>
>> I am in favor of making JDK11 the default in all our distributions, 
>> including controller and agent Docker images.
>> At the same time I am afraid that removal of Java 1.8 support is premature. 
>> The vast majority of Jenkins users still uses this version, and the 
>> migration to Java 11 won't be seamless in al l cases. For example, Maven 
>> Plugin will effectively switch project builds to Java 11 once the agent 
>> images are updated. It will cause unexpected issues in user builds here and 
>> there. Nothing should be critical, but we should not force users to migrate 
>> immediately.
>>
>> IMHO there should be a grace period between Java 8 support deprecation and 
>> the actual removal. Maybe 6 months or so.
>>
>> BR, Oleg
>>
>> On Tuesday, April 27, 2021 at 7:13:17 PM UTC+2 slide wrote:
>>>
>>> I agree with dropping java 8. There are some nice features in 11 that would 
>>> be good to use.
>>>
>>> On Tue, Apr 27, 2021 at 9:11 AM Tim Jacomb  wrote:

 We’ve been using it for over a year on java 11 and never hit an issue...

 I would rather drop java 8 as well

 On Tue, 27 Apr 2021 at 15:48, Jesse Glick  wrote:
>
> My opinion remains that if we believe Java 11 support is solid enough to 
> be the default, then we may as well keep things simple and drop Java 8 
> support: start building core and important plugins with `java.level=11`, 
> and take advantage of its features. Building and testing primarily 
> against 8 while pushing users to run 11, and forcing developers to 
> consider both platforms in every situation, seems like the worst decision.
>
> --
> 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/CANfRfr2hjuPWgK7XqzwezcT8eP1i1_ZZd_iMNreg%3D7K7FTzH8Q%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/CAH-3BifVe04fx-7vx6Dp-jkLmTvepCDGHXqRDLEWdHyNN8TG%3Dw%40mail.gmail.com.
>>>
>>>
>>>
>>> --
>>> Website: http://earl-of-code.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/74c9f96d-1acc-4315-9fd5-e59bb6fdeff8n%40googlegroups.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/CAFoxvgwycdrsK9dX-A7KVcA%2Bi%3Dta6dhc4iZbVAz%2BRKv3dn5Ymg%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/CACmp6koaWJhQ6R_6991XaFfF%2ByHxEkhoKv%3DsYmE0SmnreOu2tQ%40mail.gmail.com.

Re: ANN - Jenkins Governance update (Marky Jackson)

[Matt Sicker]

Thanks for all your hard work and infectious enthusiasm, Marky!

On Thu, Mar 4, 2021 at 9:51 AM Alyssa Tong  wrote:
>
> Thank you Marky for your time and contributions to the project, you're made a 
> difference. Altho you're stepping down, we hope you'll still be around 
> because you're much needed.
>
> Thank you and all the best.
>
> BR,
> alyssa
>
>
>
> On Thu, Mar 4, 2021 at 7:22 AM Jeff Pearce  wrote:
>>
>> Thanks for all you’ve contributed over the past several years, Marky. Your 
>> contributions have made a notable difference.
>>
>> Sent from my iPhone
>>
>> On Mar 4, 2021, at 6:34 AM, Oleg Nenashev  wrote:
>>
>> 
>> Notice: This email is from an external sender.
>>
>>
>>
>> Dear all,
>>
>> Effective today, Marky Jackson is stepping down from the Jenkins Governance 
>> Board and Event Officer positions. On behalf of the Jenkins community, we 
>> would like to thank Marky for all contributions and for the continued 
>> participation in the Jenkins community. As an active Jenkins contributor and 
>> community leader, Marky helped a lot of initiatives to happen: Jenkins and 
>> Kubernetes ecosystem, terminology changes, GSoC and GSoD, pipeline authoring 
>> SIG and many more activities. Thank you Marky!
>>
>> Based on the Interim procedures, the Jenkins Governance board will appoint 
>> an interim board member and a new event officer, subject to approval in a 
>> regular governance meeting (Mar 10). Nominations:
>>
>> Jenkins Governance Board member - the board would like to respect the 2020 
>> Election Results and to appoint Ewelina Wilkosz as an interim board member. 
>> Ewelina got the most of the votes among board member candidates.
>> Event Officer - nominations are open! If you are interested to become the 
>> new even officer, please reach out to the Jenkins Governance Board.
>>
>> Best regards,
>> Oleg Nenashev
>>
>>
>> --
>> 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/CAPfivLAtsyGErEEspBRESgknamtfAO1C9V3TjnWW5y8zSLXz1A%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/EE3EA218-466C-48D8-9AEB-04C743307256%40gmail.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/CAC9wNaxkRth22KxePUeo-r8tguMZPB-rJaVTHyCBsCfnZ219%3Dw%40mail.gmail.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/CAEot4oy7aSAac%3D4zkBJ087pjo-YWnyvTa617Gt%2BY%2BwMYuzkkrg%40mail.gmail.com.

Re: Support for multi-cloud/account setups in Jenkins plugins

[Matt Sicker]

This sounds like something that belongs in an identity and access
management solution in general since it's a common problem to be
solved for all your other applications using those auth sources.

On Fri, Feb 12, 2021 at 5:40 AM Chris Kilding
 wrote:
>
> Hello,
>
> Interest in multi-cloud and multi-account cloud setups is increasing at my 
> company, and I have had correspondence from people in other companies about 
> this too. It's worth thinking about how Jenkins is going to work in this 
> scenario going forward.
>
> There are quite a few Jenkins plugins that connect to cloud providers (e.g. 
> EC2 plugin, S3 plugin, my own Secrets Manager plugin, plus all the Azure, 
> GCP, Kubernetes equivalents). At the moment, these plugins are (at the risk 
> of generalising) built with the assumption that they connect to a single 
> cloud account. They work well within this assumption, but not outside it.
>
> The key issues at the moment are:
>
> 1. Name clashes (due to lack of namespacing facilities) when two resources in 
> different accounts have the same name.
> 2. Slowness/unavailability from interactions with one cloud account affecting 
> interactions with other accounts.
>
> To resolve the first problem, I would propose that we introduce a namespacing 
> feature of some kind, to allow resources from different accounts to safely 
> coexist.
>
> For the second problem, perhaps some partitioning of operations could be done 
> within the namespacing feature, so that if one API call goes bad or slower 
> than the others, it doesn't affect interactions with other accounts.
>
> At a minimum this would need to be done in the credentials API plugin: I'm 
> thinking an optional `namespace` argument could be specified for the 
> `withCredentials` or `credentials` bindings, implemented by the credential 
> providers. But I'm not sure that namespaces should be limited to just the 
> credentials system. Are there other parts of the Jenkins pipeline which deal 
> with cloud resources, and so would need to be aware of the namespacing 
> feature as well?
>
> Regards,
>
> Chris
>
> PS: In the past I have considered generalising the folders credentials 
> provider for this purpose, but this does not seem like the right fit. This is 
> really a namespacing problem, not an access control problem (which is what 
> folders are for).
>
> --
> 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/3e423f19-b3d1-4827-9881-b89d3b73b051%40www.fastmail.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/CAEot4owhMdnn5gNQGrkCdv%3D_dCD9oMHmy81khELxZfzgHiTOOA%40mail.gmail.com.

Re: Jenkins Core and Plugins VS FIPS 140-2

[Matt Sicker]

I'd imagine a global security configuration option in
bouncycastle-api-plugin to choose whether to use BC or BCFIPS could
work. If that's too late in the initialization process, then a system
property to allow overriding which BC provider to use may be more
appropriate.

I also have a concern about data migration for any encrypted stored
data if it needs to change algorithms, but that might not be a problem
depending on which AES modes are still allowed in FIPS. For that area,
there's the ConfidentialStore API in Jenkins core along with
hudson.util.Secret (which uses that store API), some encryption code
in credentials plugin for certificate credentials support, and some
encryption code in ssh-credentials plugin for supporting different key
formats (FIPS requires use of PKCS12 private keys, not the OpenSSH
format, so you may need to add support there if you're using SSH,
too).

On Fri, Feb 5, 2021 at 9:52 AM Илья Гуляев  wrote:
>
> I've done several PR in Jenkins Core and Remoting:
> https://github.com/jenkinsci/jenkins/pull/5266
> https://github.com/jenkinsci/remoting/pull/435
>
> Also, I've added change to kubernetes-client used in several plugins:
> https://github.com/fabric8io/kubernetes-client/pull/2788
>
> At least the following plugins should bump the version of kubernetes-client 
> after the fix will be released:
> https://github.com/jenkinsci/kubernetes-client-api-plugin
> https://github.com/jenkinsci/kubernetes-plugin
>
> Now I need suggestions on how to exclude adding BouncyCastleProvider time.
> https://github.com/jenkinsci/bouncycastle-api-plugin/blob/master/src/main/java/jenkins/bouncycastle/api/InstallBouncyCastleJCAProvider.java
> https://github.com/jenkinsci/bouncycastle-api-plugin/blob/master/src/main/java/jenkins/bouncycastle/api/SecurityProviderInitializer.java
>
>
> пятница, 5 февраля 2021 г. в 18:38:11 UTC+3, msi...@cloudbees.com:
>>
>> I think it'll require a bit more patching than just that. What about
>> all the plugins and Jenkins core code that requests non-FIPS
>> algorithms? For example, MD5 is still used for some non-security
>> features, and I wouldn't expect that to be available in a
>> FIPS-compliant JCE provider.
>>
>> On the other hand, I'd hope that their JSSE stuff for TLS connections
>> works fairly transparently which would at least cover the HTTPS and
>> some Remoting connections.
>>
>> On Fri, Feb 5, 2021 at 7:41 AM Илья Гуляев  wrote:
>> >
>> > Hi all,
>> > I want to add support of FIPS 140-2 to Jenkins Core and some plugins.
>> >
>> > BouncyCastle Security provider used in Jenkins has FIPS version.
>> > https://downloads.bouncycastle.org/fips-java/BC-FJA-UserGuide-1.0.2.pdf
>> > https://downloads.bouncycastle.org/fips-java/BC-FJA-(D)TLSUserGuide-1.0.9.pdf
>> > https://downloads.bouncycastle.org/fips-java/BC-FJA-SecurityPolicy-1.0.2.pdf
>> >
>> > I've tried to run Jenkins with BouncyCastleFipsProvider and found some 
>> > blockers:
>> >
>> > Use hardcode of JKS keystore (BouncyCastleFipsProvider use BCFKS)
>> >
>> > https://github.com/search?l=Java=org%3Ajenkinsci+JKS=Code
>> > Suggested solution:
>> > Change
>> > KeyStore.getInstance("JKS");
>> > to
>> > KeyStore.getInstance(KeyStore.getDefaultType());
>> >
>> > Don't add BouncyCastleProvider in case BouncyCastleFipsProvider already 
>> > used, because BouncyCastleProvider contains algorithms, that can't be used 
>> > in FIPS mode.
>> >
>> > https://github.com/search?p=2=org%3Ajenkinsci+BouncyCastleProvider=Code
>> > It can be 2 solutions:
>> > 1. Check already used providers and don't add new if BouncyCastle(BC) or 
>> > BouncyCastleFIPS(BCFIPS) already used.
>> > Example:
>> > if (Security.getProvider("BC") == null && Security.getProvider("BCFIPS")) {
>> > Security.addProvider(new 
>> > org.bouncycastle.jce.provider.BouncyCastleProvider());
>> > }
>> > 2. Add the flag for FIPS mode, which should be used in plugins
>> > Example:
>> > if (isFipsMode()) {
>> > Security.addProvider(new 
>> > org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider());
>> > } else {
>> > Security.addProvider(new 
>> > org.bouncycastle.jce.provider.BouncyCastleProvider());
>> > }
>> >
>> > What do you think about that change? What you can suggest?
>> > I can do pull requests for projects used in my Jenkins installation and 
>> > will be happy if someone will help with other projects.
>> >
>> > --
>> > You received this messa

Re: Jenkins Core and Plugins VS FIPS 140-2

[Matt Sicker]

I think it'll require a bit more patching than just that. What about
all the plugins and Jenkins core code that requests non-FIPS
algorithms? For example, MD5 is still used for some non-security
features, and I wouldn't expect that to be available in a
FIPS-compliant JCE provider.

On the other hand, I'd hope that their JSSE stuff for TLS connections
works fairly transparently which would at least cover the HTTPS and
some Remoting connections.

On Fri, Feb 5, 2021 at 7:41 AM Илья Гуляев  wrote:
>
> Hi all,
> I want to add support of FIPS 140-2 to Jenkins Core and some plugins.
>
> BouncyCastle Security provider used in Jenkins has FIPS version.
> https://downloads.bouncycastle.org/fips-java/BC-FJA-UserGuide-1.0.2.pdf
> https://downloads.bouncycastle.org/fips-java/BC-FJA-(D)TLSUserGuide-1.0.9.pdf
> https://downloads.bouncycastle.org/fips-java/BC-FJA-SecurityPolicy-1.0.2.pdf
>
> I've tried to run Jenkins with BouncyCastleFipsProvider and found some 
> blockers:
>
> Use hardcode of JKS keystore (BouncyCastleFipsProvider use BCFKS)
>
> https://github.com/search?l=Java=org%3Ajenkinsci+JKS=Code
> Suggested solution:
> Change
> KeyStore.getInstance("JKS");
> to
> KeyStore.getInstance(KeyStore.getDefaultType());
>
> Don't add BouncyCastleProvider in case BouncyCastleFipsProvider already used, 
> because BouncyCastleProvider contains algorithms, that can't be used in FIPS 
> mode.
>
> https://github.com/search?p=2=org%3Ajenkinsci+BouncyCastleProvider=Code
> It can be 2 solutions:
> 1. Check already used providers and don't add new if BouncyCastle(BC) or 
> BouncyCastleFIPS(BCFIPS) already used.
> Example:
> if (Security.getProvider("BC") == null && Security.getProvider("BCFIPS")) {
> Security.addProvider(new 
> org.bouncycastle.jce.provider.BouncyCastleProvider());
> }
> 2. Add the flag for FIPS mode, which should be used in plugins
> Example:
> if (isFipsMode()) {
> Security.addProvider(new 
> org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider());
> } else {
> Security.addProvider(new 
> org.bouncycastle.jce.provider.BouncyCastleProvider());
> }
>
> What do you think about that change? What you can suggest?
> I can do pull requests for projects used in my Jenkins installation and will 
> be happy if someone will help with other projects.
>
> --
> 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/c27a5acc-e75b-43b7-826a-1610e12d7565n%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/CAEot4oz-f6BSRnHtgTu3WGdNCoAg7SkRUSX-H7UhPS%3Dgx65spQ%40mail.gmail.com.

Re: Has anyone implemented OpenTelemetry or similar observability APIs in Jenkins?

[Matt Sicker]

Hey, great to see you again, Cyrille!

This sounds interesting. I'm still not a fan of their enormous
dependency stack, but I'm sure it's sufficient for prototyping. :)

On Tue, Jan 12, 2021 at 2:52 AM 'Cyrille Le Clerc' via Jenkins
Developers  wrote:
>
> Hello Matt,
>
> For Your Information
>
> I'm writing a PoC to instrument Jenkins with OpenTelemetry.
>
> code: https://github.com/cyrille-leclerc/opentelemetry-plugin
>
> My focus for the moment is tracing the execution of jobs with OpenTelemetry 
> distributed traces
>
> I have a glitch for which I am asking for help on 
> https://groups.google.com/g/jenkinsci-dev/c/TEMMId7vzh0
>
> I plan later down the road to instrument:
>
> Jobs with OpenTelemetry metrics and logs
> Jenkins internals with OpenTelemetry metrics and logs
>
> We could also instrument Jenkins HTTP requests as you said
>
> As OpenTelemetry is emerging as the standard for Observability / Monitoring 
> with integrations with most observability technologies, open source and 
> commercial, such as Jaeger, Elastic, Prometheus...), this integration will 
> enable CI monitoring to most Jenkins users.
>
> Cyrille
>
> On Thursday, May 7, 2020 at 12:11:37 AM UTC+2, Matt Sicker wrote:
>>
>> Site: https://opentelemetry.io/
>>
>> This seems like it could be a useful thing to integrate with,
>> particularly for Remoting-related network calls, but it could
>> potentially be extended to other HTTP client type calls and such for
>> richer tracing data. As a Jenkins admin, you'd be able to identify
>> issues in your Jenkins cluster more easily. Implemented properly, it
>> could even provide a way for users to submit traces to help debug
>> issues they find.
>>
>> I looked at their Java library, and it seems to have an absurd amount
>> of dependencies compared to a proper logging library (which has no
>> required dependencies), but the gist of attaching traces and spans to
>> requests/responses is fairly simple to implement.
>>
>> --
>> 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/296be7c7-f98b-4f80-a3a8-f023ffb118c7o%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/CAEot4oxM1tjmFjd_7ht89vzXiq0kq6B0C%2BveAzGR7O%2Be%3DQtxuw%40mail.gmail.com.

Re: 2021 priorities for Jenkins - Security

[Matt Sicker]

Getting together to define some secure setup guidelines for users
would be useful, too. It's not that helpful that Jenkins and its
plugins are more secure if users end up configuring Jenkins insecurely
in the first place!

On Thu, Jan 21, 2021 at 7:12 AM 'Olblak' via Jenkins Developers
 wrote:
>
> Thanks, Oleg for putting down this, I would definitely be interested to chat 
> during the contributor summit about this topic.
>
> On Thu, Jan 21, 2021, at 1:48 PM, Oleg Nenashev wrote:
>
> Just a quick follow-up to this thread, there is ongoing discussion about 
> hosting a contributor summit after FOSDEM.
> Should it happen, I suggest having a security track/section there. We had a 
> similar one last year in Brussels, and IIRC it went quite well.
>
> Ideas/comments and topic suggestions are welcome :)
>
>
> On Tuesday, January 19, 2021 at 9:02:51 AM UTC+1 Oleg Nenashev wrote:
>
> Hi all,
>
> To follow-up on the Jenkins Governance meeting we had last week, I'd like to 
> continue the discussion about Jenkins security which was suggested as one of 
> 2021 priorities. In this thread I propose to discuss ideas w.r.t improving 
> security of Jenkins components and software supply chains. NOTE: Please do 
> not reference unfixed security issues in this thread (reporting 
> vulnerabilities).
>
> Current state. Jenkins Security Team is doing a great job w.r.t. addressing 
> security issues. In 2020 we had 19 security advisories with 198 fixed 
> vulnerabilities and 72 disclosed ones. There were great additions to 
> devtools: Dependabot, GitHub CodeQL, Find-Sec-Bugs, etc. Also, new plugin 
> hosting requests now get on-demand security reviews before being published. 
> All of that is a great progress compared to the state we had several years 
> ago.
>
> What’s next? With all the recent events, security of the software delivery 
> chain is in the spotlight for the many organizations. Jenkins is a key part 
> of this chain for many users, and for sure we want to keep it that way. It is 
> not “just” about timely fixing security issues and preventing 
> misconfiguration. We are also interested to keep our own delivery processes 
> in the best possible shape.
>
> Some ideas we discussed at the meeting:
>
> Growing security awareness among contributors so that the new code and 
> documentation get developed with security in mind.
> Expanding developer tooling. It would help to automate, and, when relevant, 
> enforce preferred security practices in Jenkins components.
>
> Examples: release automation infrastructure, adopting more analysis tools in 
> the default pipelines. With a great start in previous years, we could 
> definitely do more by using available tools and sponsorships.
>
> Getting more contributors involved in the security effort. It is not only 
> about delivering the security fixes. Many topics could be discussed publicly 
> in SIGs and sub-projects, e.g. hardening Docker images, demonstrating 
> security tools with Jenkins, and so on. Contributors could also help with 
> security reviews
> // Add your ideas in replies!
>
> What do you think about these items? Would you like to suggest more 
> additional areas where we could improve? Any feedback would be appreciated.
>
> Best regards,
> Oleg Nenashev
>
>
> --
> 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/ea30b90e-c2ee-433f-868d-384793350481n%40googlegroups.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/735b71c9-6321-41a0-b3cc-7c13177ac66e%40www.fastmail.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/CAEot4ozxuAZz-ssfKzT6k%3D6r2pfdxfEt%2BBnMaNMfpEV_Zoo8hA%40mail.gmail.com.

Re: Releasing JCasC support for ghprb-plugin

[Matt Sicker]

I'd argue that without a maintainer, a plugin would be better off
archived until someone with sufficient interest to maintain it
volunteers.

On Fri, Jan 22, 2021 at 3:05 AM ogondza  wrote:
>
> I understand it feels strange, though it is the second best thing we can do 
> in case we lack a maintainer.
> On Wednesday, January 6, 2021 at 5:53:37 PM UTC+1 msi...@cloudbees.com wrote:
>>
>> I'd prefer if this plugin has an actual maintainer. Otherwise, this
>> also seems like false advertising that the plugin is still supported
>> by anyone.
>>
>> On Wed, Jan 6, 2021 at 10:45 AM 'Gavin Mogan' via Jenkins Developers
>>  wrote:
>> >
>> > If you do a release and there are new bugs are you going to handle them?
>> >
>> > Without a maintainer it seems like deploying to prod and not monitoring 
>> > afterwards.
>> >
>> > Gavin
>> >
>> > On Wed., Jan. 6, 2021, 6:03 a.m. Marky Jackson,  
>> > wrote:
>> >>
>> >> Same, no objections
>> >>
>> >> On Jan 6, 2021, at 6:01 AM, Mark Waite  wrote:
>> >>
>> >> 
>> >> No objections from me.
>> >>
>> >> On Wed, Jan 6, 2021 at 2:18 AM Oliver Gondža  wrote:
>> >>>
>> >>> Hey, there is a long anticipated feature merged in in the plugin[1][2],
>> >>> but no maintainer appears to be active to cut a release.
>> >>>
>> >>> Are there any objections if I step in a do the release?
>> >>>
>> >>> [1] https://github.com/jenkinsci/ghprb-plugin/pull/731
>> >>> [2] https://issues.jenkins-ci.org/browse/JENKINS-55793
>> >>> --
>> >>> oliver
>> >>>
>> >>> --
>> >>> 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/f3e65b25-477d-a780-ceae-eb8dec945f40%40gmail.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/CAO49JtETdyEZtHzG2%2BLGBHyBmKHZPTjLQffozt16GWYb%3DP_htg%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/CE90DAE5-AF7D-452E-BAAB-6DD82A6B0B5A%40gmail.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/CAG%3D_Dut0W%3DJyR48uxTvPpUgZg2vS1nRsAtHREKW%2BGsbjfXRX%3Dw%40mail.gmail.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/8c9149bf-b71b-4184-a280-2280ad1eeb66n%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/CAEot4ow9HkOsO%2BeGqUzcN5TxRf25kjwPtzdNomOR0D7LtcC2gA%40mail.gmail.com.

Re: Connecting to an oauth2 protected API?

[Matt Sicker]

You should look at potentially integrating this plugin into your code:
https://plugins.jenkins.io/oauth-credentials/

On Fri, Jan 22, 2021 at 9:52 AM Michael Carter
 wrote:
>
> I've basically been tasked with "converting to oauth2" for all my API calls.
>
> Can someone point me in the right direction... to a java tools kit that can 
> make it easy to call an oauth protected API service inside my java plugin?
>
> Thanks.
>
> --
> 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/42c25176-9205-434e-b3d2-d18cf66d257cn%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/CAEot4oyDbZ5bXVt5fxLpHnqo_zRYpL5OgRHdmh%3DdAeqoa8Pucg%40mail.gmail.com.

Re: Jenkins 3.x

[Matt Sicker]

That's a good point. I still see people who don't know about pipelines
even though they've been around since Jenkins 2.0 IIRC. The updated UI
is also less well known.

On Fri, Jan 22, 2021 at 9:23 PM Ming Tang  wrote:
>
> I think the release of Jenkins 3.x is very urgent. Let me put forward another 
> very important reason: companies and users are abandoning Jenkins. Jenkins 
> 2.x has a history of 5 years. In the past 5 years, Jenkins 2.x has many major 
> features and incompatible modifications. The obsolescence, update, and 
> requirements for higher versions of Jenkins core require constant upgrading 
> of Jenkins and modification of the configuration. This is in the view of the 
> end user (administrator) of Jenkins, but it is a toss in the view of the 
> leader. Small versions usually mean small changes. For the leaders of Jenkins 
> administrators, Jenkins 2.x is something that hasn't changed a lot for many 
> years, but it requires labor-intensive maintenance and repeated exploration. 
> The minor version upgrade hides the value of the new version of Jenkins! News 
> organizations do not pay attention to minor version updates, and the 
> leadership does not care about minor version updates. Only the Jenkins 
> administrator knows what Jenkins has updated! Enterprises and users have 
> begun to consider abandoning Jenkins! ! We need to let the outside know that 
> Jenkins is undergoing major changes, not that it has not released a major 
> version for 5 years.
>
> 在2020年12月3日星期四 UTC+8 上午2:02:20 写道：
>>
>> Interesting, first I had seen Revapi. Would be worth checking whether
>> it can replace japicmp in `jenkinsci/jenkins`, which I introduced as
>> part of JEP-227 but had to patch in order to properly handle
>> POM/classpath changes (and unfortunately that patch remains
>> unevaluated).
>
> --
> 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/9d0ad61c-e63e-47d5-9034-1b648e002198n%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/CAEot4oyMa0SvOBBVSOpiL0Jpkk%2B7%2BC4JtqijiYxAvZSM1TygRw%40mail.gmail.com.

Re: Releasing JCasC support for ghprb-plugin

[Matt Sicker]

I'd prefer if this plugin has an actual maintainer. Otherwise, this
also seems like false advertising that the plugin is still supported
by anyone.

On Wed, Jan 6, 2021 at 10:45 AM 'Gavin Mogan' via Jenkins Developers
 wrote:
>
> If you do a release and there are new bugs are you going to handle them?
>
> Without a maintainer it seems like deploying to prod and not monitoring 
> afterwards.
>
> Gavin
>
> On Wed., Jan. 6, 2021, 6:03 a.m. Marky Jackson,  
> wrote:
>>
>> Same, no objections
>>
>> On Jan 6, 2021, at 6:01 AM, Mark Waite  wrote:
>>
>> 
>> No objections from me.
>>
>> On Wed, Jan 6, 2021 at 2:18 AM Oliver Gondža  wrote:
>>>
>>> Hey, there is a long anticipated feature merged in in the plugin[1][2],
>>> but no maintainer appears to be active to cut a release.
>>>
>>> Are there any objections if I step in a do the release?
>>>
>>> [1] https://github.com/jenkinsci/ghprb-plugin/pull/731
>>> [2] https://issues.jenkins-ci.org/browse/JENKINS-55793
>>> --
>>> oliver
>>>
>>> --
>>> 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/f3e65b25-477d-a780-ceae-eb8dec945f40%40gmail.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/CAO49JtETdyEZtHzG2%2BLGBHyBmKHZPTjLQffozt16GWYb%3DP_htg%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/CE90DAE5-AF7D-452E-BAAB-6DD82A6B0B5A%40gmail.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/CAG%3D_Dut0W%3DJyR48uxTvPpUgZg2vS1nRsAtHREKW%2BGsbjfXRX%3Dw%40mail.gmail.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/CAEot4ozOt59wmaLzWCSyS0hST3xANL%2By9cKCTyZ5sYNXYuX9Wg%40mail.gmail.com.

Re: Return a map/value from a step in a pipeline build

[Matt Sicker]

Indeed, if you're modifying run actions inside a pipeline thing like
in credentials-binding, you need to ensure to merge existing actions
into the new one however it makes sense for that usage. If it doesn't
make sense to do so, then attaching actions is likely too coarse for
your use case.

On Thu, Dec 10, 2020 at 10:51 AM Jesse Glick  wrote:
>
> On Thu, Dec 10, 2020 at 4:26 AM Lakshmi Narasimhan
>  wrote:
> > I am trying to understand  how I can leverage SimpleBuildWrapper to be able 
> > to work in different job types.
>
> `SimpleBuildWrapper` is specifically designed (in fact restricted) to
> be compatible with traditional job types as well as Pipeline. Please
> read
>
> https://www.jenkins.io/doc/developer/plugin-development/pipeline-integration/
>
> > step ([$class: "MyStepClass"...]  // This performs some action and has the 
> > return values (name-value pairs)
>
> No, you just define a `@Symbol` and that becomes a Pipeline step name.
>
> > I am tending towards  doing this through an intermediate action
>
> `Run.addAction` affects the build globally, which will lead to
> incorrect or confused results if a Pipeline build uses the wrapper
> multiple times, or does work after the block ends, or (especially) if
> the wrapper is run in parallel. So avoid that.
>
> From a `SimpleBuildWrapper` you can communicate information to nested
> steps using simple (textual) environment variables. If you need to
> communicate richer substructure contextually, you will need to use
> `Step` and check the documentation on `BodyInvoker`.
>
> --
> 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/CANfRfr0o1KLdpNpWVarYoycm5v_hKBofXeVyyoYcTiN8JeRQDQ%40mail.gmail.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/CAEot4owXfGvTC27mjSxC7e_SOL%3DgkYnjevzKB%3DUjeg9Afvef-g%40mail.gmail.com.

Re: Core Baseline Java8 -> Java11?

[Matt Sicker]

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 
> 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 
> 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.
> &g

Re: Core Baseline Java8 -> Java11?

[Matt Sicker]

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  
>> 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  
>> >> 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 
>&

Re: Core Baseline Java8 -> Java11?

[Matt Sicker]

FWIW, whenever I need to set up some sort of integration testing with
Jenkins, I'm usually using Java 11 as it's what's most easily
installable on Linux and Windows. The only incompatibilities I've come
across so far have been old fixed issues in maven-hpi-plugin when
trying to compile old plugins.

On Sat, Dec 5, 2020 at 1:22 AM Oleg Nenashev  wrote:
>
> Last time I was testing cross-JVM mode (Java 8 agents + Java 11 controller), 
> it passed smoke tests I had. I am pretty sure there are class serialization 
> edge cases, but it should be solvable.
>
> As Jesse said, the main concern is about warnings being printed here and 
> there. JVM access and illegal reflective access mostly. On 2.263 there are a 
> few hundreds being printed, mostly from XStream and from Pipeline internals. 
> XStream unforking should help.
>
> Best regards,
> Oleg
>
>
> On Sat, Dec 5, 2020, 03:03 'Gavin Mogan' via Jenkins Developers 
>  wrote:
>>
>> I know there has been few/minor reports on IRC/gitter about agents having 
>> issues in 11 that were fixed going back to 8. I tried to encourage them to 
>> report issues, but I'm not sure they did.
>>
>> On Fri, Dec 4, 2020 at 1:50 PM Jesse Glick  wrote:
>>>
>>> I am definitely opposed to trying to continue to “support” 8 if and
>>> when we use 11 as a baseline for core. Let us be clear about what we
>>> require and test against, so that we do not have a combinatorial
>>> explosion of platforms. Plugins can be switched to run 11 in CI over
>>> the course of a few months, and upgraded to `-source 11` as soon as
>>> they decide to pick a new `jenkins.version`. (There is a bit of
>>> infrastructure work needed for all this.)
>>>
>>> Basing decisions on what portion of users currently run on 11 seems
>>> circular. The interesting question is what portion of users _cannot_
>>> run 11, for example due to some corporate mandate, and so would
>>> actually refuse to upgrade Jenkins. This is harder to measure, of
>>> course, but we can try.
>>>
>>> I do not _think_ there is any problem running an agent on 11 while the
>>> controller is on 8, or vice-versa, but it bears testing.
>>>
>>> Last I tried using 11, there was still a lot of polish missing. The
>>> agent printed a bunch of warnings about use of JDK internal classes.
>>> IMO we should not be promoting use of a 9+ version until we can be
>>> assured that no such warnings are printed when using testable features
>>> of core or common plugins, perhaps by running `plugin-compat-tester`
>>> and `acceptance-test-harness` with a JVM flag to turn on strict mode.
>>> (JEP-228 means we are now on a version of XStream which at least
>>> claims to get this right!)
>>>
>>> Note that AdoptOpenJDK intends to support Java 8 for considerably
>>> _longer_ than 11. And we should be at least testing against newer
>>> versions including previews of 17 when they become available, lest we
>>> move to 11 just as it is becoming obsolete.
>>>
>>> --
>>> 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/CANfRfr0C3GO1SiAYzhN2Zjp6x6_nk6t03LW8n_1kim5xMC4ZDQ%40mail.gmail.com.
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/jenkinsci-dev/nEw4TLDcZLw/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CAG%3D_DuuJ30tFYmFu2wRiU5n2%3DRpcrZHgivLEfDfrTQ3g1i5mrQ%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/CAPfivLCiCTS%2B%2BQxAnuDc4_A021EwoNJ%3DMzAjmNGgfbJL5mF17Q%40mail.gmail.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/CAEot4ozG8-OqwfhUvRtnmtiKA9anyDjX5R8xBLVg1_d%3Dfrn7cA%40mail.gmail.com.

Re: Core Baseline Java8 -> Java11?

[Matt Sicker]

 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/6BBCBBDB-FBCE-4210-BE0C-F3DA73777D8B%40gmail.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/692ae683-264b-47bd-bb8b-52c89de574bbn%40googlegroups.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/CAH-3Bic%3D266-%3DZPnSh6MAZ%2B8rtduOoo8fyVqZYDG8CW62%3DQAqQ%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/491F0F5C-CE94-458A-AC65-1929B159D58C%40gmail.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/5150b925-4f70-4de7-8bd6-793c5cfc1623n%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/CAEot4owdez8tPzyKSD-90e-uHgkMu2hAhT_UvwkT1%3DUNG9WTJg%40mail.gmail.com.

Re: Jenkins 3.x

[Matt Sicker]

Revapi is another great tool; we use it in Log4j2 nowadays after a
couple releases accidentally introduced minor binary compatibility
issues (but source compatible) in the logging API.

On Tue, Dec 1, 2020 at 7:15 AM Ullrich Hafner  wrote:
>
>
> Am 30.11.2020 um 22:51 schrieb Matt Sicker :
>
> I think Jesse has articulated my own feelings fairly well here. I will
> note that OSGi has some useful tooling [1] and semantics related to
> semantic versioning, generic Java plugins/modules/components, and some
> other well-explored areas related to compatibility which our own
> plugin ClassLoader only scratches the surface of.
>
> [1]: https://bnd.bndtools.org/commands/baseline.html
> https://bnd.bndtools.org/commands/diff.html
>
>
> I’m using https://revapi.org/l in my plugins to detect incompatible API 
> changes before a release. It seems to work quite similar and has support for 
> Jenkins JPI files now. The included maven plugin warns me if I try to remove 
> a method that actually might be used by a depending plugin.
>
> On Mon, Nov 30, 2020 at 3:45 PM Jesse Glick  wrote:
>
>
> I do not think switching to a 3.x version number accomplishes much of
> anything (even if we had done so several weeks ago, when the big
> changes were landing). I would much rather see Jenkins switch to
> either a date-based scheme, or just some opaque incrementing number
> like we have but without the meaningless `2.` prefix. Jenkins releases
> break compatibility for someone, somehow, all the time; a number tells
> you nothing about whether _you_ will be affected. We need to publish
> clear, concise upgrade guides; encourage users to make backups or use
> a config-as-code workflow; and of course try as hard as we can to not
> break compatibility to begin with! In the case of JEP-227 & JEP-228
> there have already been extensive plugin fixes released and few users
> should actually be affected. Tables-to-divs has apparently caused more
> regressions, but these should all be fixable long before the LTS.
>
> In theory SemVer could be useful for libraries. In practice it seems
> like a false promise to me. It is your tests which will tell you if an
> upgrade is compatible, not some upstream maintainer’s fantasy.
> Dependabot actually _keeps score_ and tells you whether a given update
> broke CI for other people, which seems like far more valuable
> information.
>
> --
> 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/CANfRfr0JZtW1x17eeUSVQzfAJgck08jVnfZ0%3DN4reZZ7RYx6fA%40mail.gmail.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/CAEot4oz-kiQLAUrU3RQYr3en%2B%3DCAKsA1wOpwpHbkGk04sCq3tA%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/96F88098-40ED-4002-869B-2842D5E26746%40gmail.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/CAEot4oztA9bv%3DUfXibXcZr-zCEjMWEC6FuutdCWSa3gABfo%2BdA%40mail.gmail.com.

Re: Jenkins 3.x

[Matt Sicker]

I think Jesse has articulated my own feelings fairly well here. I will
note that OSGi has some useful tooling [1] and semantics related to
semantic versioning, generic Java plugins/modules/components, and some
other well-explored areas related to compatibility which our own
plugin ClassLoader only scratches the surface of.

[1]: https://bnd.bndtools.org/commands/baseline.html
https://bnd.bndtools.org/commands/diff.html

On Mon, Nov 30, 2020 at 3:45 PM Jesse Glick  wrote:
>
> I do not think switching to a 3.x version number accomplishes much of
> anything (even if we had done so several weeks ago, when the big
> changes were landing). I would much rather see Jenkins switch to
> either a date-based scheme, or just some opaque incrementing number
> like we have but without the meaningless `2.` prefix. Jenkins releases
> break compatibility for someone, somehow, all the time; a number tells
> you nothing about whether _you_ will be affected. We need to publish
> clear, concise upgrade guides; encourage users to make backups or use
> a config-as-code workflow; and of course try as hard as we can to not
> break compatibility to begin with! In the case of JEP-227 & JEP-228
> there have already been extensive plugin fixes released and few users
> should actually be affected. Tables-to-divs has apparently caused more
> regressions, but these should all be fixable long before the LTS.
>
> In theory SemVer could be useful for libraries. In practice it seems
> like a false promise to me. It is your tests which will tell you if an
> upgrade is compatible, not some upstream maintainer’s fantasy.
> Dependabot actually _keeps score_ and tells you whether a given update
> broke CI for other people, which seems like far more valuable
> information.
>
> --
> 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/CANfRfr0JZtW1x17eeUSVQzfAJgck08jVnfZ0%3DN4reZZ7RYx6fA%40mail.gmail.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/CAEot4oz-kiQLAUrU3RQYr3en%2B%3DCAKsA1wOpwpHbkGk04sCq3tA%40mail.gmail.com.

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

[Matt Sicker]

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-dev+unsubscr...@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/CAEot4oycQMFRHz%2BirV69b%3DJKWG%3DLM25r5jsUAOkfzb5DHR%2BABg%40mail.gmail.com.

Re: Jenkins BOM and base Jenkins version

[Matt Sicker]

Whichever LTS version you use should probably be kept up to date with
the latest security patch version for that LTS. No preference from me
on 2.204.x versus 2.222.x.

On Mon, Nov 23, 2020 at 11:24 AM Mark Waite  wrote:
>
> The git plugin currently requires Jenkins 2.204.1 and uses the plugin bom to 
> simplify dependency management.  I like the results of that simplification 
> very much.
>
> A dependabot pull request has proposed to update the git plugin use of 
> bom-2.204.x from 17 to 18.  However, the build of that proposed update fails 
> because one of the dependent plugins requires Jenkins 2.204.6 rather than 
> 2.204.1.
>
> I believe my options are:
>
> Update the  minimum Jenkins version required by the git plugin from 2.204.1 
> to 2.222.1 to retain the benefits of the plugin bom and move the minimum 
> version forward to one of the currently recommended minimum versions - few 
> users affected, reduces maintenance by reducing number of older Jenkins 
> versions allowed to use the plugin
> Update the minimum Jenkins version required by the git plugin from 2.204.1 to 
> 2.204.6 to retain the benefits of the plugin bom with least chance of 
> disrupting existing users (though the number of users of Jenkins 2.204.x 
> using newer versions of the git plugin is quite small based on 
> stats.jenkins.io - even fewer users affected, retains benefits of the bom
> Close the pull request updating bom-2.204.x from 17 to 18 and make that 
> change at some other time - suspends benefits of plugin bom until the next 
> time the Jenkins minimum version is incremented
>
> I prefer the first option (update from 2.204.1 to 2.222.1 as minimum 
> version).  Are there reasons I should consider something other than that?
>
> 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/f61faad1-4f67-4920-b68a-b75b4b124d64n%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/CAEot4oxW8RMu0ZyWYEdkjOZ5yARaSyvmSuEVq_4pfZtxb9JD6A%40mail.gmail.com.

Re: NTLM Authentication

[Matt Sicker]

The Kerberos SSO plugin is one generic way. The Active Directory plugin
requires an AD server, but it's similar tech. I haven't used it before, but
https://plugins.jenkins.io/NegotiateSSO/ is another option.

On Wed, Nov 18, 2020 at 8:02 AM Chris Bahonda 
wrote:

> Thanks guys,
>
> I am actually referring to NTLMv2, my mistake I wasn't concise enough.
>
>
> On Tue, Nov 17, 2020 at 3:04 PM Robert Sandell 
> wrote:
>
>> https://plugins.jenkins.io/kerberos-sso/
>>
>> /B
>>
>> Den tis 17 nov. 2020 kl 12:50 skrev Ivan Fernandez Calvo <
>> kuisathave...@gmail.com>:
>>
>>> I guess that it is because nobody has an interest in developing a plugin
>>> for NTLM authentication because there are better ways to authenticate
>>> against windows, for example, Active directory that has support for
>>> authentication and authorization, also NTLM is pretty old and insecure. If
>>> after all that you continue thinking to use it you can use an Apache HTTP
>>> server in front of Jenkins and configure there the NTLM authentication.
>>>
>>> https://en.wikipedia.org/wiki/NT_LAN_Manage
>>> https://docs.moodle.org/310/en/NTLM_authentication#APACHE_Configuration
>>>
>>> https://plugins.jenkins.io/active-directory/
>>>
>>> El lunes, 16 de noviembre de 2020 a las 16:55:36 UTC+1,
>>> chrisb...@gmail.com escribió:
>>>
>>>>
>>>> Hello everyone,
>>>>
>>>> I'd like to know why Jenkins does not consider NTLM authentication on
>>>> Windows.
>>>>
>>>> Many thanks.
>>>>
>>> --
>>> 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/d6fde3a9-ca08-48f1-ae77-2fbdc31b10e6n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/d6fde3a9-ca08-48f1-ae77-2fbdc31b10e6n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> *Robert Sandell*
>> Senior Software Engineer
>> CloudBees, Inc.
>> <http://www.cloudbees.com>
>> E: rsand...@cloudbees.com
>> Twitter: robert_sandell
>>
>> --
>> 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/CALzHZS2NjLWa_cFc8Sx0worVxQmp1fLfcWFZP%3DqjqOLKG90A7w%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2NjLWa_cFc8Sx0worVxQmp1fLfcWFZP%3DqjqOLKG90A7w%40mail.gmail.com?utm_medium=email_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/CAHFeqYSeEf56F1KYe%3DLo%3D%2BvYb%2BKyyKdarjx09ni_hK5mRu1Xew%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAHFeqYSeEf56F1KYe%3DLo%3D%2BvYb%2BKyyKdarjx09ni_hK5mRu1Xew%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAEot4ozupzzB7HPoj%3DMWLxrRge5knPRJd1_JXYDvKsSQoaiuKg%40mail.gmail.com.

Re: Pullrequest for jenkinsci/trilead-ssh2 - who can help out

[Matt Sicker]

Cross-posting here as well: we're currently looking at deprecating
trilead-ssh2 by replacing it with a maintained SSH library. Though I
do wonder if we will need a trilead-ssh2 compatibility bridge to more
easily upgrade plugins to use the updated library without needing to
update their code.

On Fri, Nov 13, 2020 at 3:05 AM mike  wrote:
>
>
> Hi,
>
> I have created a quite large commit for new kex algorithms.
> Who can assist in review and commit it to repo?
>
> br,
>
> //mike
>
> --
> 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/bb14b771-c4f2-4596-b7b4-59bac967adben%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/CAEot4ozW5waRhseuxhhUg8-8s8bJt8nu6VTDi%3DAWdMvjhp3CPA%40mail.gmail.com.

Re: JEP-227 & JEP-228: request for assistance

[Matt Sicker]

Paying down technical debt is always cause for celebration. Kudos!

On Fri, Nov 6, 2020 at 3:51 PM Basil Crow  wrote:
>
> On Fri, Nov 6, 2020 at 1:38 PM Jesse Glick  wrote:
> >
> > Merged toward 2.266.
>
> Nice work on some long-needed changes. As a community member I would
> like to thank your employer for funding this work and to thank you for
> implementing it.
>
> --
> 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/CAFwNDjpdzMaZwiWzq22JxMRpKimNLXxW5Q8_CUO_%3DzvHtowQ4A%40mail.gmail.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/CAEot4ox2YQQx6Az0EpYP7jnW7F6nbpCU9CuzJMv7oEfXQ8EXeQ%40mail.gmail.com.

Re: Log4j2 logger not working for jenkins plugin

[Matt Sicker]

Chances are there's some slf4j dependency interfering. Jenkins uses a
bridge for that into the java.util.logging API from what I've seen.

On Wed, Oct 21, 2020 at 11:39 AM Tim Jacomb  wrote:
>
> Can you post a link to the code? Or at least a new plugin generated off of 
> archetypes where it doesn’t work for you?
>
> Thanks
> Tim
>
> On Wed, 21 Oct 2020 at 17:19, varun...@gmail.com  
> wrote:
>>
>> Hi Matt,
>> all dependencies are as below:
>>
>> 
>> 
>> org.apache.httpcomponents
>> httpclient
>> 4.5.2
>> 
>>
>> 
>> com.google.code.gson
>> gson
>> 2.6.2
>> 
>> 
>> org.jenkins-ci.plugins
>> job-dsl
>> 1.41
>> true
>> 
>> 
>> org.jenkins-ci.plugins
>> structs
>> 1.6
>> 
>> 
>> org.mockito
>> mockito-all
>> 1.10.19
>> test
>> 
>> 
>> commons-beanutils
>> commons-beanutils
>> 1.8.3
>> test
>> 
>> 
>> commons-net
>> commons-net
>> 3.6
>> 
>> 
>> junit
>> junit
>> test
>> 
>> 
>> org.powermock
>> powermock-module-junit4
>> 1.6.1
>> test
>> 
>> 
>> org.powermock
>> powermock-api-mockito
>> 1.6.1
>> test
>> 
>> 
>> 
>> org.jetbrains
>> annotations-java5
>> RELEASE
>> compile
>> 
>> 
>> org.apache.logging.log4j
>> log4j-api
>> 2.11.0
>> 
>> 
>> org.apache.logging.log4j
>> log4j-core
>> 2.11.0
>> 
>> 
>> org.apache.logging.log4j
>> log4j-slf4j-impl
>> 2.11.0
>> 
>>
>> 
>> com.fasterxml.jackson.core
>> jackson-core
>> 2.6.3
>> 
>> 
>> com.fasterxml.jackson.core
>> jackson-databind
>> 2.6.3
>> 
>>
>>
>> 
>> 
>> 
>> repo.jenkins-ci.org
>> https://repo.jenkins-ci.org/public/
>> 
>> 
>> 
>> 
>> repo.jenkins-ci.org
>> https://repo.jenkins-ci.org/public/
>> 
>> 
>> 
>>
>> On Wednesday, 21 October 2020 at 21:42:11 UTC+5:30 varun...@gmail.com wrote:
>>>
>>> Hi,
>>>
>>> Below are details of maven dependency  which i have included
>>> 
>>> org.apache.logging.log4j
>>> log4j-api
>>> 2.11.0
>>> 
>>> 
>>> org.apache.logging.log4j
>>> log4j-core
>>> 2.11.0
>>> 
>>> 
>>> org.apache.logging.log4j
>>> log4j-slf4j-impl
>>> 2.11.0
>>> 
>>>
>>>
>>> Thanks,
>>> Varun
>>> On Wednesday, 21 October 2020 at 21:14:49 UTC+5:30 msi...@cloudbees.com 
>>> wrote:
>>>>
>>>> Do you also have log4j-core in your plugin? What other dependencies do you 
>>>> have?
>>>>
>>>> On Wed, Oct 21, 2020 at 9:48 AM varun...@gmail.com
>>>>  wrote:
>>>> >
>>>> > Hi Matt,
>>>> >
>>>> > Thanks for reply.
>>>> > I am running mvn hpi:run for running jenkins locally. so it includes 
>>>> > only jenkins standard plugin. so no audit-log plugin tool , i am using.
>>>> > It creates log file on local machine but no log is written.
>>>> > but It successfully logs on jenkins system log.
>>>> > I have also included an appender by providing TaskListener.getLogger() 
>>>> > printStream as we can add output stream as appender.
>>>> > to log on jenkins console but it does not work
>>>> >
>>>> > Thanks,
>>>> > Varun
>>>> > On Wednesday, 21 October 2020 at 19:52:23 UTC+5:30 msi...@cloudbees.com 
>>>> > wrote:
>>>> >>
>>>> >> Are you using the audit-log plugin, too? That specifies a log4j2
>>>> >> config which probably overrides anything you're using.
>>>> >>
>>>> >> On Wed, Oct 21, 2020 at 9:04 AM varun...@gmail.com
>>>> >>  wrote:
>>>> >> >
>>>> >> > Hi,
>>>> >> >
>>>> >> > I am trying to use Log4j2 for looging in jenkins plugin , as it 
>>>> >> > includes some jar file,
>>>> >> > which uses log4j2 for logging.
>>>> >> > when I independently run jar, logging is working fine.
>>>> >> > But when I include jar in jenkins Plugin, it is not logging any log.
>>>> >> > What 

Re: Log4j2 logger not working for jenkins plugin

[Matt Sicker]

Do you also have log4j-core in your plugin? What other dependencies do you have?

On Wed, Oct 21, 2020 at 9:48 AM varun...@gmail.com
 wrote:
>
> Hi Matt,
>
> Thanks for reply.
> I am running mvn hpi:run for running jenkins locally. so it includes only 
> jenkins standard plugin. so no audit-log plugin tool , i am using.
> It creates log file on local machine but no log is written.
>  but It successfully logs on jenkins system log.
> I have also included an appender by providing TaskListener.getLogger() 
> printStream as we can add output stream as appender.
> to log on jenkins console but it does not work
>
> Thanks,
> Varun
> On Wednesday, 21 October 2020 at 19:52:23 UTC+5:30 msi...@cloudbees.com wrote:
>>
>> Are you using the audit-log plugin, too? That specifies a log4j2
>> config which probably overrides anything you're using.
>>
>> On Wed, Oct 21, 2020 at 9:04 AM varun...@gmail.com
>>  wrote:
>> >
>> > Hi,
>> >
>> > I am trying to use Log4j2 for looging in jenkins plugin , as it includes 
>> > some jar file,
>> > which uses log4j2 for logging.
>> > when I independently run jar, logging is working fine.
>> > But when I include jar in jenkins Plugin, it is not logging any log.
>> > What may be issue, i have also kept log4j2 properties file in resources 
>> > folder, still not able
>> > to log. can anyOne please help me here?
>> >
>> > Thanks,
>> > Varun
>> >
>> > --
>> > 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/97b5066e-c2c3-48a4-b316-12152bf390cen%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/e67c56db-a8d8-4163-8970-dea7bf1bc59en%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/CAEot4oywr3pZG74T0mWeUn1N1e3wK-VGOCjXwNps1Oq269UdEw%40mail.gmail.com.

Re: Log4j2 logger not working for jenkins plugin

[Matt Sicker]

Are you using the audit-log plugin, too? That specifies a log4j2
config which probably overrides anything you're using.

On Wed, Oct 21, 2020 at 9:04 AM varun...@gmail.com
 wrote:
>
> Hi,
>
> I am trying to use Log4j2 for looging in jenkins plugin , as it includes some 
> jar file,
> which uses log4j2 for logging.
> when I independently run jar, logging is working fine.
> But when I include jar in jenkins Plugin, it is not logging any log.
> What may be issue, i have also kept log4j2 properties file in resources 
> folder, still not able
> to log. can anyOne please help me here?
>
> Thanks,
> Varun
>
> --
> 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/97b5066e-c2c3-48a4-b316-12152bf390cen%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/CAEot4oxiXtyOJ42dL1X3x5S2YyB%2BuFpx7PYkmihmGewu4ohrkw%40mail.gmail.com.

Re: Availability of Oliver Gondža in late 2020 and onward

[Matt Sicker]

Thanks for all the help! Have fun with the new babies! I'm sure they
require more maintenance than our infra ;)

On Tue, Oct 20, 2020 at 10:48 AM Raul Arabaolaza
 wrote:
>
> All the best with your new responsibilities as a father of twins Oliver.I am 
> sure you will do great, I have not worked a lot with you but it has been 
> always a pleasure when I have done it.
>
> Enjoy!
>
> On Tuesday, October 20, 2020 at 3:50:46 PM UTC+2 Mark Waite wrote:
>>
>> On Tue, Oct 20, 2020 at 2:24 AM Oliver Gondža  wrote:
>>>
>>> Hey Folks, After all those years with the project doing my best here and
>>> there (Release and LTS officer, reviewer and maintainer of a number of
>>> components), I have chosen to step back a bit. Partially as my focus is
>>> shifting away slowly, but mostly to direct my attention to my family and
>>> the twins expected to be born in a couple of weeks.
>>
>>
>> Thanks so much for your contributions to the Jenkins project as release 
>> officer and as leader and maintainer of the Jenkins acceptance test harness. 
>>  Your work has been such a help to Jenkins users around the world.
>>
>> All the best with the impending birth of twins.  What an exciting addition 
>> to your family!  Children teach us so many things and twins seem to teach us 
>> even faster.  Truly best wishes for you and your family with the exciting 
>> new additions.
>>
>> 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/6c1ac33d-eedc-4716-85f8-20c2b34737e4n%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/CAEot4oyJ_NJgNqBqtb7kE6SEA34hSGdd8OnBZSPtG94f5-NnWA%40mail.gmail.com.

Re: [PROPOSAL] Unforking XStream

[Matt Sicker]

+1 to un-forking. That's also in general to make maintenance easier
for anything forked.

On Mon, Oct 12, 2020 at 5:22 PM Marky Jackson  wrote:
>
> Non-binding +1
>
> > On Oct 12, 2020, at 2:07 PM, Jesse Glick  wrote:
> >
> > See https://github.com/jenkinsci/jep/pull/309 for details. The core PR
> > has been prepared, along with PRs to a number of plugins which require
> > modification to be compatible. (All of those PRs can and should be
> > merged & released in advance of the core change.) I am hoping to get
> > this merged after the next LTS baseline has been cut, if there are no
> > objections.
> >
> > --
> > 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/CANfRfr1P2izJbsRE%2BCyA8NQgWkdTFPyaBZsXTTywKpeSNBafLw%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/8524AD23-57A3-41E0-940F-842553CFF285%40gmail.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/CAEot4ozsvvZWurEz_5_ri-aqUxy1reU6kKAreg0uLzgOF%3D5cVA%40mail.gmail.com.

Re: Request to adopt a plugin

[Matt Sicker]

I believe the label was re-added because there were no active
maintainers anymore except for some security issues being patched
(orthogonal to the maintenance of the plugin).

On Fri, Oct 2, 2020 at 8:41 AM Oleg Nenashev  wrote:
>
> Hi all,
>
> There might be some confusion. According to the commit history, the plugin is 
> actively maintained now: 
> https://github.com/jenkinsci/ec2-plugin/commits/master . Last substantial 
> merge was 2 weeks ago . Ramon Leon has took ownership 5 months ago according 
> to https://github.com/jenkins-infra/repository-permissions-updater/pull/1533 
> , and then another maintainer joined on Aug 25: 
> https://groups.google.com/g/jenkinsci-dev/c/alJpUbtKYh0/m/4QpxyYHoBQAJ
>
> I suspect that the maintainers just forgot to remove the adopt-this-plugin 
> GitHub topic. Before we proceed with ownership transfer, I think we need 
> explicit confrmation from Ramon Leon and Martin Frobles.
>
> Best regards,
> Oleg
>
> On Friday, October 2, 2020 at 12:04:04 AM UTC+2 himansh...@gmail.com wrote:
>>
>> Thank you Mark.
>>
>> No we have not submitted any pull requests yet. Surely we can start with 
>> them.
>>
>> Thanks again. Looking forward to contribute to the Jenkins community.
>>
>> Regards,
>> Himanshu
>>
>> On Thursday, October 1, 2020 at 12:21:25 PM UTC-7 Mark Waite wrote:
>>>
>>> Thanks to you and Deepika for your willingness to help.  That's great!
>>>
>>> We usually prefer that those adopting a plugin have submitted pull requests 
>>> to the plugin prior to adopting it.  Have you previously submitted pull 
>>> requests to the plugin?  If not, would you be willing to start with pull 
>>> requests?
>>>
>>> To others, I've worked with Himanshu and Deepika on Jenkins training.  I'm 
>>> +1 to allow them to adopt the plugin but would love to have support from 
>>> others that are willing to assist them while they work on the plugin.
>>>
>>> On Thu, Oct 1, 2020 at 1:17 PM Himanshu Gautam  wrote:
>>>>
>>>> Hello,
>>>>
>>>> We recognize the value provided by the Amazon EC2 plugin. Since it is up 
>>>> for adoption, We love to help maintain it.
>>>>
>>>> Here is the link to the plugin: https://plugins.jenkins.io/ec2/
>>>>
>>>> Our GitHub usernames:
>>>> https://github.com/hgautam
>>>> https://github.com/dhgautam
>>>>
>>>> Our Jenkins infrastructure IDs:
>>>> hgautam
>>>> dgautam
>>>>
>>>>
>>>> Regards,
>>>> Himanshu Gautam and Deepika Gautam
>>>>
>>>> --
>>>> 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/ef3e27a7-7153-40c5-aec6-fc95373c7175n%40googlegroups.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/dc03b3e5-bc5d-4592-9765-024daeda9d3cn%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/CAEot4oyCEJ8BaFoLzK3Brx64jSX1dq%3D31eR3v5BFy-GZt9hijQ%40mail.gmail.com.

Re: Hacktoberfest: Plugin Development Lessons Learned & Best Practices

[Matt Sicker]

One thing I noticed pretty early on that's not super consistent
elsewhere is using serialization proxies for storing and loading
config data rather than relying on the autogenerated XML from your
class structure. It's a best practice for real serializable classes
(even though Jenkins/XStream support non-serializable classes, too),
and it helps avoid JEP-200-related errors or the need to attempt to
request ConcurrentHashMap.newKeySet() to be added to the allow list
(I've done that before and almost re-requested in multiple times;
serialization proxy is the way to go).

There's a little bit of info documented about making sure to use the
Secret class for storing sensitive data rather than String or similar.
For credentials management in general, I highly recommend linking or
integrating content from the credentials manual, specifically
https://github.com/jenkinsci/credentials-plugin/blob/master/docs/consumer.adoc

There are bound to be a collection of gotchas that would be great to
document in a central location. For example, Stapler databinding
involving a collection of items will not allow the collection to be
cleared unless you explicitly reset the collections before binding the
JSON like in 
https://github.com/jenkinsci/extended-security-settings-plugin/blob/f2a07b0dbb043ee16cd8d67deca754bb50b6c340/src/main/java/io/jenkins/plugins/extendedsecuritysettings/ExtendedSecuritySettings.java#L90-L95

For testing configurations, there's the JenkinsRule.configRoundtrip
family of functions:
https://javadoc.jenkins.io/component/jenkins-test-harness/org/jvnet/hudson/test/JenkinsRule.html#configRoundtrip--

See also configuration-as-code:
https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/docs/PLUGINS.md

On Fri, Aug 28, 2020 at 1:12 PM steven...@gmail.com
 wrote:
>
> Hello all!
>
> In preparation for Hacktoberfest, the Pipeline Authoring SIG was discussing 
> good first issues and opportunities for improvement.  The topic of 
> documentation came up, specifically Plugin Developer documentation.
>
> If you've written a plugin before, there many lessons learned and best 
> practices that would have been great to know up front.
>
> I'm starting this thread to hear from you all:
>
> What lessons have you learned while developing a Jenkins plugin that you wish 
> you knew up front?
>
> Some high level topics to help kickstart the conversation:
>
> Unit Testing
>
> Jenkins Test Harness
> Specific examples testing particular use cases
> How to mock a remote source code repository
> Validating configurations in the UI work as expected
>
> Plugin Development Lifecycle
>
> Productivity tips for how to simplify plugin development
>
> Backwards maintainability best practices
> Ecosystem compatibility best practices
>
>
> We would love to hear examples of topics that could be good first issues for 
> folks to help build out the plugin developer document.
>
> Thank you for your help!
>
> --
> 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/df7c8aa0-2795-4e00-8856-d6656d110182n%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/CAEot4ozBOa%2BmQpjWRTCfzXNSe8N5y-NfhMz_Uw%3D8pd0gZmr_Kg%40mail.gmail.com.

Re: Move stable/jenkins kubernetes chart to jenkinci GitHub org

[Matt Sicker]

Based on repositories like https://github.com/jenkinsci/docker and
https://github.com/jenkinsci/kubernetes-operator I'd imagine that
jenkinsci is the perfect organization for this!

On Mon, Aug 24, 2020 at 2:06 PM Torsten Walter  wrote:
>
> Hi together,
>
> Maybe some of you have used the stable/jenkins helm chart to install our 
> favorite CI tool in Kubernetes.
>
> At the moment is it hosted in the https://github.com/helm/charts repository, 
> which is already in maintenance mode and all charts from there will be 
> de-listed from the Helm Hub. And on Nov 13, 2020 the support for that 
> repository will formally end, and the repo will be marked obsolete
>
> Therefor chart maintainers are currently moving charts to different 
> organizations.
>
> I am one of the maintainers of the stable/jenkins chart and I am proposing to 
> move it to https://github.com/jenkinsci. I find that to be the most fitting 
> place as most of the jenkins plugins also reside there. It could help to 
> continue supporting it in the future.
>
> Some data about the helm chart. Unfortunately, there seems to be no usage 
> statistics to tell how many people are using it or how many downloads it has.
> I checked its git history and noticed that it's first git commit is already 
> from September 2016 and that it received over 300 contributions from 181 
> contributors since then. An older version of it is even used in 
> jenkins-x-platfrom.
>
> How could a migration look like? Ideally, we could get a repository and admin 
> permission on it so that we could set everything up. I've seen 
> https://www.jenkins.io/doc/developer/publishing/requesting-hosting/, but 
> hosting a helm chart is a bit different than a Jenkins plugin. Also with the 
> recent discussion about forked repositories in GitHub I am not sure if that's 
> still the desired process or if it would be easier to just move a repository 
> to the new org.
>
> So far I prepared a git repository 
> https://github.com/torstenwalter/helm-charts which could either be moved or 
> forked into the jenkinci org. It contains  the whole history of the helm 
> chart. It's using Apache License 2.0, as that was used by the original 
> repository.
> CI is set up using chart-releaser and chart-testing GitHub Actions.
>
> Let me know what you think of it and if a move to jenkinci GitHub org would 
> be ok.
>
> Best regards
> Torsten Walter
>
>
>
>
>
>
> --
> 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/3f16a090-727d-42db-bbce-f39b11944477n%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/CAEot4ozRDfxBdjf%3Di6UGC6aHsXfKomb2GbnQmKVh_GbJJbH%3Dmw%40mail.gmail.com.

Re: Password-like file parameter type?

[Matt Sicker]

User scoped credentials are only available to that user, yes. If you
use the authorize project plugin, you can also allow a build to use a
user's credentials provided that's the user you configured the build
to run as. Otherwise, they're only available through selecting them in
a parameterized build of some sort.

On Fri, Aug 21, 2020 at 6:51 AM Jakub Bocheński
 wrote:
>
> Interesting idea, I can indeed add credentials to a user in  
> JENKINS_URL/user/USERNAME/credentials/store/user/domain/_/
>
> I assume those credentials are only available to the user who uploaded them?
>
> Jakub Bocheński
>
>
> On Thu, Aug 20, 2020 at 6:51 PM 'Gavin Mogan' via Jenkins Developers 
>  wrote:
>>
>> if its not using the credentials system, then what is the difference between 
>> a password and a text parameter?
>>
>> I havn't checked in a while, but at one point credentials could be attached 
>> to a user. Why not do that and let them use that credential id, the the only 
>> thing stored is the id, and its safe and secure and encrypted?
>>
>> Gavin
>>
>> On Thu, Aug 20, 2020 at 7:17 AM Jakub Bocheński  
>> wrote:
>>>
>>> Well, file parameter is not supported for Pipelie at the moment anyhow :)
>>>
>>> But in principle I don't see why it couldn't be kept until the build is 
>>> finished.
>>> I don't mind storing it for some time. The main problems are:
>>>  - after the build is done anybody with view permission can see the 
>>> parameter
>>>  - the file will be stored on disk as long as the build is, I'd like to get 
>>> rid of it earlier
>>>
>>> I guess having an aggressive log rotator policy could limit the impact of 
>>> it, but it would be removing too much.
>>>
>>> > You could _predefine_ secret file credentials and then use a
>>> credentials parameter.
>>>
>>> The whole point is to allow users to upload a certificate, so that won't 
>>> help.
>>>
>>> Jakub Bocheński
>>>
>>>
>>> On Wed, Aug 19, 2020 at 10:03 PM Jesse Glick  wrote:
>>>>
>>>> On Mon, Aug 17, 2020 at 10:10 AM kuba.bo...@gmail.com
>>>>  wrote:
>>>> > My problem with file parameter is that the file is stored in the build 
>>>> > and can be retrieved later.
>>>> > Is there some parameter implementation that would handle files without 
>>>> > making them available later?
>>>>
>>>> I do not think so. Would be especially thorny for Pipeline because
>>>> what is “later”? If you restart Jenkins in the middle of a build and
>>>> it needs the parameter after the restart, what then? What if you
>>>> *Replay* the build?
>>>>
>>>> You could _predefine_ secret file credentials and then use a
>>>> credentials parameter.
>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the 
>>>> Google Groups "Jenkins Developers" group.
>>>> To unsubscribe from this topic, visit 
>>>> https://groups.google.com/d/topic/jenkinsci-dev/pr04Pf-p89U/unsubscribe.
>>>> To unsubscribe from this group and all its topics, 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/CANfRfr27F-wz1%2B5bkR%2Bi2uVy58dHpuwoMw_v-4uZVc1MsUkU%2Bw%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/CAGiELgpeX4PEWaKm06Q4g2v-B%3DJJgnu21XGqahUaN_mMdE_Kxg%40mail.gmail.com.
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/jenkinsci-dev/pr04Pf-p89U/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CAG%3D_DusngUGEtkN9GodgV3dDQJUR0BEjAfp1AuzFTxAaEg28Ag%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/CAGiELgqNSHKZHUg_BFRo19r6Pf-GMyfpay433jCcwCeZOQhHNQ%40mail.gmail.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/CAEot4ox4OeGY7FKq%3DSc4QL%3DDm1k34EKs2vTO%2BPVsMUe%2BEc7A1w%40mail.gmail.com.

Re: What makes Credential Parameter special that it can be used in Bind area?

[Matt Sicker]

More info is in that doc elsewhere by the way such as the guide for
exposing said UI:
https://github.com/jenkinsci/credentials-plugin/blob/master/docs/consumer.adoc#providing-a-ui-form-element-to-let-a-user-select-credentials

On Fri, Aug 21, 2020 at 10:38 AM Matt Sicker  wrote:
>
> As long as the UI in question is calling
> CredentialsProvider.findCredentialsById(), that will automatically
> parse the ${} syntax and replace them with parameter values. At a
> super low level, this works via the following invisible action
> attached to the build:
> https://github.com/jenkinsci/credentials-plugin/blob/master/docs/consumer.adoc#binding-user-supplied-credentials-parameters-to-builds
>
> On Thu, Aug 20, 2020 at 4:29 PM Michael Carter
>  wrote:
> >
> > Was designing my own "Credential Parameter" (basically a clone of the 
> > existing one with some extra on screen filtering) and it wasn't working... 
> > kept getting:
> >
> > ERROR: Could not find credentials entry with ID '${Testing}'
> >
> > In trying to trace the problem... if I use a String parameter.  I get the 
> > same error.  So my question what makes the "Credential Parameter" special 
> > that you can use it's ${name} in the  freestyle jobs Bind area for pulling 
> > passwords to variables?
> >
> > --
> > 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/31918aae-5e4e-46c8-ae39-6e80363d37a3n%40googlegroups.com.
>
>
>
> --
> Matt Sicker
> Senior Software Engineer, CloudBees



-- 
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/CAEot4oxGE6vcSt93TTOekwv5F%2B9oPkvGOFnRY3yTvZG7zCJMow%40mail.gmail.com.

Re: What makes Credential Parameter special that it can be used in Bind area?

[Matt Sicker]

As long as the UI in question is calling
CredentialsProvider.findCredentialsById(), that will automatically
parse the ${} syntax and replace them with parameter values. At a
super low level, this works via the following invisible action
attached to the build:
https://github.com/jenkinsci/credentials-plugin/blob/master/docs/consumer.adoc#binding-user-supplied-credentials-parameters-to-builds

On Thu, Aug 20, 2020 at 4:29 PM Michael Carter
 wrote:
>
> Was designing my own "Credential Parameter" (basically a clone of the 
> existing one with some extra on screen filtering) and it wasn't working... 
> kept getting:
>
> ERROR: Could not find credentials entry with ID '${Testing}'
>
> In trying to trace the problem... if I use a String parameter.  I get the 
> same error.  So my question what makes the "Credential Parameter" special 
> that you can use it's ${name} in the  freestyle jobs Bind area for pulling 
> passwords to variables?
>
> --
> 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/31918aae-5e4e-46c8-ae39-6e80363d37a3n%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/CAEot4ozg_Bco2fZ51%3D3yeDE43wP_NXa6%3D7cPWVsBBHWcmZi3yA%40mail.gmail.com.

Re: Forked repositories in GitHub

[Matt Sicker]

ported 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 (including perhaps a complete repo
>>>>>> transfer to retain issues and PRs). If they refuse, rather than cut the
>>>>>> fork relationship, we could just delete our unused fork. (While this
>>>>>> touches on plugins maintained exclusively outside jenkinsci, I consider
>>>>>> that general topic to be a separate conversation. Please keep this thread
>>>>>> focused on this proposal.)
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Daniel
>>>>>>
>>>>>> 1:
>>>>>> https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/#discussions
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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/6D96DA83-2AE0-4C87-92D6-4CCC8DFE1E57%40beckweb.net
>>>>>> .
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Arnaud Héritier
>>>>> Twitter/Skype : aheritier
>>>>>
>>>>> --
>>>>> 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/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com?utm_medium=email_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/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>>
>>> --
>>> Arnaud Héritier
>>> Twitter/Skype : aheritier
>>>
>>
>>
>> --
>> Arnaud Héritier
>> Twitter/Skype : aheritier
>>
> --
> 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/50ad23a4-abe8-4a69-ab09-2419d227e830n%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/50ad23a4-abe8-4a69-ab09-2419d227e830n%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAEot4oz_CHTEH257FqacEOChDxEHTWj0SPOVTbt3%2BKKCSxnj0A%40mail.gmail.com.

Re: Failing CI build for tuleap-oauth-plugin

[Matt Sicker]

That looks like an intermittent issue. You can try closing and opening
the PR to trigger a new build to try again.

On Mon, Aug 10, 2020 at 11:12 AM Goyot, Martin  wrote:
>
> Hi there,
>
> Is there a current issue with the Jenkins pipeline for plugins or are we 
> doing something wrong? Our builds seems to not be able to connect to the AWS 
> machines: 
> https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Ftuleap-oauth-plugin/detail/PR-35/4/pipeline
>
> --
> 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/CA%2Bb6JB9TtcG6RiW_R_bZNtq7K6iBKVUcWchENBVtkSmtoUqjyw%40mail.gmail.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/CAEot4oyiZ9GgOSLhV0CUpqoFVT6S6gc8qAQuYhbU-463jmHAVw%40mail.gmail.com.

Re: buildPlugin() now with Warnings NG and GitHub checks

[Matt Sicker]

Very nice! I love automation. :)

On Thu, Aug 6, 2020 at 2:26 AM 'Olblak' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Well done \o/
>
> On Thu, Aug 6, 2020, at 8:54 AM, Tim Jacomb wrote:
>
> Hi all
>
> I’m happy to announce that the `buildPlugin()` library step that is used
> by almost all plugins on ci.jenkins.io now uses the Warnings NG plugin
> <https://plugins.jenkins.io/warnings-ng/> for static code analysis
> reporting and quality control.
>
> We have set default quality gate for:
>
>-
>
>No new spotbugs issues
>-
>
>No checkstyle issues
>
> Note: in order for spotbugs to calculate your initial issues you will need
> your master branch ran once to establish a baseline
>
> You can customise the quality gates, however you wish (enable / disable
> them, or adjust the severity of the warnings), see the documentation for
> the pipeline-library
> <https://github.com/jenkins-infra/pipeline-library/#optional-arguments>
> and the Warnings NG <https://plugins.jenkins.io/warnings-ng/>
> documentation.
>
> On top of the Warnings NG addition we have switched ci.jenkins.io over to
> GitHub app authentication (mailing list post
> <https://groups.google.com/g/jenkins-infra/c/VYXkHYS10oo/m/DUP7kVZOAQAJ>).
> This gives us much higher rate limits and access to the GitHub checks API.
>
> Lastly we have installed the GitHub checks
> <https://plugins.jenkins.io/github-checks/> plugin which is a GSoC 2020
> project by Kezhi Xiong which exposes an API allowing consuming plugins to
> publish checks results and annotations to GitHub.
>
>
>
>
> See Kezhi’s GSoC phase 2 demo on YouTube
> <https://youtu.be/b67I6spBdTg?t=1517>.
>
> Next steps:
>
>-
>
>We hope to soon land support for the Code Coverage API plugin in
>`buildPlugin()` - Code Coverage API plugin already has support for the
>GitHub checks plugin. - Pull request
><https://github.com/jenkins-infra/pipeline-library/pull/153>.
>-
>
>Kezhi and I will be hosting a Jenkins online meetup Mid August on
>GitHub app authentication and the GitHub checks integration.
>-
>
>Possibly some tuning of severity on some issues - see discussion
>
> <https://github.com/jenkins-infra/pipeline-library/pull/121#discussion_r465956892>
>
>
> Feedback
>
> We would love any feedback, please feel free to provide it either here, in
> Gitter <https://gitter.im/jenkinsci/github-checks-api> or in the issue
> tracker for the respective component.
>
> 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/CAH-3Bidxq1BJi8LYzj-ftWfzSkevYro4Z%2B38Bnpx-jqpsDNAsw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bidxq1BJi8LYzj-ftWfzSkevYro4Z%2B38Bnpx-jqpsDNAsw%40mail.gmail.com?utm_medium=email_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/e8f770f1-a504-4139-bc51-5bb286739ca4%40www.fastmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/e8f770f1-a504-4139-bc51-5bb286739ca4%40www.fastmail.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAEot4ox04EBcB7P_k9FC4y76EL7iAJn9KvtK-36Sm9hocMVrCA%40mail.gmail.com.

Re: Proposal: Jenkins CDF Graduation July 28th

[Matt Sicker]

gt;>>>> A new listing of Jenkins adopters was introduced on jenkins.io:  
>>>>>> https://www.jenkins.io/project/adopters/
>>>>>>
>>>>>> Please do not hesitate to submit pull requests and to add your companies 
>>>>>> there!
>>>>>>
>>>>>> Jenkins Weekly Release line is now documented on jenkins.io:  
>>>>>> https://www.jenkins.io/download/weekly/
>>>>>> Jenkins Main repository was updated to include references to all the 
>>>>>> pages above:  https://github.com/jenkinsci/jenkins/blob/master/README.md
>>>>>> The default Jenkins contributing template was updated by Tim Jacomb:  
>>>>>> https://github.com/jenkinsci/.github/blob/master/CONTRIBUTING.md. More 
>>>>>> contributions are always welcome!
>>>>>> Core infrastructure Initiative checklist is in progress, but it is not a 
>>>>>> blocker for graduation
>>>>>>
>>>>>> A Security Checklist has been submitted for review today. Reviewers: 
>>>>>> Jenkins Security Team, Jenkins Infrastructure and Documentation officers
>>>>>> We have an initial agreement about creating a Jenkins Bug Triage Team, I 
>>>>>> will proceed with the implementation next week
>>>>>>
>>>>>> If the Jenkins developers and board members agree, I will send an 
>>>>>> official request to CDF TOC on behalf of the Jenkins project. I would 
>>>>>> appreciate any feedback!
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Oleg Nenashev
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 16, 2020 at 11:17 PM Vlad Silverman  
>>>>>> wrote:
>>>>>>>
>>>>>>> +1 from me on achieving CDF Graduation by July 28 based on listed 
>>>>>>> Criteria Checklist
>>>>>>>
>>>>>>> Thx, Vlad
>>>>>>>
>>>>>>> On Jun 12, 2020, at 6:43 AM, Oleg Nenashev  wrote:
>>>>>>>
>>>>>>> I have started a Google Doc with a checklist: 
>>>>>>> https://docs.google.com/document/d/1Ldmtny6OfEtQlCqdFWqq9Z25cxkZFX6yNiRqOOxo77c/edit?usp=sharing
>>>>>>> Please feel free to contribute and suggest changes!
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Oleg
>>>>>>>
>>>>>>> On Friday, June 12, 2020 at 12:16:35 AM UTC+2, Marky Jackson wrote:
>>>>>>>>
>>>>>>>> +1 from me
>>>>>>>>
>>>>>>>> On Jun 11, 2020, at 2:39 PM, Tracy Miranda  
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> Last year Jenkins became a CD.Foundation project. The Technical 
>>>>>>>> Oversight Committee (TOC) of CDF set out a project lifecycle for 
>>>>>>>> projects as part of the governance model. CDF is proposing Jenkins be 
>>>>>>>> the first project to go through the process and "graduate" i.e. 
>>>>>>>> demonstrate it has met the acceptance criteria.
>>>>>>>>
>>>>>>>> Dan Lorenc, the current TOC Chair, joined the Jenkins Governance 
>>>>>>>> meeting this month for an overview of the process and we had a 
>>>>>>>> discussion around the criteria. In short, there are a few housekeeping 
>>>>>>>> things to do for Jenkins to graduate, and the process has already been 
>>>>>>>> beneficial to the project health (e.g. helping identify that we need 
>>>>>>>> to strengthen the triage team, update Code-of-Conduct, etc). Project 
>>>>>>>> graduation will also be an opportunity to promote the Jenkins project 
>>>>>>>> via CDF channels and highlight how the project goes from strength to 
>>>>>>>> strength.
>>>>>>>>
>>>>>>>> I would like to propose that the Jenkins Community commit to 
>>>>>>>> graduating by the end of July, i.e. on July 28th 2020 at the CDF TOC 
>>>>>>>> meeting, we show how we've met the criteria and ask for a vote.
>>>>>>>>
>>>>>>>> (Not

Re: Proposal - Expanding the DockerHub admins team

[Matt Sicker]

Sounds great!

On Wed, Jul 29, 2020 at 11:06 AM Oleg Nenashev  wrote:
>
> Hi all,
>
> I am planning to be on vacation in the beginning of September, likely off the 
> grid for some time. I would like to ensure that we have a good bus factor. 
> Taking our experience with the Docker images in the recent months, it would 
> be great to add more admins there.
>
> I propose to add Alex Earl and Mark Waite to the team. It would mean the 
> administrative access to all DockerHub organizations: jenkins, jenkinsci, 
> jenkins4eval. Both Mark and Alex have CLA signed. They also have 
> administrative access to many areas of the Jenkins infrastructure, including 
> critical components like the new release infrastructure and Trusted CI.
>
> Any objections?
>
> Thanks in advance,
> 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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLBiDZxaB3txQjmABX8t1_L4W2YY%3Dvg5G7C%2BX0vcPqfzsg%40mail.gmail.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/CAEot4ozj%3DFAjDU4fjQni9U3XsNQ2p%2Bi3Jbhwc-ncMZZ8ZYmDSw%40mail.gmail.com.

Re: LTS baseline selection for the successor of 2.235

[Matt Sicker]

;> 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 jenkin...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/0B575C1E-06AD-4D04-BDA2-0424269AAB8F%40gmail.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/0B575C1E-06AD-4D04-BDA2-0424269AAB8F%40gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>>
>>> --
>>>
>>> Daniel Beck
>>> Senior 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/aadb0f8f-7847-4ad6-a5a0-e396f03bbabeo%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/aadb0f8f-7847-4ad6-a5a0-e396f03bbabeo%40googlegroups.com?utm_medium=email_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/CAH-3BiemXRGrxXv_%3DiPXvi6y3LQKcreT0Z3DWAqF-panTEjosA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BiemXRGrxXv_%3DiPXvi6y3LQKcreT0Z3DWAqF-panTEjosA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


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

Re: Extension: Difference between Singleton and Describable/Descriptor pattern

[Matt Sicker]

I'd love to see more info about this. I had similar difficulty
understanding the difference back when I was working on the secret
textarea UI widget, and I had wanted to do some research to write a
blog post about it, but that was well over a year ago by now.

On Mon, Jul 27, 2020 at 11:06 AM Jesse Glick  wrote:
>
> On Fri, Jul 24, 2020 at 10:52 AM mike cirioli  wrote:
> > Thanks for the description Jesse
>
> Sure; want to write up a jenkins.io patch?
>
> --
> 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/CANfRfr2uqO5b4AtriB5GmaduOL4a2RPqBOcyXE87gqRWoKHY9g%40mail.gmail.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/CAEot4oy-qLRUF%2BhL-UGbyf7_EvF%2BbP%2BgjxTLJOpHq5vLV0H%3DAQ%40mail.gmail.com.

Re: Will JDK 8 supports RHEL4

[Matt Sicker]

This mailing list is for Jenkins development. Please see
https://www.jenkins.io/mailing-lists/ for user mailing lists.

On Thu, Jul 23, 2020 at 8:15 AM venkateshwarlu miyapuram
 wrote:
>
> Hi,
>
> I am in the process of migrating Jenkins 1.x which is in Windows 2003 machine 
> to 2.x to windows 2019 machine .
> Here is the problem , We have dependency of some modules with RHEL4 which 
> cannot migrate and RHEL4 is not supporting JDK8 .
> Please advise any suggestions
>
> --
> 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/3bf80338-b87f-4d39-9e40-50fcb40c67c1o%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/CAEot4oygQE62PKE3Owp6hJiZYgPJzc0yT75K0oPzdF3JOZAsNg%40mail.gmail.com.

Re: jenkins slave run in jdk 1.6

[Matt Sicker]

This is the developer list for discussing development of Jenkins and
plugins. You want to try the jenkinsci-users mailing list or similar
chats: https://www.jenkins.io/mailing-lists/

On Thu, Jul 23, 2020 at 8:15 AM miyapuram...@gmail.com
 wrote:
>
> Hi All,
>
> i have a very complex environment in my jenkins build and deployment. There 
> are four kinds of system: windows(for the jboss java environment), aix(for 
> the xlc compiler), linux(for the websphere jee application), mac (for the ios 
> development). Different system own their jdk, the least one is the JDK 1.6. 
> For the AIX IBM JDK(with the DES SDK problem), so i need the jenkins 2.32.1+, 
> but my environment which has the JDK 1.6, so the slave JNLP showing error it 
> requries JDK8 . But the jenkins slave jar need the JDK 1.7+, so i thinks 
> weather i can compile the slave jar by myself for the jdk 1.6.
>
> How can i solve this problem?
>
>
> Pls help on this.
>
>
> Regards,
>
> M.Venkat.
>
> --
> 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/633cc212-b2e0-4c5f-b45d-66a6be26d455n%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/CAEot4oyQ%2BZagtNOktczZo6K%3DbepiFc4FK45fv2xSjUhzdwUB9w%40mail.gmail.com.

Re: modifying a @DataboundConstructor

[Matt Sicker]

There's an automatic converter between String and Secret when loading
XML files via XStream in Jenkins. The only compatibility concerns you
should have here are for any code that directly calls that constructor
or uses the string value of the secret.

On Wed, Jul 8, 2020 at 3:51 AM Goyot, Martin  wrote:
>
> Thanks Ullrich!
>
> Do you have any pointer for me as to how to proceed?
>
> Le mer. 8 juil. 2020 à 10:34, Ullrich Hafner  a 
> écrit :
>>
>>
>>
>> Am 08.07.2020 um 10:16 schrieb Goyot, Martin :
>>
>> Hi there,
>>
>> On the OAuth plugin I'm working on, I'd like to modify the 
>> @DataboundConstructor for the Realm. Issue is, if I modify it, whether be 
>> the signature or the inners of the function, the deserialization for 
>> previous instances won't work anymore hence breaking any previous 
>> installation of the plugin.
>>
>> How am I supposed to proceed in such particular cases, when I need to update 
>> this constructor without breaking any config already set on Jenkins 
>> instances?
>>
>>
>> The serialization does not use the constructor. You need to provide a 
>> readResolve method that will map the old fields to the new fields.
>>
>> Here is some code for reference:
>>
>> public class MySecurityRealm extends SecurityRealm {
>> private String clientId;
>> private Secret clientSecret;
>>
>> @DataBoundConstructor
>> public MySecurityRealm(String clientId, String clientSecret) {
>> this.clientId = Util.fixEmptyAndTrim(clientId);
>> this.setClientSecret(Util.fixEmptyAndTrim(clientSecret));
>> }
>> }
>>
>> Thanks in advance !
>> Martin
>>
>> --
>> 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/CA%2Bb6JB-wx%3D%2BPRcXb057-9idgZkL7kYw%3DSvmSsaR-mxRJ9_g96A%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/E316B1D7-CCBE-4BCE-A50C-E64A53A88E68%40gmail.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/CA%2Bb6JB8J4-AHbMyb%3DWDATiXGvtnuw6YcEcB-pV0SPc4Ju6xNkA%40mail.gmail.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/CAEot4ozZDBe3yKLAVUWjFYiUPjD5NtweBqW0%2BozvBPr5hb1ScA%40mail.gmail.com.

Re: ANN: Jenkins release artifacts uploads blockage on June 09, and a temporary downloads issue

[Matt Sicker]

No complaints about the lack of a DNSSEC record or other ways to avoid
an initial MitM attack when connecting to jenkins.io for the first
time. Or numerous other theoretical points of failure. It might be
better to offer constructive advice rather than declaring everything
broken.

On Mon, Jun 15, 2020 at 1:20 PM Steve Springett
 wrote:
>
> Security best practices should not be opt-in. I receive the manifest (daily) 
> emails and did not see this topic. Many others likely did not either.
>
> Jenkins is viewed by many as Critical Cyber Infrastructure and plays an 
> important role in the global software supply chain. That supply chain was 
> just weakened today, on purpose.
>
> I understand the volunteer perspective. I lead multiple OWASP projects and 
> spend a considerable amount of time doing open source projects. I get it. 
> Just know that the software supply chain affects everyone including CloudBees 
> Enterprise customers and every downstream consumer of projects built using 
> Jenkins.
>
>
> On Monday, June 15, 2020 at 10:27:01 AM UTC-5 Oleg Nenashev wrote:
>>
>> Hi Steve,
>>
>> Duly noted. Note that we offered an alternate way for maintainers to get 
>> their password delivered if they are not fine with the current delivery 
>> method. In my message from Jub 12: If anyone has concerns about such a 
>> method and wants to use alternate channels for encrypted password transfer, 
>> please send us a message through the Jenkins Infrastructure mailing list 
>> from your email registered in Jenkins. In this email please provide your 
>> public GPG key so that we can reset a password again in a secure way. You 
>> did not contact us, and hence you got your password reset with the standard 
>> process. If you want to get your password reset in a secure way, please feel 
>> free to use this process.
>>
>> Again, we operate with resources and tools we have. The Jenkins project and 
>> its infrastructure are driven by volunteers, and we have limited capacity 
>> when it comes to fixing urgent things due to uncoordinated disclosures. You 
>> may call it insane, but it was the solution we delivered with given 
>> circumstances. Contributors have families and other commitments, and please 
>> know that the situation has taken a high toll on them. Everybody is welcome 
>> to contribute and to contribute to the infrastructure. I am cordially 
>> grateful to those several contributors who stepped up and helped to get the 
>> issue fixed, or offered to help, or sent kind words over different channels. 
>> This is an example to follow.
>>
>> Everyone is welcome to join the team and to work together on a better 
>> solution for user management so that we can prevent a similar situation in 
>> the future.
>>
>> Best regards,
>> Oleg
>>
>>
>> On Mon, Jun 15, 2020 at 5:02 PM Steve Springett  wrote:
>>>
>>> "Technical debt" is not an excuse to reset plugin maintainers accounts and 
>>> include a clear-text email containing their username AND password. That's 
>>> insane. As a security professional I will not stand for that. I will no 
>>> longer be maintaining Jenkins plugins and will attempt to find new 
>>> maintainers for the ones I do. No guarantees.
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Jenkins Developers" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/jenkinsci-dev/3UvrCTflXGk/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> jenkinsci-de...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/4547a00e-e223-4075-a2a1-9162b4634b5bo%40googlegroups.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/da467d52-3ad4-41f5-8d8b-2f86a68487a1n%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/CAEot4owMsAT7Y%2BRHyo87A_QEPeJo5Ufbf9jtu3QGJxzhHVRiFw%40mail.gmail.com.

Re: Terminology Updates

[Matt Sicker]

A master key is a particular type of universal key used for unlocking
multiple different locks. In this case, the master key in Jenkins is
used to unlock all the other encrypted data. It sort of makes sense.

On Mon, Jun 15, 2020 at 10:04 AM Angélique Jard  wrote:
>
> My preference goes to "controller", "server" make me think somehow to the 
> hardware physical machine. "Coordinator" is fine also (in the link tools.ietf 
> in previous post) but a bit hard to pronounce.
>
> As a non english native speaker (but french), I have some issue with "valet" 
> and "majordomo" which have fix gender in french and are all male. I know that 
> it's not like that in english but I think it's better to tell it now.
>
> As a music player I also like "conductor" (as musical director) this is how I 
> see my Jenkins instance when I use it, that orchestrate agents, Jenkinsfile 
> could be the music sheet :) 
> On Monday, June 15, 2020 at 4:00:27 PM UTC+2 Antonio Muñiz wrote:
>>
>> In spanish the term "Master" ("Maestro"), when used in isolation (no "slave" 
>> in the context), has no negative connotations. Its main use is to describe 
>> someone very skilled in some matter (often used for artisans).
>> I might be suffering of language bias, just wanted to give some "non english 
>> native speaker" perspective to the conversation.
>>
>> El lun., 15 jun. 2020 a las 7:56, Justin Harringa () 
>> escribió:
>>>
>>> Personally I thank the community for having already starting down this path.
>>>
>>> I tend to like leader or controller from 
>>> https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1
>>>  but I could also see server working. The difficulty I would see with 
>>> primary/active is that folks who run Jenkins would have a bit of a conflict 
>>> of terminology there.
>>>
>>> Take care all.
>>>
>>> --
>>> 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/3411fed5-7e21-454a-b285-f719f07c1b3ao%40googlegroups.com.
>>
>>
>>
>> --
>> * Antonio Manuel Muñiz
>> * amunizmartin.com
>> * amuniz...@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/56742697-234e-4d29-b613-fcc13d072ed7n%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/CAEot4oywLs2LskSZV6p%2BY152humcnM_3oTBb2xZi%2BnMM5jZkYA%40mail.gmail.com.

Re: Terminology Updates

[Matt Sicker]

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/CAO49JtH%3DNGuf%2BEOoh9gXyOY53vx761aV-w4V07hA7SxwZ%2B_Q1A%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/7EF2760C-0B57-42AA-A600-B55E557956D3%40gmail.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/CAEot4oxiMsarDuQp8KcgUcv08TVtHFBpsz2m4qRECdBo%2BvhzGw%40mail.gmail.com.

Re: RCA of memory conditions on Ubuntu EC2 agents on ci.jenkins.io causing test instability

[Matt Sicker]

Looks like m5a are AMD and t2 are Intel (and burstable). If they cost
similar, m5a sounds better.

On Fri, Jun 5, 2020 at 4:19 PM Vlad Silverman  wrote:
>
> I don't know what the cost difference is between the t2 and m5a instances.
>
>
> I guess it depends on the region.
> More details are at https://aws.amazon.com/ec2/pricing/on-demand/
>
> On Jun 5, 2020, at 2:02 PM, Slide  wrote:
>
> We are currently using t2.small instances on EC2 for the non-high memory 
> instances
>
> 
>
> Going from t2.small to t2.medium would double the CPU Credits / hour, though 
> it also doubles vCPU count and Mem.
>
> The high mem instances are using m5.adxlarge:
>
> 
>
> I don't know what the cost difference is between the t2 and m5a instances.
>
> On Fri, Jun 5, 2020 at 1:40 PM Basil Crow  wrote:
>>
>> On Fri, Jun 5, 2020 at 1:24 PM Jesse Glick  wrote:
>> > The next step would be PRs to infrastructure repositories.
>>
>> I agree. Unfortunately I have spent too much time on this issue already and
>> cannot volunteer to become an infrastructure developer at present.
>>
>> > 256Mb seems low for a Surefire JVM—this needs to run Jenkins and all
>> > plugins plus whatever your test code is doing.
>>
>> I agree, which is why I said "I worked around the problem" rather than "I
>> solved the problem." Changing the JVM settings for Surefire and the agent
>> launched by my tests was easy because both those JVMs were completely within
>> my control. I agree that a long-term solution would involve setting -Xmx and
>> -Xms on all agent and Maven JVMs as well as possibly increasing the EC2
>> instance size for these nodes.
>>
>> --
>> 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/CAFwNDjrjW2aA74pqoFMhca%2BD0YqL%3DWvNe46g7G1aM3Bmx5LrWQ%40mail.gmail.com.
>
>
>
> --
> Website: http://earl-of-code.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/CAPiUgVfTTqU65LN7iDo%2BMw5xPnCKFJfiTqq7kgcCtfXVMsN42w%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/FCEB4838-4FF8-410F-AEB3-6FACBDF98D80%40gmail.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/CAEot4ox0q94X6DA-iyhNwoEXXwZk98E5qN1da0ngO6XWCre2Vw%40mail.gmail.com.

Re: RCA of memory conditions on Ubuntu EC2 agents on ci.jenkins.io causing test instability

[Matt Sicker]

Might be worth looking at OpenJ9. It has some nifty cloud native
features for helping reduce JVM load. For example:

* https://www.eclipse.org/openj9/docs/jitserver/
* https://www.eclipse.org/openj9/docs/shrc/

Disclaimer: I've only seen a talk about this; I've never tried
configuring this in a real cloud environment. Looks nifty, though.

On Fri, Jun 5, 2020 at 3:24 PM Jesse Glick  wrote:
>
> Thank you for digging into this problem which has been plaguing us.
> (INFRA-2548?) Your analysis sounds right. The next step would be PRs
> to infrastructure repositories.
>
> 256Mb seems low for a Surefire JVM—this needs to run Jenkins and all
> plugins plus whatever your test code is doing. Of course 2Gb is also a
> bit tight for `JenkinsRule` tests. I agree that `agent.jar` should be
> able to run in quite a bit less than whatever HotSpot ergonomics would
> pick by default, and probably `mvn` could as well, leaving more room
> for the Surefire JVM and any extra processes such as mock agents, Git,
> Docker fixtures, etc.
>
> I wonder if there is any way to have all the JVMs in this VM coöperate
> to jointly use, say, 75% of available RAM in whatever proportion.
>
> --
> 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/CANfRfr1t-OO_xf4JC7ABZApepXSQ44P2SphF_8j0cf8FsZNU1A%40mail.gmail.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/CAEot4ozeXkYbRevuwk4F5wr%3DaR9sniv%2BJ3H60Ed-7iKpT%3DErGA%40mail.gmail.com.

Re: Remote access API

[Matt Sicker]

You need to create an API token in your user account to authenticate.

On Thu, May 21, 2020 at 6:20 AM Jayalakshmi Nair
 wrote:
>
> Hello all,
>
> I was looking for a lightweight method to get the build details. (As we have 
> a lot of builds and noticed that getBuilds method consumes a lot of time).
> I figured out that there is no other approach from the Jenkins methods to get 
> the builds.
>
> Now I am trying to get the build details from 
> $JENKINS_HOME/jobs/$NAME_OF_JOB/api/xml. However ,while trying to read the 
> xml using the url, this throws me a 403 or 401. This can be resolved by 
> authenticating.
>
> Can anyone assist me on how I can obtain the username and password of the 
> currently logged in user in java? Or is there a way to access the job link 
> without authentication?
> Or is there any api in java which helps me read the above URL?
>
> Thanks in advance.
>
> -Jayalakshmi
>
> --
> 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/e4cb9ec0-5bb8-4014-bb3a-428aab6d7ccc%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/CAEot4oxBUbsT1k7PW%3DNvWPFrCdJ5-Qh1afQ9%2Bj-HXE9qorSNUA%40mail.gmail.com.

Has anyone implemented OpenTelemetry or similar observability APIs in Jenkins?

[Matt Sicker]

Site: https://opentelemetry.io/

This seems like it could be a useful thing to integrate with,
particularly for Remoting-related network calls, but it could
potentially be extended to other HTTP client type calls and such for
richer tracing data. As a Jenkins admin, you'd be able to identify
issues in your Jenkins cluster more easily. Implemented properly, it
could even provide a way for users to submit traces to help debug
issues they find.

I looked at their Java library, and it seems to have an absurd amount
of dependencies compared to a proper logging library (which has no
required dependencies), but the gist of attaching traces and spans to
requests/responses is fairly simple to implement.

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

Re: plugin parent 4.0

[Matt Sicker]

 26 Mar 2020 at 09:11, James Nord  wrote:
>>>>>>
>>>>>> Hi Oleg et al.
>>>>>>
>>>>>> is it time to move the plugin parent out of beta?
>>>>>>
>>>>>> have not seen any negative feedback (or positive door that matter) but 
>>>>>> I've been using it for numerous proprietary plugins with no issue.
>>>>>>
>>>>>> /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 jenkin...@googlegroups.com.
>>>>>> To view this discussion on the web visit 
>>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/5d4104be-2fbc-428f-8992-91b11e41344b%40googlegroups.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 jenkin...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifrNfcECRgZ7A2fxros_vT1S0AezDr6C5HGFGPMgormdQ%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 jenkin...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/545f5189-e38e-2147-d166-e6f8933916e4%40cloudbees.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/dbeebe3e-d25e-44be-af92-1f26ce1c8582%40googlegroups.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-3Bid6JLdKZiPOaZA5faNKp4zBAH0rS-jk2gzyxSgY%2BS9OtA%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/E0F9EF7A-BF9D-465A-B3E9-FC1548AFD42C%40gmail.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/CAEot4owvW%3DcASvVoMWPyRhdjYcJRfh_Uh25fF%3Dx%3DbgppW2xVBw%40mail.gmail.com.

Re: [Proposal] Centralize chat on matrix

[Matt Sicker]

I'd love to use a more modern and open chat protocol like matrix,
though I have no experience in doing so. The only chat server I've run
within the past few years was Mattermost which was nice, though their
LDAP integration costs money from what I remember.

On Fri, Apr 10, 2020 at 11:05 AM Tim Jacomb  wrote:
>>
>> >  if we were to use this is there a reason not to use the SaaS version 
>> > (other than LDAP auth)?
>>
>> I think if we did modular.im, we could still use ldap, and they might be 
>> have open source pricing. I think its something that cdf might be interested 
>> in.
>>
>> I just don't like slack because I have now close to 15 different slack 
>> accounts. Each server needs individual accounts, and monitoring. The desktop 
>> client can handle multiple servers ..okay, though ate up a lot of memory. I 
>> don't know if this ever got fixed.
>
>
> Agree the multiple accounts is a pain
> The performance was fixed mid last year: 
> https://slack.engineering/rebuilding-slack-on-the-desktop-308d6fe94ae4
>
>>
>> I'm a big fan of the big shared environment like gitter and irc where you 
>> can belong to multiple communities at the same time.
>> I also like the matrix has matrix-irc, which would allow weechat, irssi, 
>> ircloud, etc to connect and use basic features like you would with an IRC 
>> server if desired.
>>
> Agree that's useful
>
>
> 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/CAH-3Bifzy5QCHsGihThLCMWZZtUWNE3cn5jKkRYK5oBMQMzmBQ%40mail.gmail.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/CAEot4ozTbnY_nRn5waU5o%3D5bj%2BaV_2ptnQp-m1CsvP9kHfiaLw%40mail.gmail.com.

Re: How to perform a plugin release to Jenkins Artifact Repository through Continuous Integration?

[Matt Sicker]

Typing "mvn release:{prepare,perform}" into a terminal is about as
automated as pressing the "release" button in CI. You can even press
Ctrl-R in a terminal to find the last time you used the command and
use less keystrokes than it takes to type out ci.jenkins.io.

On Fri, Apr 10, 2020 at 11:12 AM Tim Jacomb  wrote:
>
> There's a proposal for automating plugin release here: 
> https://jenkins.io/jep/221
> Not sure what's needed to get it going though, would be great to get done
>
> Thanks
> Tim
>
> On Fri, 10 Apr 2020 at 16:46, Slide  wrote:
>>
>> Yes, all releases are done manually. There are some ideas floating around to 
>> do the deployment in an automated way, but there are some things to flush 
>> out that haven't been solved yet. It's not a hard process. You run mvn 
>> release:prepare release:perform and follow the prompts.
>>
>> On Fri, Apr 10, 2020 at 8:23 AM Shihaaz Buhary  wrote:
>>>
>>> Is that how all the plugins do the release to Jenkins Artifact Repo - 
>>> manually?
>>>
>>> On Thursday, April 9, 2020 at 8:10:17 PM UTC+5:30, slide wrote:
>>>>
>>>> buildPlugin just wraps up a bunch of the common stuff for ci.jenkins.io 
>>>> for building and testing plugins for master, PRs and branches. It does not 
>>>> release anything to the update center. You need to do releases manually.
>>>>
>>>> On Thu, Apr 9, 2020 at 6:42 AM Shihaaz Buhary  wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I know how to do a plugin release manually by executing a few commands as 
>>>>> mentioned in the Performing a Plugin Release documentation. I can also 
>>>>> see a page for Continuous Integration where it mentions about 
>>>>> buildPlugin(configurations: buildPlugin.recommendedConfigurations()). 
>>>>> What this method actually does? Does it release the plugin to repo 
>>>>> through CI? If not, is there a way that we can achieve both (automate the 
>>>>> release) together in the above pages? Because I can see almost all the 
>>>>> plugins are using only the above buildPlugin(...) method in their 
>>>>> Jenkinsfile. Or am I missing something here? I appreciate your help on 
>>>>> this.
>>>>>
>>>>> Thanks,
>>>>> Shihaaz
>>>>>
>>>>> --
>>>>> 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 jenkin...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/53933abf-1a36-440a-838b-6defbb733cf2%40googlegroups.com.
>>>>
>>>>
>>>>
>>>> --
>>>> Website: http://earl-of-code.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/8015df3b-5a54-4796-9831-d142a892bff6%40googlegroups.com.
>>
>>
>>
>> --
>> Website: http://earl-of-code.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/CAPiUgVcS4VLhzE4Q95MzBDwapKqSNLivk4Y-KyCWdzK9Jwks%2Bg%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-3Bify1eu%3DFs4F9VPYw_Ai_JBySYGCTvNS%2BJdcx%2BO5yWPYPg%40mail.gmail.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/CAEot4oyGmNnBV_ggqTNtUuaQLzYr7KBiQBfBEK_zXs8Pnpum0w%40mail.gmail.com.

Re: Discussion: Jenkins Core Maintainer/Developer discussion channels

[Matt Sicker]

I'm not a big fan of gitter myself as the client is fairly buggy and
limited compared to the alternatives. I'm even ok with IRC. We could
use some other chat as well like Slack as you suggested.

On Wed, Apr 8, 2020 at 2:15 PM Sladyn Nunes  wrote:
>
> I would like to share my opinion as a  new contributer to the Jenkins core 
> that it would be very helpful if there is a Jenkins core developers dedicated 
> channel maybe on slack or any other convenient medium similar to the 
> Jenkins-X project , because the jenkinsci/jenkins gitter channel is mostly 
> filled with user queries and it could be possible that the discussion may get 
> lost.
> Also +1 to the on demand sync-ups for the core maintainers, maybe non 
> maintainers can attend to learn more about the recent developments and learn 
> from the maintainers.
> Thanks and cheers.
>
> On Wed, Apr 8, 2020, 8:06 PM Tim Jacomb  wrote:
>>
>> do you mean #jenkins on irc or gitter http://gitter.im/jenkinsci/jenkins ?
>>
>> gitter jenkins is are very heavy user channel
>>
>> irc jenkins isn't so bad but still lots of people after pipeline help.
>>
>> On the kubernetes slack there's a few, -users and -dev 
>> channels
>> Which helps separate out the noise in my opinion.
>>
>> But yeah open to both...
>>
>> On Wed, 8 Apr 2020 at 14:50, Daniel Beck  wrote:
>>>
>>>
>>>
>>> > On 8. Apr 2020, at 14:17, Oleg Nenashev  wrote:
>>> >
>>> > creation of chats and other communication channels for Jenkins core 
>>> > maintainers which could help in the case of runtime communications: 
>>> > merge/changelog discussions, sync-ups between maintainers, etc. Right now 
>>> > we mostly use pull requests and mailing lists for such kind of 
>>> > discussions, but a number of private messages between maintainers makes 
>>> > me tink that we might be lacking a chat for runtime discussions
>>>
>>> I see this going in two ways:
>>>
>>> - Core development related (and will probably pretty open)
>>> - Core maintenance related (and can easily be limited to committers and the 
>>> triage team)
>>>
>>> It seems to me that there are already plenty of venues to discuss the 
>>> former, and it's typically not time sensitive. OTOH, the latter needs (or 
>>> can benefit from) closer coordination, especially towards end of the week, 
>>> or before LTS schedule related dates.
>>>
>>> I prefer we don't create yet another almost-general-purpose chat (what 
>>> wrong with #jenkins and equivalents for general questions about core?), so 
>>> for me, the latter seems more useful. A larger scope would also increase 
>>> the volume of messages, which makes it less viable to have notifications 
>>> enabled.
>>>
>>> That said, I'm open to either (or both…), if the chosen approach doesn't 
>>> work we can always change it. Given the relatively small group of people 
>>> involved, it shouldn't be too difficult to change direction.
>>>
>>> --
>>> 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/925CE240-87BD-44B3-8D15-535FDFE4F328%40beckweb.net.
>>
>> --
>> 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-3Bif09MwSQZFW6CLvnejsN7drWk8Zo%2Bp8Yw0U8UWhY-G01A%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/CAC-Leqt60gdyFmpt3cgHi8qRT4PHxqrxqJsuE-1wom5hEdvCZg%40mail.gmail.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/CAEot4owx3YVUPX%3DAZWrsLKUraD06azLiS%3DKdAcGOvVYQNuVkbw%40mail.gmail.com.

Re: Proposal: Public community-driven roadmap for the Jenkins project

[Matt Sicker]

Looks great! Thanks for the hard work everyone!

On Wed, Apr 1, 2020 at 3:44 PM Oleg Nenashev  wrote:
>
> Quick updates: https://jenkins.io/project/roadmap/ is live!
>
> Roadmap JEP has been published as a draft: JEP-14
> Initial pull request was merged as it was agreed at the governance meeting 
> last week. It is considered as a work-in-progress draft, so the data does not 
> represent the final roadmap. Blue Ocean's Javascript magic was replaced by 
> old faithful HAML, so we do not
> Data is now stored in the YAML format: /content/_data/roadmap/roadmap.yml
>
>  Any feedback will be appreciated, especially Jenkins Roadmap item 
> proposals.Please feel free to just submit pull requests!
>
> Best regards,
> Oleg
>
>
> On Monday, March 23, 2020 at 11:21:45 AM UTC+1, Oleg Nenashev wrote:
>>
>> I will submit a JEP today. Once it is in place, I would also like to go 
>> ahead with the suggested rollout plan and to deploy a WIP version of the 
>> Roadmap page on the website. All disclaimers will be applied there.
>> Added the approval request to the next governance meeting agenda: 
>> https://jenkins.io/project/governance-meeting/
>>
>> Best regards,
>> Oleg
>>
>>
>> On Monday, March 16, 2020 at 10:28:07 AM UTC+1, Oleg Nenashev wrote:
>>>
>>> Thanks all for the feedback and for the comments in the Google Doc!
>>> I will go ahead tomorrow and suggest a formal JEP.
>>>
>>> All Jenkins contributors are welcome to suggest their roadmap items!
>>>
>>>
>>> On Sunday, March 15, 2020 at 11:50:24 PM UTC+1, Daniel Beck wrote:
>>>>
>>>>
>>>>
>>>> > On 12. Mar 2020, at 17:09, Oleg Nenashev  wrote:
>>>> >
>>>> > On Jan 31 we had a Jenkins contributor summit in Brussels. At this 
>>>> > unconference we discussed a number of ongoing projects and key 
>>>> > initiatives which could help us to evolve the project (meeting notes). 
>>>> > One of the proposals there was to create a public community-driven 
>>>> > roadmap for the project. There was a strong consensus about doing so, so 
>>>> > I went ahead and created a Public Jenkins Roadmap process proposal draft 
>>>> > which is based on the discussion results. I plan to submit it as a 
>>>> > formal Jenkins Enhancement Proposal later after getting initial feedback 
>>>> > from contributors who were not in Brussels. Any feedback will be 
>>>> > appreciated!
>>>> >
>>>> > Motivation: Jenkins is a community-driven project. Changes there happen 
>>>> > only in those areas where we have contributors. So changes in the 
>>>> > project may sometimes appear chaotic to an external observer. At the 
>>>> > same time, now we have a lot of entities like special interest groups, 
>>>> > sub-projects and teams. These entities drive key initiatives in the 
>>>> > community, and largely use their own channels for that. One has to find 
>>>> > these channels to follow a project. A Jenkins user or an outside 
>>>> > contributor might have difficulties understanding what is going on and 
>>>> > how to contribute.
>>>> >
>>>> > This proposal documents a new roadmap process which would make planned 
>>>> > changes more explicit and which would highlight the potential projects 
>>>> > to Jenkins contributors and users. It will help Jenkins users and 
>>>> > vendors to properly plan their work and to contribute to the projects 
>>>> > they are interested in.
>>>> >
>>>> > Links:
>>>> > • JEP draft in Google Doc
>>>> > • Prototype implementation for jenkins.io
>>>> > • Roadmap JSON from the PoC (feel free to contribute!)
>>>> > Note that my proposal does not define the roadmap items on its own, it 
>>>> > only defines the process and the implementation for it. Not all 
>>>> > proposals from the contributor summit have been added to the draft, but 
>>>> > I plan to follow-up on that during the proposal review. In the coming 
>>>> > weeks I am planning to reach out to Special Interest Groups, teams and 
>>>> > sub-projects so that they could contribute their roadmap items for key 
>>>> > initiatives. Maintainers of Jenkins plugins are also welcome to make 
>>>> > suggestions.
>>>> >
>>>>
>>>>
>>>> Really cool, thanks for driving this!
>>>>
>>>>
> --
> 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/0d57f091-0ea9-441c-92a9-71cce6f59c99%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/CAEot4ox99iUa6-NMxWnU9VUWBkz1CqFj82cY6ey5uZx4cv%2Br5Q%40mail.gmail.com.

Re: Automating plugin release process via GitHub Actions

[Matt Sicker]

This sounds like it might relate well to a reproducible builds project
of some sort. Ideally we'd be able to do that in ci.jenkins.io, though
credentials management is a little less fine-grained there, so doing
so that way would likely required a trusted CI/CD environment.

Whether it's in Jenkins, GitHub Actions, or elsewhere, what I've
always done is create dedicated CD credentials while limiting said
credentials' access scopes as much as possible.

On Fri, Mar 27, 2020 at 2:16 PM Radek Antoniuk  wrote:
>
> I'm thinking about automating the plugin release process using GH Actions:
>
> https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets
> https://github.com/marketplace/actions/maven-release
> https://help.github.com/en/actions/reference/events-that-trigger-workflows
> https://www.asyncapi.com/blog/automated-releases/
>
> It seems that the process for setting this up for releasing on GH is quite 
> straightforward.
> The issue is uploading the new artifact to the Artifactory, for what we need 
> the credentials that are managed through:
> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/
>
> There are two problems here:
> - what user should be used in GH action to push to Artifactory
> - the GH secrets can be only created by GH org owners
>
> Do you think it's a good idea to try this out?
> For me the benefits are:
> - the release process will be done in a standard environment defined by the 
> used docker image (obviously could be done locally but that's the point not 
> to do have the need to do it in docker locally)
> - the process can be automated, e.g. "do a release at the last day of month 
> if there were any new PRs merged" - that would increase transparency and 
> predictability on the releases
>
> Cheers,
> Radek
>
> --
> 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/a799d799-6015-4252-8eb6-8d7f06a76609%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/CAEot4owf%2B6KJyABmzVvxLkNhC-_MRZLs%3D%3DB8ntPzxHxCYVeK5Q%40mail.gmail.com.

Re: Proposal: Public community-driven roadmap for the Jenkins project

[Matt Sicker]

That looks really cool!

On Thu, Mar 12, 2020 at 11:45 AM Oleg Nenashev  wrote:
>
> Just a sample screenshot for those who are interested to see how it may look 
> like.
> This is a mock data and a PoC layout, so please do not consider it as a final 
> version.
>
>
>
> On Thursday, March 12, 2020 at 5:09:27 PM UTC+1, Oleg Nenashev wrote:
>>
>> Dear Jenkins contributors,
>>
>> On Jan 31 we had a Jenkins contributor summit in Brussels. At this 
>> unconference we discussed a number of ongoing projects and key initiatives 
>> which could help us to evolve the project (meeting notes). One of the 
>> proposals there was to create a public community-driven roadmap for the 
>> project. There was a strong consensus about doing so, so I went ahead and 
>> created a Public Jenkins Roadmap process proposal draft which is based on 
>> the discussion results. I plan to submit it as a formal Jenkins Enhancement 
>> Proposal later after getting initial feedback from contributors who were not 
>> in Brussels. Any feedback will be appreciated!
>>
>> Motivation: Jenkins is a community-driven project. Changes there happen only 
>> in those areas where we have contributors. So changes in the project may 
>> sometimes appear chaotic to an external observer. At the same time, now we 
>> have a lot of entities like special interest groups, sub-projects and teams. 
>> These entities drive key initiatives in the community, and largely use their 
>> own channels for that. One has to find these channels to follow a project. A 
>> Jenkins user or an outside contributor might have difficulties understanding 
>> what is going on and how to contribute.
>>
>> This proposal documents a new roadmap process which would make planned 
>> changes more explicit and which would highlight the potential projects to 
>> Jenkins contributors and users. It will help Jenkins users and vendors to 
>> properly plan their work and to contribute to the projects they are 
>> interested in.
>>
>> Links:
>>
>> JEP draft in Google Doc
>> Prototype implementation for jenkins.io
>> Roadmap JSON from the PoC (feel free to contribute!)
>>
>> Note that my proposal does not define the roadmap items on its own, it only 
>> defines the process and the implementation for it. Not all proposals from 
>> the contributor summit have been added to the draft, but I plan to follow-up 
>> on that during the proposal review. In the coming weeks I am planning to 
>> reach out to Special Interest Groups, teams and sub-projects so that they 
>> could contribute their roadmap items for key initiatives. Maintainers of 
>> Jenkins plugins are also welcome to make suggestions.
>>
>> Thanks for your time and feedback,
>> Oleg Nenashev
>>
> --
> 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/220e2089-26d1-48ff-bde1-0c8ca862cb98%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/CAEot4oytQrwS8NPdvfZT4n2u%2Bv_cwtfVhTRafPQTzV0twvXzTg%40mail.gmail.com.

Re: Jenkins architecture

[Matt Sicker]

Responses inline below:

On Thu, Feb 27, 2020 at 9:07 AM Jeroen Haaksema
 wrote:
>
> Hello,
>
> First of, I’m really sorry if this is not the right place to ask this, if not 
> please let me know who I could direct this to!I am a CS student who is doing 
> a course on architecture and I have chosen Jenkins. Part of the course is 
> communicating with the architect. There doesn’t seem to be just a single 
> architect within Jenkins and your group seems to me the closest I will get to 
> an actual architect. The assignment I’m working on is a reconstruction of the 
> architecture from an open source software project and one of the things we 
> are looking at is Architecturally Significant Requirements(ASR). Which comes 
> down to requirements set in stone with no wiggle room. I would really 
> appreciate it if someone would be able to either confirm or deny if the ASR’s 
> I have defined are correct.

Correct; there isn't a single architect behind Jenkins, though Kohsuke
Kawaguchi was the original developer which is the closest thing I can
think of.

> Would you say that part of the reason that Jenkins was developed in Java is 
> due to that this means that the codebase can be used for Linux, Mac Os X and 
> Windows? (this obviously skips over that Oracle, the owner of Java was part 
> of the inception of Jenkins)

Cross platform capabilities are useful, though I'd also assume it was
also chosen as a familiar tech stack by the original developer at the
time when it was just a side project running on a spare computer at
his office.

> Would you say that using HTTP to manage slave nodes is to make it possible 
> for Jenkins to have nodes on different operating systems working together?

The nodes are managed through a custom protocol which has allowed it
to be implemented in several concrete implementations such as
launching over SSH, using the protocol directly (encrypted via TLS)
over TCP/IP for agent-initiated TCP/IP connections, and even using
Apache Kafka as a message broker of sorts.

> Furthermore I have some other questions:
>
> Would you say that one of the main features of Jenkins is the Pipeline and 
> the option to customise which steps are taken including the order and 
> possible steps after the completion of test?

Yes, though do note that pipelines are a more recent feature than the
project itself, though just through a different UI. Automation of
tasks and reacting to them is the gist in my opinion, yes.

> What is the reason that plugins can be written in Kotlin?

Kotlin was designed to interoperate easily with Java [1], so it's a
natural extension to be able to do the same in Jenkins. Due to
JEP-200, though, there may be extra boilerplate code needed to save
and load config objects written using Kotlin collection classes, but I
haven't actually validated that.

[1]: https://kotlinlang.org/docs/reference/java-interop.html

> Would you say that an external interface used by Jenkins is a link to a 
> source control management system (eg. GitHub) ?

Yes, though I'd clarify that there are two potential interfaces there:
the git repository itself and webhooks from GitHub (or other similar
SCM hosts). There are even more potential interfaces there, though the
git repository one is a fundamental one as most Jenkins jobs need to
pull data from somewhere continuously, and a git repository is a
natural tool for that.


-- 
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/CAEot4ozS-vFMgNfi7dZ_3%3Duu2rzQYub_kyvxzm3UyOgM-WNUJA%40mail.gmail.com.

Re: Proposal: Jenkins Core PR reviewers team

[Matt Sicker]

ogle 
>>>>>> Groups "Jenkins Developers" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>>> an email to jenkin...@googlegroups.com.
>>>>>> To view this discussion on the web visit 
>>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DusuUMUQuMqXYwbQ6vf%2BqaXgNzT9cg_5M9QYJzh7c%3DVbWg%40mail.gmail.com.
>>>>>>
>>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to a topic in the 
>>>>> Google Groups "Jenkins Developers" group.
>>>>> To unsubscribe from this topic, visit 
>>>>> https://groups.google.com/d/topic/jenkinsci-dev/0sdrcSOQW64/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to 
>>>>> jenkin...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/46d147a4-3f81-4eea-93ad-3a355329eb28%40googlegroups.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 jenkin...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDFMapzJLRGneO1M7aD1ontMYFF-fUDH93Gspp5VfnzBA%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/b2d59f93-4eb5-44fa-a22f-887bbd4b4fff%40googlegroups.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-3BidZpfjF4z6XTF7wEkmGZ%2BnU_%2BZ68FFMwtGnjbcmBieeJA%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/CAPyTVp3gQggh9Xuq7meBPtwhcWQnJ-xx3AN7%2BzsjHKTpn%3DEYhA%40mail.gmail.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/CAEot4owksV0kgNtWVrpbH2930UU1KMA2cf1vNdfT5MYB5io0sA%40mail.gmail.com.

Looking for potential weekend hackathon ideas

[Matt Sicker]

Hi all,

I'll be attending Hack Illinois [1], a weekend-long hackathon focused
on contributing to open source projects. This hackathon is in about a
week, so while this is somewhat late notice, I'm looking for any
suggestions on bugs, features, and other work that might be
appropriate for a university-level audience. The students will range
in skill levels and experience, so I'd like to have a bag of issues or
features that span the complexity spectrum.

[1]: https://www.hackillinois.org/

-- 
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/CAEot4owJZvpGfU-u32dX4AecJ-7w1%3DW%3DJAunPh0uMxrRADz-Jg%40mail.gmail.com.

Re: JEP-225: Folder-based access control for any credentials provider

[Matt Sicker]

ACL is in jenkins-core along with AccessControlled and the other
classes Jesse mentioned.

On Fri, Feb 14, 2020 at 4:59 AM Chris Kilding
 wrote:
>
> I meant the permissions thing which is dotted all around the codebase, and 
> looks like this:
>
> import hudson.security.ACL;
> import org.acegisecurity.Authentication;
>
> public void doSomething(Authentication authentication) {
>   if (ACL.SYSTEM.equals(authentication)) {
> // do something
>   }
> }
>
> The matrix-auth component seems to have a hudson.security package, but I 
> didn’t see the ACL class in it though.
>
> On 13 Feb 2020, at 14:13, Daniel Beck  wrote:
>
>
>
> On Wed, Feb 12, 2020 at 6:50 PM Chris Kilding 
>  wrote:
>>
>> I have encountered the following solutions which seem relevant, but I know 
>> very little about them:
>>
>> - Cloudbees RBAC plugin (commercial)
>> - Role Strategy Plugin
>> - Jenkins permissions system
>
>
> Given the way you wrote up this list, do you mean 
> https://plugins.jenkins.io/matrix-auth with the third item?
>
>
> --
> 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/CAMo7Pt%2B-NWfMV9Qvbr-kPAoBjb%3DgDFTCm4fG3tV1CeUVtHgK5g%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/242E58A5-AE65-416C-B8AD-33E9089046F5%40chriskilding.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/CAEot4oyyapPMFsf4s_nUXOsVfW_p%3DvS67T_j4%3Dnf-2%3DzUT_Y6g%40mail.gmail.com.

Re: PROPOSAL: Remove network discovery services

[Matt Sicker]

On Fri, Jan 31, 2020 at 3:35 AM Amit Dar  wrote:
> As a heavy Swarm Plugin user, I can say we don't use the discovery feature of 
> the plugin, but rather direct the client to a specific master. This is due 
> the fact we have several Jenkins masters in the same network (for testing 
> purposes, mainly). I think the usage of the auto discovery feature is 
> something people use only if they have a single instance of the master in 
> their network, and this might be true only when using jenkins in a 
> "dockerized" network.

Agreed on this regard. I used to use the multicast discovery feature
of Hazelcast long ago when we had only one cluster, but once we added
another cluster that was logically a different environment but still
accessible within the same network, this caused numerous configuration
issues and mixing of caches and other nonsense. I highly suggest
leaving UDP multicast to be used only for video streaming or the other
goals it was originally designed for.

-- 
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/CAEot4oxNGpF6%2Bm7%3DUCbH%3D6N98B18snKOcSr%2BRji0vtn2_cTYBA%40mail.gmail.com.

Re: JENKINS-60897 - worth expanding into a JEP?

[Matt Sicker]

Agreed there. I'd be interested in that JEP.

On Wed, Jan 29, 2020 at 11:47 AM Oleg Nenashev  wrote:
>
> With the current scope of Affected components JEP would be definitely great
>
> On Wednesday, January 29, 2020 at 5:21:20 PM UTC+1, Chris Kilding wrote:
>>
>> I'm currently working out the details of JENKINS-60897, an enhancement to 
>> enable the folders plugin to provide an access control layer over any 
>> credentials provider. This would affect several components (all credential 
>> providers, credentials API, CasC, folders plugin, maybe more). It may also 
>> be relevant to other access control features Jenkins has. Therefore it might 
>> be worth expanding into a JEP.
>>
>> Thoughts?
>
> --
> 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/5758c026-29d1-4339-bb37-b5d5cb8507ca%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/CAEot4oyp_rBxfVOi8EgjB%2B1%2BsV9NqiutJr8D%2BkuGfz13gc_z-g%40mail.gmail.com.

Re: Request to add Marky Jackson as YouTube and twitter admin

[Matt Sicker]

+1

Thanks for all the help, Marky!

On Mon, Jan 20, 2020 at 12:38 PM Tracy Miranda 
wrote:

> +1 for both requests! 
>
> On Mon, Jan 20, 2020 at 9:38 AM Ullrich Hafner 
> wrote:
>
>> +1 for both requests
>>
>> Am 20.01.2020 um 15:34 schrieb Mark Waite :
>>
>> +1 from me.
>>
>> On Mon, Jan 20, 2020 at 7:27 AM Oleg Nenashev 
>> wrote:
>>
>>> I am +1 for both.
>>>
>>>- According to JEP-13, Marky is eligible to get access to the
>>>Jenkins Youtube channel as an Advocacy SIG leader
>>>- Marky has been very active in Twitter recently (twitter account
>>><https://twitter.com/markyjackson5>), and he continuously helps to
>>>promote Jenkins in this resource. Plus, the community would definitely
>>>benefit from Twitter contributors who promote Jenkins & Cloud Native
>>>technology areas
>>>
>>> Best regards,
>>> Oleg Nenashev
>>>
>>> On Monday, January 20, 2020 at 3:20:15 PM UTC+1, Marky Jackson wrote:
>>>>
>>>> Hello all!
>>>> This is a request to add me (Marky Jackson) to the admin of twitter and
>>>> youtube. I have filed the following jira tickets in conjunction with JEP-10
>>>> and JEP-13:
>>>>
>>>> https://issues.jenkins-ci.org/browse/INFRA-2431
>>>> https://issues.jenkins-ci.org/browse/INFRA-2432
>>>>
>>>> The PR for my cla is here:
>>>> https://github.com/jenkinsci/infra-cla/pull/79
>>>>
>>>> Thank you kindly in advance.
>>>>
>>>>
>>>>
>>> --
>>> 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/86e63853-e5fc-4f84-bbdc-284840df88d3%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/86e63853-e5fc-4f84-bbdc-284840df88d3%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> Thanks!
>> 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/CAO49JtFB4e%3DAJKT2e%2B7vGXUjvc-_qFGE1_VqC9jhjFKFZXDtQA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFB4e%3DAJKT2e%2B7vGXUjvc-_qFGE1_VqC9jhjFKFZXDtQA%40mail.gmail.com?utm_medium=email_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/7020EAE9-FEA4-40FF-8BDF-7191F469FF15%40gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/7020EAE9-FEA4-40FF-8BDF-7191F469FF15%40gmail.com?utm_medium=email_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/CACTaz6rn%3DSP9fxya%3D%2BzF6Yd5%3Dqqktd4Poxv2eKq40bcn-D9dgQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CACTaz6rn%3DSP9fxya%3D%2BzF6Yd5%3Dqqktd4Poxv2eKq40bcn-D9dgQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAEot4oyEn9OS8WT-zhFKxrB%3DjwzVTi4ihE4n%3Dc%2BLYbm-6jMasQ%40mail.gmail.com.

Re: Proposal: Implementing sensible fine grained permissions to allow an administer to securely delegate some aspects of jenkins configuration

[Matt Sicker]

That would assuage my concerns significantly.

On Thu, Jan 16, 2020 at 3:43 AM Daniel Beck  wrote:
>
>
>
> On Wed, Jan 15, 2020 at 9:00 PM Matt Sicker  wrote:
>>>
>>> Plugins that contribute to the settings on on the Configure Jenkins page 
>>> should carefully consider if allowing a user with only Jenkins.CONFIGURE 
>>> could result in an unintended privelege escalation.
>>
>>
>> To me, this sounds like a fairly onerous requirement for plugins. Based on 
>> the numerous published security advisories just around plugins not bothering 
>> with a permission check in the first place, this sounds like a fairly large 
>> hole. How could we mitigate that?
>
>
> The difference is that much of that comes from bad (permissive) defaults. 
> This would be opt-in, and with good documentation about security 
> considerations, plugin maintainers will be given the tools to understand 
> whether it makes sense to make this available, or not.
>
> --
> 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/CAMo7PtL5X07BBvtorwR5t8%3DO%3D8mHdGkkX79YqKYrMixoF7yLrw%40mail.gmail.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/CAEot4ow7hyKRDWUK4qB71Y3tsOhMxfkUfM9ZE1%3DaGvpwKpD58Q%40mail.gmail.com.

Re: Happy Holiday

[Matt Sicker]

How do you opt in to the new notifications thing? I'm only opted in to
some code-owners feature right now.

On Wed, Jan 15, 2020 at 1:58 PM Joseph P  wrote:
>
> Here's a crazy thought, use GitHub?
>
> It's a matter of creating appropriate repos and using GitHub issues / pull 
> requests.
>
> For announcement see
> https://github.com/dotnet/announcements/issues
>
> if you need some structure create a repo with the desired content structure.
>
> GitHub can get pretty chatty.
> If your discussing a persisted topic, create pull request, add a review to 
> the topic line and let the thread messaging commence 殺
>
> If you need to chat with your team? Create proper team structure and use 
> GitHub Team Discussion (which atm is currently disabled in most teams 
> https://github.com/orgs/jenkinsci/teams/core )
>
> I do not see a need for a separate channel once GitHub's new notifications is 
> out.
> Totally loving being in the new notifications beta!
>
>
> On Friday, December 27, 2019 at 2:27:40 AM UTC+1, Marky Jackson wrote:
>>
>> The holidays are upon us and it’s time to relax and look back on the year 
>> and at the roadmap for the future.
>> With [gitter being 
>> down](https://twitter.com/gitchat/status/1210326466870882306?s=21) I think 
>> the conversation should be had regarding moving off the archaic (gitter/irc) 
>> communications used for the community and into a more robust form of unified 
>> community bonding.
>> I would love to see the recently nominated board move to standardize, not 
>> only our crumbling infrastructure but also the means by which we communicate.
>> With the CDF integration in the works I would also love to hear more about 
>> how that looks. More so how this community adapts to that new world (and 
>> their use of slack as a communication medium).
>> We had a lot of emails about the integration and board nominations (along 
>> with officers), I personally am eager to hear more about the plans and the 
>> way to make rubber meet the road from all newly elected officials and 
>> returning ones.
>> Happy New Years all and thank you to all the contributors for all the hard 
>> work you put in to this project, I for one am immensely thankful.
>
> --
> 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/0a75cf6f-5ebd-4cdd-8c03-89c87889a65e%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/CAEot4ozvmZFhXDmZASYyA31hoEbn9HWNHRr9BNpBmduZrw5cDw%40mail.gmail.com.

Re: Proposal: Implementing sensible fine grained permissions to allow an administer to securely delegate some aspects of jenkins configuration

[Matt Sicker]

Alright, I have some immediate concerns about the following aspects:

Plugins that contribute to the settings on on the Configure Jenkins page
> should carefully consider if allowing a user with only Jenkins.CONFIGURE
> could result in an unintended privelege escalation.
>

To me, this sounds like a fairly onerous requirement for plugins. Based on
the numerous published security advisories just around plugins not
bothering with a permission check in the first place, this sounds like a
fairly large hole. How could we mitigate that?

On Wed, Jan 15, 2020 at 9:57 AM Matt Sicker  wrote:

> I'll be reviewing this JEP from a security perspective over the next
> couple days.
>
> On Wed, Jan 15, 2020 at 7:02 AM Oleg Nenashev 
> wrote:
>
>> Just to bump this discussion, the JEP draft was published as
>> https://github.com/jenkinsci/jep/tree/master/jep/223
>> Any feedback would be appreciated, there were changes since the last post
>> in this thread
>>
>>
>> Best regards,
>> Oleg Nenashev
>>
>>
>> On Friday, December 27, 2019 at 8:30:30 PM UTC+1, Michael Cirioli wrote:
>>>
>>> As part of this proposal we have been struggling a bit to find the right
>>> "name" to describe this new permission type. Currently, we are thinking
>>> about creating a new Permission Group called Restricted Administer in
>>> order to provide some contextual meaning to the permissions it contains.
>>> Initially there will be only the proposed permission, Configure, but
>>> there are a number of other potentially similar permission types that would
>>> fit in this category as well (although not in scope for this JEP). Below is
>>> a screenshot to help illustrate what we are considering.
>>>
>>>
>>>
>>> *note: the additional permissions shown below are just to help make the
>>> picture a bit more clear. TBD how permissions like Read Only will work in
>>> conjunction with others, etc. The primary focus is on deciding on the
>>> terminology to best describe these types of permissions in generally*
>>>
>>> [image: permission_idea.png]
>>>
>>>
>>>
>>>
>>> On Monday, November 18, 2019 at 9:57:29 PM UTC-5, Michael Cirioli wrote:
>>>>
>>>> Dear Everyone,
>>>>
>>>> Myself (https://github.com/mikecirioli), Angelique Jard (
>>>> https://github.com/aHenryJard), and Esther Feijoo (
>>>> https://github.com/EstherAF) would like to offer a proposed JEP
>>>> (currently, still a draft) focused on creating a more sensible set of
>>>> fine-grained permissions for supporting Jenkins administrators who would
>>>> like to delegate the management of certain aspects of a Jenkins instance in
>>>> a secure manner.
>>>>
>>>> Currently, when using matrix style authorization, an administrator may
>>>> choose to selectively remove the ability for a user to RUN_SCRIPTS,
>>>> UPLOAD_PLUGINS, or CONFIGURE_UPDATECENTER.  At first glance, this may seem
>>>> reasonable, but any user with one of these permissions must also have been
>>>> granted ADMINISTER.  If a user has been granted ADMINISTER, they can also
>>>> grant themselves any of the other permission types.  Furthermore, this
>>>> behavior may not be intuitive to all administrators, resulting in
>>>> inadvertently granting more access to a user when the intent was to
>>>> actually limit their access.
>>>>
>>>> We propose deprecating the permission types RUN_SCRIPTS,
>>>> UPLOAD_PLUGINS, and CONFIGURE_UPDATECENTER, to be replaced with the
>>>> existing ADMINISTER permission (which they effectively are, or easily allow
>>>> a sneaky user to elevate themselves to).  Additionally, we want to
>>>> introduce a new permission type, CONFIGURE_JENKINS, with the intent of
>>>> seperating configuration elements that do not allow a user to escalate
>>>> beyond what was given to them from those that impact security on a global
>>>> level.
>>>>
>>>> This means that access to configuration urls such as
>>>> /configureSecurity/, /configureTools/,  and /pluginManager/, etc, as well
>>>> as certain elements under /configure/, would only be visible/accessible to
>>>> users who have explicitly been granted the ADMINISTER permission.  Other
>>>> configuration urls and elements would be accessible to users who have been
>>>> granted the lesser permission of CONFIGURE_JENKINS (which would also be
>>>&g

Re: Proposal: Implementing sensible fine grained permissions to allow an administer to securely delegate some aspects of jenkins configuration

[Matt Sicker]

/github.com/mikecirioli/jenkins/tree/FGP (along with continuing
>>> work via PRs at
>>> https://github.com/mikecirioli/jenkins/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc
>>> )
>>>
>>> thanks, we look forward to discussion and feedback about this proposal!
>>>
>>> -mike cirioli
>>>
>>> --
> 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/7c9ba96b-1626-4af1-9964-bdad58bbb453%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/7c9ba96b-1626-4af1-9964-bdad58bbb453%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAEot4ow_k659Cbpo4N_7HgbmM%2B4pLeXU%3D9pegmkwu5ef5YrjkQ%40mail.gmail.com.

Re: ANN: Removal of old, unsupported agent protocols

[Matt Sicker]

I love deleting deprecated code, so big +1 from me. I especially like
the emphasis on always using an encrypted+authenticated connection for
remoting to ensure that users will have a properly secure experience
out of the box.

On Sat, Jan 11, 2020 at 2:27 PM Oleg Nenashev  wrote:
>
> Thanks a lot to Jeff for this update and for the hard work he is doing to 
> maintain Jenkins Remoting! Even in 2020 it remains one of the most critical 
> parts of the Jenkins ecosystem, and it is essential to the project to keep 
> the component up to date. And to keep it secure, of course.
>
> Just to provide some context here, the removal of this protocols was 
> discussed in the user mailing list (here).
> Although it is not the best channel for such discussions, I believe the 
> removal is well justified.
>
> JNLP1..3 protocols were announced as deprecated more than 2 years ago (Aug 
> 2017, announcement blogpost)
> Although we recommend disabling the protocols && disable them by default on 
> new instances, we still some instances using the old protocols as a fallback 
> when Jenkins is misconfigured
> JNLP1 and JNLP2 are not encrypted, which allows various kinds of channel 
> sniffing attacks on instances which do not disable protocols (protocol 
> downgrade from encrypted JNLP4 to unencrypted JNLP2)
> JNLP3 is just unstable, JNLP1/2 have known stability issues. They have not 
> been supported since the deprecation announcement, except a number of bugfixes
> With the WebSocket support in JEP-222, there will be more protocols to 
> maintain. Getting rid of deprecated and unstable protocols redues the 
> maintenance overhead
>
> There are some consequences to keep in mind:
>
> Remoting 3.40 does not longer support Jenkins versions before 2.32, and for 
> 2.32 special flags need to be set (JNLP4 protocol was in Beta)
> New versions old jenkins/slave and jenkins/jnlp-slave Docjer images will not 
> not support old Jenkins versions either (we should finally rename these 
> images...)
> The change formally breaks the binary compatibility in the core though we are 
> not aware about any real use-case when it gets impacted. Wrappers like 
> ruby-runtime and jenkins.py are usual suspects, but I am not sure they are 
> operational in any case for recent versions
>
> Best regards,
> Oleg Nenashev
> // also a former Remoting maintainer
>
>
>
> On Friday, January 10, 2020 at 7:33:33 PM UTC+1, Jeff Thompson wrote:
>>
>> Hi,
>>
>> For historical reasons, Jenkins has still shipped with old, deprecated 
>> protocols, JNLP1-connect, JNLP2-connect, and JNLP3-connect. These are also 
>> known currently as Inbound TCP Agent Protocol/1, Inbound TCP Agent 
>> Protocol/2, and Inbound TCP Agent Protocol/3. These all have fundamental 
>> issues and known bugs. They were all superseded by the JNLP4-connect 
>> protocol released in Jenkins 2.27 over three years ago (October 2016). They 
>> have all been deprecated and unsupported since Jenkins 2.75 over two years 
>> ago. Since then there have been UI messages and an administrative monitor 
>> strongly discouraging their use. (See more information about the protocols 
>> at https://github.com/jenkinsci/remoting/blob/master/docs/protocols.md )
>>
>> We have been discussing plans to remove these old protocols in various 
>> places, including the Users list and a couple of PRs. This removal is in 
>> process with major steps occurring now.
>>
>> These protocols were removed from Remoting 3.40, released two weeks ago.
>> On the Jenkins master side, the changes were integrated towards Jenkins 
>> 2.214 weekly. ETA is next Monday. The next LTS baseline is expected to have 
>> the protocols removed as well.
>> Jenkins docker agent image updates are in process. ETA is next Monday.
>> Swarm Plugin Client is updated, but we need a release.
>>
>> Jeff
>
> --
> 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/0a4ec6f4-78f1-4db7-b6b4-da225373874a%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/CAEot4oy1p%3DNu%3Dn5CMGufgrZ6k5bbj5ec9-61KMRockYtYMSLBw%40mail.gmail.com.

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

[Matt Sicker]

Sounds like an interesting project idea. For inspiration on UI, would this
be similar to, say, https://start.spring.io/ ?

On Wed, Jan 8, 2020 at 8:49 AM Rick  wrote:

> Hi team,
>
> I'd like to share an idea with you. There are some original discussions
> from the GSoC thread
> <https://groups.google.com/d/msgid/jenkinsci-gsoc-all-public/36332f60-e8f0-4cc0-a37d-642990c824d9%40googlegroups.com?utm_medium=email_source=footer>
> here.
>
> For many users, they download Jenkins first, then select some plugins and
> config them. It might take a lot of time, like hours. But if we can get a
> perfect Jenkins distribution which contains all we need, it can save that
> time for us. Yes, I propose an out of the box solution.
>
> The service could be like this, a website offered as
> https://customize.jenkins.io. Plus, it should be self-host. People can
> select the following configurations:
>
>- Jenkins core version
>- plugins
>- common configuration, user/password, update-center site e.g.
>- plugin based configuration, Kubernetes, Sonarqube plugin config e.g.
>- multi-form package, jenkins.war or docker image
>- other things
>
> Two projects are expected backend and frontend. I think
> https://github.com/jenkinsci/custom-war-packager already did a lot of
> works. We can reuse it in this project. The backend should provide the
> modern Restful API. We can start the backend project with SpringBoot, it
> can save a lot of time.
>
> About the frontend project, I don't have too many experiences on it. For
> example, we can start it by React framework. If you're instrested in it,
> please help to add more ideas on it.
>
> Any feedbacks are very appreciated.
>
> Best regards,
> Rick
> --
> Zhao Xiaojie (Rick)
> Blog: https://github.com/LinuxSuRen
> Twitter: https://twitter.com/suren69811254
>
> --
> 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/CAMM7nTFs-%3DeBOnFeTthXmViVzeBdbPCkNP%3DXn3Mq2-97zoFvQQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFs-%3DeBOnFeTthXmViVzeBdbPCkNP%3DXn3Mq2-97zoFvQQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


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

Re: Jenkins Plugin Error

[Matt Sicker]

I think you need to add an index.jelly file for that URL. If you
already have one, can you paste its contents?

On Mon, Dec 23, 2019 at 4:11 PM 'Gavin Mogan' via Jenkins Developers
 wrote:
>
> You havn't really given us very much to work with. At least seeing the code 
> we could make a shot at this.
>
> Did you confirm your run has the action (look at the xml file)
> What url did you try to hit? Looks like /job/testProject/4/greeting but want 
> to confirm
>
> Did you define getUrlName() to something like the tutorials/error message 
> suggested?
>
> Gavin
>
>
> On Mon, Dec 23, 2019 at 5:24 AM wla  wrote:
>>
>> Hello,
>>
>> if i follow this tut :
>> https://jenkins.io/doc/developer/tutorial/extend/
>> i get the following error
>> Stapler processed this HTTP request as follows, but couldn't find the 
>> resource to consume the request
>>
>> -> evaluate( 
>> :hudson.model.Hudson,"/job/testProject/4/greeting")
>> -> 
>> evaluate(((StaplerProxy)).getTarget(),"/job/testProject/4/greeting")
>> -> evaluate(.getJob("testProject"),"/4/greeting")
>> -> evaluate( 
>> :hudson.model.FreeStyleProject,"/4/greeting")
>> -> 
>> evaluate(((StaplerProxy)).getTarget(),"/4/greeting")
>> -> 
>> evaluate(.getDynamic("4",...),"/greeting")
>> -> evaluate( :hudson.model.FreeStyleBuild,"/greeting")
>> -> evaluate(((StaplerProxy)).getTarget(),"/greeting")
>> -> evaluate(.getDynamic("greeting",...),"")
>> -> evaluate( 
>> :io.jenkins.plugins.sample.HelloWorldAction,"")
>> -> No matching rule was found on 
>>  for ""
>>
>>  has the following URL 
>> mappings, in the order of preference:
>>
>> If path ends without '/' insert it
>> TOKEN.groovy for url=/TOKEN
>> VIEW.jelly for url=/VIEW
>> BLOCKED: java.lang.String 
>> io.jenkins.plugins.sample.HelloWorldAction.getDisplayName() for 
>> url=/displayName/...
>> BLOCKED: java.lang.String 
>> io.jenkins.plugins.sample.HelloWorldAction.getIconFileName() for 
>> url=/iconFileName/...
>> BLOCKED: java.lang.String 
>> io.jenkins.plugins.sample.HelloWorldAction.getUrlName() for url=/urlName/...
>> BLOCKED: java.lang.Class java.lang.Object.getClass() for url=/class/...
>> BLOCKED: java.lang.String 
>> io.jenkins.plugins.sample.HelloWorldAction.getName() for url=/name/...
>>
>> have someon a similar issue ?
>> Or better a solution?
>>
>> --
>> 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/41d6fcd1-7721-4191-b6a0-2e825fd575ee%40googlegroups.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/CAG%3D_Dut6cb9_SWnAmuw0yAhLh%2BXjxc4s7merm2d7DVz5KxMVhA%40mail.gmail.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/CAEot4ozagS1CPnZFkJbcVqi51iwF7E7w5sH%2BSVS_8pJq3RxS6g%40mail.gmail.com.

Re: Happy Holiday

[Matt Sicker]

>>
>>>>>> The other nice thing is keybase is well integrated to github too :)
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Will
>>>>>>
>>>>>> On Thu, Dec 26, 2019 at 17:41 'Gavin Mogan' via Jenkins Developers 
>>>>>>  wrote:
>>>>>>>
>>>>>>> I would be very much against yet another slack i'd have to join. 
>>>>>>> Especially cause its a closed system, requiring invites to join. Its 
>>>>>>> certainly why i havn't bothered looking into the jenkins-ux sig.
>>>>>>>
>>>>>>> Gitter is nice because everything is public and googleable, you only 
>>>>>>> need a github account, which is the minimum you'd need to contribute to 
>>>>>>> any of the jenkins systems anyways. Though gitter is pretty abandoned, 
>>>>>>> and I would prefer IRC, especially with a public logging bot.
>>>>>>>
>>>>>>> Gavin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 26, 2019 at 5:27 PM Marky Jackson  
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> The holidays are upon us and it’s time to relax and look back on the 
>>>>>>>> year and at the roadmap for the future.
>>>>>>>> With [gitter being 
>>>>>>>> down](https://twitter.com/gitchat/status/1210326466870882306?s=21) I 
>>>>>>>> think the conversation should be had regarding moving off the archaic 
>>>>>>>> (gitter/irc) communications used for the community and into a more 
>>>>>>>> robust form of unified community bonding.
>>>>>>>> I would love to see the recently nominated board move to standardize, 
>>>>>>>> not only our crumbling infrastructure but also the means by which we 
>>>>>>>> communicate.
>>>>>>>> With the CDF integration in the works I would also love to hear more 
>>>>>>>> about how that looks. More so how this community adapts to that new 
>>>>>>>> world (and their use of slack as a communication medium).
>>>>>>>> We had a lot of emails about the integration and board nominations 
>>>>>>>> (along with officers), I personally am eager to hear more about the 
>>>>>>>> plans and the way to make rubber meet the road from all newly elected 
>>>>>>>> officials and returning ones.
>>>>>>>> Happy New Years all and thank you to all the contributors for all the 
>>>>>>>> hard work you put in to this project, I for one am immensely thankful.
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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 jenkin...@googlegroups.com.
>>>>>>>> To view this discussion on the web visit 
>>>>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/139A5221-5B88-4B8E-A96A-39D399587D0F%40gmail.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 jenkin...@googlegroups.com.
>>>>>>> To view this discussion on the web visit 
>>>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DutWqTvR%3DAYwGcHUW10fGNj-OjV4NX06Kcj9%2BZP4PY%2BMFA%40mail.gmail.com.
>>>>>>
>>>>>> --
>>>>>> William Hetherington
>>>>>> w - opschops.ca
>>>>>> t - @wmwh
>>>>>>
>>>>>> --
>>>>>> 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 jenkin...@googlegroups.com.
>>>>>> To view this discussion o

Re: Proposal: Official Docker Image maintenance team (Jenkins and Agents)

[Matt Sicker]

+1 to this idea and initial maintainers. This would go a long way
toward unblocking changes in this area! :)

On Tue, Dec 10, 2019 at 7:42 AM Marky Jackson  wrote:
>
> I have not been as active as I would like but I would also like to be a 
> maintainer based on our previous conversation
>
> On Dec 10, 2019, at 3:34 AM, Oleg Nenashev  wrote:
>
> 
> BTW, I suggest the following list of maintainers based on the recent activity:
>
> Mark Waite
> Alex Earl
> Carlos Sanchez
> Oleg Nenashev
> Baptiste Mathus
> Olivier Vernin
>
> Alternative is to just keep all members of 
> https://github.com/orgs/jenkinsci/teams/docker/members though some 
> contributors are not active at the moment
>
> BR, Oleg
>
> On Tuesday, December 10, 2019 at 11:42:49 AM UTC+1, Mark Waite wrote:
>>
>> I would like that very much
>>
>> On Tue, Dec 10, 2019, 11:19 AM Oleg Nenashev  wrote:
>>>
>>> Hi all,
>>>
>>> Right now we have a number of official packages for Docker:
>>>
>>> https://github.com/jenkinsci/docker
>>> https://github.com/jenkinsci/docker-slave
>>> https://github.com/jenkinsci/docker-ssh-slave
>>> https://github.com/jenkinsci/docker-jnlp-slave
>>> https://github.com/jenkinsci/jnlp-agents
>>>
>>> All these repositories have different teams which define permissions/. In 
>>> addition to that we have jenkinsci/docker and 
>>> jenkinsci/docker-packaging-team team which also grant permissions. It is 
>>> quite difficult to manage the repositories in the current state, and it is 
>>> difficult to request reviews.
>>>
>>> I suggest to keep things simple and just proceed with a single team for the 
>>> official packaging:
>>>
>>> Introduce an official "docker-packaging-team" under umbrella of Platform 
>>> Special Interest group which currently manages Docker packaging
>>> Cleanup existing teams, leave just one for all official Jenkins master and 
>>> agent mages. Plugin Docker packaging (e.g. Remoting over Apache Kafka, 
>>> Swarm plugin) will not be affected
>>> Update GitHub and DockerHub teams to reflect the changes (mostly 
>>> jenkins4eval which grants write permissions)
>>> Add new team to CODEOWNERS in all repos
>>>
>>> WDYT?
>>>
>>> Thanks in advance,
>>> 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 jenkin...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCPBvAvsqC4nqpr2e%2BqBOo2BdMqa%3DY5%3Dx%2BhVO735YzX_w%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/d333d077-28bb-431f-9f5a-950440970429%40googlegroups.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/11566D48-9955-40F5-B5EA-75CAEB228589%40gmail.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/CAEot4oxKYCkyCgnqxkxR0A%2BaDk%3Dbj0krcd-xAteAE-r1z-QK%3Dg%40mail.gmail.com.

Re: Check if agent is running as a service

[Matt Sicker]

A low tech workaround for this would be using node labels to define
which nodes have the graphical environment and which ones don't.

On Fri, Dec 6, 2019 at 4:05 AM Adakar  wrote:
>
> Hi Daniel,
>
> Thanks for the explanation and pointing this out :)
>
> Bingo! The access to a display is mandatory for the plugin to be executed 
> succesfully. That's exactly the reason why I wanted the plugin to stop the 
> execution if the agent is running as a service. Although information if it is 
> a service or not might still be useful for more detailed output.
>
>
> W dniu czwartek, 5 grudnia 2019 11:57:53 UTC+1 użytkownik Daniel Beck napisał:
>>
>>
>>
>> On Thu, Dec 5, 2019 at 11:26 AM Adakar  wrote:
>>>
>>> My intention is to customize a plugin behavior based on the fact if the 
>>> agent is running as a service. If it does, it should stop the build. If 
>>> not, the build should be continued. I simply want my plugin to stop builds 
>>> which are executing on agents that are running as a Windows Service.
>>
>>
>> That looks a bit like an XY problem (http://xyproblem.info/), if so, it 
>> would be helpful if you could provide additional context.
>>
>> For example, if there's something preventing builds run from a Windows 
>> service to be completed successfully (e.g. no desktop access) in your 
>> environment, perhaps you can check for that directly rather than trying to 
>> identify whether you're running as a service?
>
> --
> 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/a1563dfd-f5f7-4e8a-9cc5-c0b46c322e82%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/CAEot4oyOOwhrLv%2BzRBa3WiX2tKQXHmcHt6ubtHQG_rfM-Css9A%40mail.gmail.com.

Re: How to restrict no of builder

[Matt Sicker]

You're likely looking for this plugin:
https://plugins.jenkins.io/throttle-concurrents

The jenkins user mailing list would be likely to get more detailed answers.

On Thu, Nov 28, 2019 at 12:48 AM selva vignesh
 wrote:
>
> Hi Team,
> I have written plugin that actually make a apicall to my internal product. 
> Where I have to restrict number builder not being added more than 10.
> Is this possible? if so, please let me know. It would be great, having sample 
> code snippet.
> Thanks in advance.
>
> --
> 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/95a267da-b7b4-45b4-9953-129330797a96%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/CAEot4ozTdtiwUQG7R3WgAY%2BagCmKAG_bchAahDA8CSzbpx5fkg%40mail.gmail.com.

Re: How to consume incrementals?

[Matt Sicker]

If you change your IntelliJ config to delegate to Maven rather than
using its own build code, most of these Maven-specific extensions work
fine (I've had to do that with Maven projects that rely heavily on
Maven toolchain support for example).

On Thu, Nov 28, 2019 at 5:04 PM Joseph P  wrote:
>
> https://github.com/JetBrains/intellij-community/blob/fecfdd52f426cf1b2770edee7dc9d9ecab692441/plugins/maven/maven3-server-common/src/org/jetbrains/idea/maven/server/Maven3ServerEmbedder.java#L80
>
> So close but no cigar
>
> On Tuesday, November 26, 2019 at 4:26:32 PM UTC+1, Jesse Glick wrote:
>>
>> On Mon, Nov 25, 2019 at 8:45 PM James Nord  wrote:
>> >> IntelliJ simply does not read maven.config
>> >
>> > That's a shame.
>>
>> Uh, is it not open source (at least the core part)? I fixed this bug
>> for NetBeans. Granted, I had a head start in that case.
>
> --
> 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/66ee9eef-f892-4adf-859d-c2ef2c0ed576%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/CAEot4owULgWyDkdS9U_N%3DYT0M93AxQK%2BH__Q-DmurQbOoPd-2Q%40mail.gmail.com.

Re: Proposal: Jenkins Browser Support policy updates

[Matt Sicker]

FWIW, I've written any new JS/HTML/CSS according to caniuse.com and their
base line supported level, though that might be fairly conservative (not as
conservative as the current Jenkins wiki, though!)

On Fri, Nov 15, 2019 at 8:15 AM Daniel Beck  wrote:

> I think Firefox ESR would make sense to support as well. Its baseline is
> never older than a year IIUC, so should be feasible to have it be
> considered supported.
>
> Showing warnings on the UI when using an unsupported browser would
> probably be fairly straightforward as well, and help to inform users.
> Perhaps we even distinguish between "outdated based on policy" and
> "outdated based on features actually used in core or popular plugins", but
> that may end up being too much effort to maintain.
>
>
> Does it actually make sense to still support IE?
>
> On Fri, Nov 15, 2019 at 10:17 AM Oleg Nenashev 
> wrote:
>
>> Hi all,
>>
>> There was recently a question about Jenkins browser support policy raised
>> in the chats. Currently the policy is hosted on Wiki (here
>> <https://wiki.jenkins.io/display/JENKINS/Browser+Compatibility+Matrix>),
>> and the policy looks to be REALLY old. E.g. we say that Safari 6+ are fully
>> supported, ouch. It does not look like we had any major changes since the
>> inception of the policy in 2014. I have created a pull reques
>> <https://github.com/jenkins-infra/jenkins.io/pull/2649>t to move the
>> policy to jenkins.io, and I would like to make some changes to actualize
>> it.
>>
>> What do I propose?
>>
>>- Chrome, Firefox, IE, Safari
>>   - Level 1:
>>  - "Latest regular release, latest minor release / patch level"
>>   - Level 2:
>>  - Previous patches of the latest regular release
>>  - Latest minor release / patch level  for the "Version -1"
>>   - Level 3:
>>  - All other versions
>>   - Other browsers, including mobile versions, Chromium, Microsoft
>>EDGE, etc.:
>>   - Level 2: Latest regular release, latest minor release / patch
>>   level
>>   - Level 3: All other versions
>>
>>
>> This policy should be somewhat aligned with the current ATH state. IIUC
>> we test only Firefox now, and there is a PR by Oliver Gondza to run tests
>> on Chrome instead (here
>> <https://github.com/jenkinsci/acceptance-test-harness/pulls>)
>>
>> WDYT?
>>
>> 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-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/976db98b-75be-4e29-9bd4-d5fe6676c674%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/976db98b-75be-4e29-9bd4-d5fe6676c674%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
>
> Daniel Beck
> Senior Software Engineer
> CloudBees, Inc.
>
> [image: CloudBees-Logo.png]
>
>
> --
> 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/CAMo7PtKGPEqv9gaVT%2BX%3DoXT%2Busp3RhA%3DfBgcHaWD0hrt8MPdaQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKGPEqv9gaVT%2BX%3DoXT%2Busp3RhA%3DfBgcHaWD0hrt8MPdaQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


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

Re: 2019 Elections: voting is delayed

[Matt Sicker]

oups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4zGX0zaavFELOovrbtr%3DoefOXrTEKDan-Mu2Z4TMTOYcA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4zGX0zaavFELOovrbtr%3DoefOXrTEKDan-Mu2Z4TMTOYcA%40mail.gmail.com?utm_medium=email_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/C1A88166-BF41-40A3-8A7F-BA0B2380192D%40gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/C1A88166-BF41-40A3-8A7F-BA0B2380192D%40gmail.com?utm_medium=email_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/c25c90d8-905a-49aa-a75a-d2575a6480fd%40www.fastmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/c25c90d8-905a-49aa-a75a-d2575a6480fd%40www.fastmail.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Zhao Xiaojie (Rick)
> Blog: https://github.com/LinuxSuRen
> Twitter: https://twitter.com/suren69811254
>
> --
> 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/CAMM7nTEpkrbSiATjvS0KmJNfMn%3D4csq34ny21q8xi2gQGUrnBQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTEpkrbSiATjvS0KmJNfMn%3D4csq34ny21q8xi2gQGUrnBQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 
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/CAEot4owAATtPHkySC-Vmq3%3DEBZz-gAiBisej-u-6-nXsPLb_1w%40mail.gmail.com.