Re: Accelerated end of life for Red Hat Enterprise Linux 7, CentOS 7, etc.

['Gavin Mogan' via Jenkins Developers]

I can't wait for the forum posts "Jenkins says my OS is bad, how do i fix?"

On Thu, May 25, 2023 at 4:16 PM Mark Waite 
wrote:

> Jenkins 2.407 will be the first weekly release to warn users about
> operating system end of life.  Warnings will be displayed immediately for:
>
> * Alpine Linux 3.14
> * CentOS Linux 7
> * Oracle Linux 7
> * Red Hat Enterprise Linux 7
> * Scientific Linux 7
> * Ubuntu Linux 18.04
>
> The next LTS baseline (after 2.401.x) will include the warning.
>
> 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/47488417-5e36-4995-9d3b-6fbed01f0b6dn%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_DutPWSZW7f5EwroUy5NrpznTw7xqYXi0KsTda%3Da4Twq-5w%40mail.gmail.com.

Re: Accelerated end of life for Red Hat Enterprise Linux 7, CentOS 7, etc.

[Mark Waite]

Jenkins 2.407 will be the first weekly release to warn users about 
operating system end of life.  Warnings will be displayed immediately for:

* Alpine Linux 3.14
* CentOS Linux 7
* Oracle Linux 7
* Red Hat Enterprise Linux 7
* Scientific Linux 7
* Ubuntu Linux 18.04

The next LTS baseline (after 2.401.x) will include the warning.

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/47488417-5e36-4995-9d3b-6fbed01f0b6dn%40googlegroups.com.

Re: Jenkins 2.401.1 RC testing has started

[Mark Waite]

On Thursday, May 25, 2023 at 4:19:17 PM UTC-6 Alexander Brandes wrote:

Hey,

Thanks for spotting! I created a draft including both changes mentioned: 
https://github.com/jenkinsci/jenkins/pull/8051

~ Alex


I think it would be better to 
revert https://github.com/jenkinsci/jenkins/pull/7084 based on the results 
from git bisect.

Sorry that I didn't detect that during interactive testing the last 10 
days.  2.401-rc has been very well behaved for me in all of my use of it.  
I'll look more carefully in case there are other surprises.

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/e4782d35-405e-49d6-bdde-197d1aeedabfn%40googlegroups.com.

Re: Jenkins 2.401.1 RC testing has started

[Alexander Brandes]

Hey,

Thanks for spotting! I created a draft including both changes mentioned: 
https://github.com/jenkinsci/jenkins/pull/8051

~ Alex

On Thursday, 25 May 2023 at 23:35:31 UTC+2 cc...@cloudbees.com wrote:

> Created https://issues.jenkins.io/browse/JENKINS-71345 for tracking.
>
> On Thursday, May 25, 2023 at 5:32:12 PM UTC-4 Cathy Chan wrote:
>
>> We just observed that the entries in the dropdown of `Manage Jenkins` -> 
>> `Configure System` all have trailing "undefined".
>>
>> This has been fixed on 2.403, apparently as a side effect of 
>> https://github.com/jenkinsci/jenkins/pull/7474 and 
>> https://github.com/jenkinsci/jenkins/pull/7887. Should we consider a 
>> backport?
>>
>> - Cathy.
>>
>>
>> On Wednesday, May 17, 2023 at 5:13:25 AM UTC-4 mc.ca...@gmail.com wrote:
>>
>> Hello everyone,
>>
>> Latest LTS RC was made public, and it is ready to be tested. Final 
>> release is scheduled for 2023-05-31.
>>
>> Please report your findings in this thread.
>>
>> Download the release from: 
>> https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-war/2.401.1-rc33562.17c1c4c32750/jenkins-war-2.401.1-rc33562.17c1c4c32750.war
>>
>> Best regards,
>> Alex
>>
>>

-- 
You received this message because you are 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/84bffcbb-7510-4c60-a018-c2685dd86faan%40googlegroups.com.

Re: Jenkins 2.401.1 RC testing has started

['Cathy Chan' via Jenkins Developers]

Created https://issues.jenkins.io/browse/JENKINS-71345 for tracking.

On Thursday, May 25, 2023 at 5:32:12 PM UTC-4 Cathy Chan wrote:

> We just observed that the entries in the dropdown of `Manage Jenkins` -> 
> `Configure System` all have trailing "undefined".
>
> This has been fixed on 2.403, apparently as a side effect of 
> https://github.com/jenkinsci/jenkins/pull/7474 and 
> https://github.com/jenkinsci/jenkins/pull/7887. Should we consider a 
> backport?
>
> - Cathy.
>
>
> On Wednesday, May 17, 2023 at 5:13:25 AM UTC-4 mc.ca...@gmail.com wrote:
>
> Hello everyone,
>
> Latest LTS RC was made public, and it is ready to be tested. Final release 
> is scheduled for 2023-05-31.
>
> Please report your findings in this thread.
>
> Download the release from: 
> https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-war/2.401.1-rc33562.17c1c4c32750/jenkins-war-2.401.1-rc33562.17c1c4c32750.war
>
> Best regards,
> Alex
>
>

-- 
You received this message because you are 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/ec62a21c-aa3d-44fa-9c36-af280a66522an%40googlegroups.com.

Re: Jenkins 2.401.1 RC testing has started

['Cathy Chan' via Jenkins Developers]

We just observed that the entries in the dropdown of `Manage Jenkins` -> 
`Configure System` all have trailing "undefined".

This has been fixed on 2.403, apparently as a side effect 
of https://github.com/jenkinsci/jenkins/pull/7474 
and https://github.com/jenkinsci/jenkins/pull/7887. Should we consider a 
backport?

- Cathy.


On Wednesday, May 17, 2023 at 5:13:25 AM UTC-4 mc.ca...@gmail.com wrote:

Hello everyone,

Latest LTS RC was made public, and it is ready to be tested. Final release 
is scheduled for 2023-05-31.

Please report your findings in this thread.

Download the release from: 
https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-war/2.401.1-rc33562.17c1c4c32750/jenkins-war-2.401.1-rc33562.17c1c4c32750.war

Best regards,
Alex

-- 
You received this message because you are 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/6ecdc1ad-600f-4be3-9ab3-a8379199dc77n%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Basil Crow]

In addition to what Mark wrote, I would want to see some of our top
open-source Gradle-based Jenkins plugins (e.g., Gradle, Terraform,
Checkmarx, Jira Trigger, etc.) upgraded to use the latest
gradle-jpi-plugin toolchain, a recent LTS release as the Jenkins core
baseline, and a recent plugin Bill of Materials (BOM) and inspect the
resulting JPI that is produced to ensure it is up to parity with a JPI
produced with the maven-hpi-plugin toolchain (e.g., equivalent
manifest entries, equivalent compiler options, etc). Right now, most
of the abovementioned plugins are using an ancient Jenkins core
baseline and an ancient plugin Bill of Materials (BOM), which does not
speak to the viability of the gradle-jpi-plugin toolchain.

In general the gradle-jpi-plugin toolchain needs to be at feature
parity with the maven-hpi-plugin toolchain before we could accept new
plugin hosting requests. That means, in addition to what Mark
described, that every feature in jenkinsci/plugin-pom and
jenkinsci/maven-hpi-plugin should have an equivalent in
gradle-jpi-plugin, including Java 11/17 support for running unit
tests, integration with the latest versions of JUnit/Mockito/Hamcrest
out-of-the-box, opt-in code formatting using our project-wide Spotless
configuration, equivalents to our Maven Enforcer rules, etc. Since I
am constantly adding new features to plugin-pom/maven-hpi-plugin, this
implies a commitment to proactively follow such development and
sideport the same features to the gradle-jpi-plugin toolchain as they
are introduced.

-- 
You received this message because you are 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/CAFwNDjqW5tWqrOGTzmLc5641Q%2BCm19-xzzrzB13K09j5rtzkJA%40mail.gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Mark Waite]

On Thursday, May 25, 2023 at 9:07:41 AM UTC-6 at...@gradle.com wrote:

Thanks for the quick answer!

On Thursday, May 25, 2023 at 3:16:30 PM UTC+2 Mark Waite wrote:

On Thursday, May 25, 2023 at 6:09:42 AM UTC-6 you wrote:

Hi,
lately I've been working on improving the Gradle support for building 
Jenkins plugins, see 
https://github.com/jenkinsci/gradle-jpi-plugin/issues/213 for more details


Thanks for doing that.
 

The latest JPI plugin release 0.49.0 and recent changes on the 
pipeline-library (https://github.com/jenkins-infra/pipeline-library/pull/654 
and https://github.com/jenkins-infra/pipeline-library/pull/652) enable 
quality checks and incremental builds on ci.jenkins.io. Where can we 
document this and would it be ok to re-enable Gradle support ?


https://github.com/jenkinsci/gradle-jpi-plugin/issues/213#issue-1499881868 
indicates the following reasons that the hosting team started rejecting new 
hosting requests for plugins built with Gradle:


   - No support for JEP-229 
   
   - No support for JEP-305 
   
   - Lacking end-user documentation on jenkins.io 
   
   - No support for publishing static analysis and coverage reports on 
   ci.jenkins.io
   - No support for building on ACI (Azure Container Instance) agents
   - Suspect to produce invalid pom.xml files causing issues with third 
   parties and the update center in the past


You noted that the second bullet (JEP-305 - incremental builds) is now 
supported and that the fourth bullet (quality checks) are now supported and 
that the first bullet (JEP-229 - automated release / continuous delivery) 
is not supported.

Are you willing to create end user documentation on jenkins.io for those 
who use Gradle?

Sure, I can start a dedicated page with what we have and enrich later (see 
below)
 


I'm not a member of the hosting team, but I think they will want to be 
assured that Jenkins plugins can be successfully maintained and released 
using Gradle.
 

One thing I've noticed though is that the cd release with Gradle would not 
be supported by the dedicated Github action. I wonder if it worth 
supporting, since I don't see it used by a lot of plugins currently: 
https://github.com/search?q=org%3Ajenkinsci%20%22maven-cd.yml%40v1%22%20path%3A*.yml=code.
 
What do you think ?


Your query is not showing you how widely the automated release process is 
used.  

https://github.com/search?q=repo%3Ajenkins-infra%2Frepository-permissions-updater+%22cd%3A%22=code
 
shows that 340 repositories have enabled automated release. 

My understanding of 
https://www.jenkins.io/doc/developer/publishing/releasing-cd/ is that this 
step will just set the Maven repository credentials as secrets on the 
relevant Github repository.
The actual continuous release will happen only if using 
https://raw.githubusercontent.com/jenkinsci/.github/master/workflow-templates/cd.yaml,
 
or am I missing something ? People maybe just have their own workflow using 
credentials to publish ?
 


I can't explain why that query does not accurately show the contents of the 
jenkinsci repositories, but I'm confident that it does not.  I see over 200 
references to maven-cd.yml in files that are named either cd.yml or cd.yaml 
in the .github/workflows directories of repositories in the jenkinsci 
GitHub organization.
 


I'm not sure what stops Gradle from being supported by automated release, 
but the number of plugins using automated releases has been steadily 
increasing for a 

Currently the Github action uses Maven to rebuild and publish 
https://github.com/jenkins-infra/jenkins-maven-cd-action/blob/master/run.sh#L8
.
We could either provide a similar Github action, or simply a template and 
some docs on how to use it, but first I'd like to make sure it's used.

Getting a step back, I'd be curious to know why it requires rebuilding 
since it's supposed to be built already on ci.jenkins.io and published to 
the incrementals repository. The automatic releasing would just consist in 
promoting from the incrementals repository to the release repository in 
Artifactory.


The ci.jenkins.io machine is intentionally not considered "trusted".  We 
don't place credentials on ci.jenkins.io
 

 
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/559cbeef-e675-4779-ac7c-f1a407d2d874n%40googlegroups.com.

Re: Did Tippy.js add Popper2 to Jenkins core?

[Basil Crow]

On Thu, May 25, 2023 at 5:24 AM Ullrich Hafner  wrote:
> Rather than reinventing the wheel we should use more of those rock-solid 
> component [sic] that are already on the market.

Indeed, and I suspect this was the fatal flaw behind Tom Fennelly's
effort several years back: his homegrown dynamic linker never reached
critical adoption. In contrast, Webpack module federation is a general
component that is already on the market and widely deployed.

> it does not make sense to create our own version of ECharts, or Bootstrap, etc

It _does_ make sense to package third-party libraries (either Java or
JavaScript) as Jenkins library plugins in order to facilitate dynamic
linking. This is a consequence of the fact that we maintain a
homegrown plugin distribution, installation, and loading system (and
it is far too late to distribute, install, and load Jenkins plugins
through some generalized method).

-- 
You received this message because you are 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/CAFwNDjqRuWnhC9XecYF%2Bpo80rrz3q5fYg_X6QR%2BEwmwP4kJRjg%40mail.gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Alexis Tual]

Thanks for the quick answer!

On Thursday, May 25, 2023 at 3:16:30 PM UTC+2 Mark Waite wrote:

On Thursday, May 25, 2023 at 6:09:42 AM UTC-6 you wrote:

Hi,
lately I've been working on improving the Gradle support for building 
Jenkins plugins, see 
https://github.com/jenkinsci/gradle-jpi-plugin/issues/213 for more details


Thanks for doing that.
 

The latest JPI plugin release 0.49.0 and recent changes on the 
pipeline-library (https://github.com/jenkins-infra/pipeline-library/pull/654 
and https://github.com/jenkins-infra/pipeline-library/pull/652) enable 
quality checks and incremental builds on ci.jenkins.io. Where can we 
document this and would it be ok to re-enable Gradle support ?


https://github.com/jenkinsci/gradle-jpi-plugin/issues/213#issue-1499881868 
indicates the following reasons that the hosting team started rejecting new 
hosting requests for plugins built with Gradle:


   - No support for JEP-229 
   
   - No support for JEP-305 
   
   - Lacking end-user documentation on jenkins.io 
   
   - No support for publishing static analysis and coverage reports on 
   ci.jenkins.io
   - No support for building on ACI (Azure Container Instance) agents
   - Suspect to produce invalid pom.xml files causing issues with third 
   parties and the update center in the past


You noted that the second bullet (JEP-305 - incremental builds) is now 
supported and that the fourth bullet (quality checks) are now supported and 
that the first bullet (JEP-229 - automated release / continuous delivery) 
is not supported.

Are you willing to create end user documentation on jenkins.io for those 
who use Gradle?

Sure, I can start a dedicated page with what we have and enrich later (see 
below)
 


I'm not a member of the hosting team, but I think they will want to be 
assured that Jenkins plugins can be successfully maintained and released 
using Gradle.
 

One thing I've noticed though is that the cd release with Gradle would not 
be supported by the dedicated Github action. I wonder if it worth 
supporting, since I don't see it used by a lot of plugins currently: 
https://github.com/search?q=org%3Ajenkinsci%20%22maven-cd.yml%40v1%22%20path%3A*.yml=code.
 
What do you think ?


Your query is not showing you how widely the automated release process is 
used.  

https://github.com/search?q=repo%3Ajenkins-infra%2Frepository-permissions-updater+%22cd%3A%22=code
 
shows that 340 repositories have enabled automated release. 

My understanding of 
https://www.jenkins.io/doc/developer/publishing/releasing-cd/ is that this 
step will just set the Maven repository credentials as secrets on the 
relevant Github repository.
The actual continuous release will happen only if using 
https://raw.githubusercontent.com/jenkinsci/.github/master/workflow-templates/cd.yaml,
 
or am I missing something ? People maybe just have their own workflow using 
credentials to publish ?
 


I'm not sure what stops Gradle from being supported by automated release, 
but the number of plugins using automated releases has been steadily 
increasing for a 

Currently the Github action uses Maven to rebuild and publish 
https://github.com/jenkins-infra/jenkins-maven-cd-action/blob/master/run.sh#L8.
We could either provide a similar Github action, or simply a template and 
some docs on how to use it, but first I'd like to make sure it's used.

Getting a step back, I'd be curious to know why it requires rebuilding 
since it's supposed to be built already on ci.jenkins.io and published to 
the incrementals repository. The automatic releasing would just consist in 
promoting from the incrementals repository to the release repository in 
Artifactory.
 
Thanks!

-- 
*
CONFIDENTIALITY NOTICE*: The contents of this email message, and any 
attachments, are intended solely for the addressee(s) and may contain 
confidential, proprietary and/or privileged information legally protected 
from disclosure. If you are not the intended recipient of this 
communication, or if you received this communication by mistake, please 
notify the sender immediately and delete this message and any attachments. 
If you are not the intended recipient, you are hereby notified that any 
use, retransmission, dissemination, copying or storage of this message or 
its attachments is strictly prohibited.

-- 
You received this message because you are 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/e0d43946-98bb-4ec0-bab5-cfae4283cfa8n%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Mark Waite]

On Thursday, May 25, 2023 at 6:09:42 AM UTC-6 you wrote:

Hi,
lately I've been working on improving the Gradle support for building 
Jenkins plugins, see 
https://github.com/jenkinsci/gradle-jpi-plugin/issues/213 for more details


Thanks for doing that.
 

The latest JPI plugin release 0.49.0 and recent changes on the 
pipeline-library (https://github.com/jenkins-infra/pipeline-library/pull/654 
and https://github.com/jenkins-infra/pipeline-library/pull/652) enable 
quality checks and incremental builds on ci.jenkins.io. Where can we 
document this and would it be ok to re-enable Gradle support ?


https://github.com/jenkinsci/gradle-jpi-plugin/issues/213#issue-1499881868 
indicates the following reasons that the hosting team started rejecting new 
hosting requests for plugins built with Gradle:


   - No support for JEP-229 
   
   - No support for JEP-305 
   
   - Lacking end-user documentation on jenkins.io 
   
   - No support for publishing static analysis and coverage reports on 
   ci.jenkins.io
   - No support for building on ACI (Azure Container Instance) agents
   - Suspect to produce invalid pom.xml files causing issues with third 
   parties and the update center in the past


You noted that the second bullet (JEP-305 - incremental builds) is now 
supported and that the fourth bullet (quality checks) are now supported and 
that the first bullet (JEP-229 - automated release / continuous delivery) 
is not supported.

Are you willing to create end user documentation on jenkins.io for those 
who use Gradle?

I'm not a member of the hosting team, but I think they will want to be 
assured that Jenkins plugins can be successfully maintained and released 
using Gradle.
 

One thing I've noticed though is that the cd release with Gradle would not 
be supported by the dedicated Github action. I wonder if it worth 
supporting, since I don't see it used by a lot of plugins currently: 
https://github.com/search?q=org%3Ajenkinsci%20%22maven-cd.yml%40v1%22%20path%3A*.yml=code.
 
What do you think ?


Your query is not showing you how widely the automated release process is 
used.  

https://github.com/search?q=repo%3Ajenkins-infra%2Frepository-permissions-updater+%22cd%3A%22=code
 
shows that 340 repositories have enabled automated release. 

I'm not sure what stops Gradle from being supported by automated release, 
but the number of plugins using automated releases has been steadily 
increasing for a 

-- 
You received this message because you are 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/b2c3fcc5-2518-41c1-9153-290e31cc29ccn%40googlegroups.com.

Re: Did Tippy.js add Popper2 to Jenkins core?

[Ullrich Hafner]

> I strongly feel the solution is to have more jelly or web components, that do 
> the standard ui behavior with encapsulation and contracts, and those that 
> want to be able to do custom logic, should include their own dependencies via 
> a bundler. 

Rather than reinventing the wheel we should use more of those rock-solid 
component that are already on the market. We have so limited development 
resources in Jenkins in the moment that it does not make sense to create our 
own version of ECharts, or Bootstrap, etc.  


-- 
You received this message because you are 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/414E3000-AB3B-4E36-AA78-17D7146C46F5%40gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Alexis Tual]

Hi,
lately I've been working on improving the Gradle support for building 
Jenkins plugins, see 
https://github.com/jenkinsci/gradle-jpi-plugin/issues/213 for more details
The latest JPI plugin release 0.49.0 and recent changes on the 
pipeline-library 
(https://github.com/jenkins-infra/pipeline-library/pull/654 and 
https://github.com/jenkins-infra/pipeline-library/pull/652) enable quality 
checks and incremental builds on ci.jenkins.io. Where can we document this 
and would it be ok to re-enable Gradle support ?
One thing I've noticed though is that the cd release with Gradle would not 
be supported by the dedicated Github action. I wonder if it worth 
supporting, since I don't see it used by a lot of plugins currently: 
https://github.com/search?q=org%3Ajenkinsci%20%22maven-cd.yml%40v1%22%20path%3A*.yml=code.
 
What do you think ?
Thanks!


On Tuesday, March 28, 2023 at 10:12:12 PM UTC+2 m...@basilcrow.com wrote:

> On Mon, Mar 27, 2023 at 7:27 AM 'Herve Le Meur' via Jenkins Developers <
> jenkin...@googlegroups.com> wrote:
> > For those using buildPluginWithGradle() from the shared pipeline 
> library, we could add a note about it in the logs.
>
> This was done in jenkins-infra/pipeline-library#629 
> .
>

-- 
*
CONFIDENTIALITY NOTICE*: The contents of this email message, and any 
attachments, are intended solely for the addressee(s) and may contain 
confidential, proprietary and/or privileged information legally protected 
from disclosure. If you are not the intended recipient of this 
communication, or if you received this communication by mistake, please 
notify the sender immediately and delete this message and any attachments. 
If you are not the intended recipient, you are hereby notified that any 
use, retransmission, dissemination, copying or storage of this message or 
its attachments is strictly prohibited.

-- 
You received this message because you are 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/f8a5a9c1-8b7a-4d86-bca7-462959aa1f46n%40googlegroups.com.