Re: [Proposal] Remove "hacktoberfest" topic from all jenkinsci repositories

[Basil Crow]

On Wed, Sep 25, 2024 at 9:01 AM 'Darin Pope' via Jenkins Developers
 wrote:
> I did some more digging and found the following topics that probably can be 
> removed as well:
>
> hacktoberfest2020
> hacktoberfest2021
> hacktoberfest2022
> hacktoberfest-accepted

I have deleted the "hacktoberfest2020" topic from the following repository:

• dotcoverrunner-plugin

I have deleted the "hacktoberfest2021" topic from the following repositories:

• cloudevents-plugin
• JiraTestResultReporter-plugin

I have deleted the "hacktoberfest2022" topic from the following repository:

• maven-snapshot-check-plugin

I have deleted the "hacktoberfest-accepted" label from the following
repositories:

• acceptance-test-harness
• ansible-plugin
• audit-log-plugin
• azure-container-agents-plugin
• build-with-parameters-plugin
• claim-plugin
• configuration-as-code-plugin
• copy-to-slave-plugin
• cvs-plugin
• deploy-plugin
• docker
• docker-agent
• docker-custom-build-environment-plugin
• docker-plugin
• docker-ssh-agent
• ec2-plugin
• email-ext-plugin
• extra-tool-installers-plugin
• folder-auth-plugin
• folder-properties-plugin
• generic-webhook-trigger-plugin
• git-bisect-plugin
• git-changelog-plugin
• github-autostatus-plugin
• gitlab-branch-source-plugin
• git-plugin
• google-kubernetes-engine-plugin
• helm-charts
• hidden-parameter-plugin
• idea-stapler-plugin
• jackson2-api-plugin
• jdk-tool-plugin
• jenkins
• jenkinsfile-runner
• jenkins-test-harness
• job-dsl-plugin
• job-restrictions-plugin
• kubernetes-ci-plugin
• kubernetes-plugin
• label-linked-jobs-plugin
• ldap-plugin
• lockable-resources-plugin
• mailer-plugin
• mq-notifier-plugin
• next-executions-plugin
• osf-builder-suite-for-sfcc-credentials-plugin
• packaging
• pipeline-build-step-plugin
• plugin-installation-manager-tool
• prometheus-plugin
• publish-over-cifs-plugin
• publish-over-plugin
• queue-cleanup-plugin
• remoting
• reverse-proxy-auth-plugin
• role-strategy-plugin
• sge-cloud-plugin
• sidebar-link-plugin
• tekton-client-plugin
• thin-backup-plugin
• timestamper-plugin
• visualworks-store-plugin
• vsphere-cloud-plugin
• webhook-step-plugin
• workflow-job-plugin
• working-hours-plugin
• wsclean-plugin

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

Re: [Proposal] Remove "hacktoberfest" topic from all jenkinsci repositories

[Basil Crow]

On Wed, Sep 18, 2024 at 7:19 PM Basil Crow  wrote:
>
> I have deleted the "hacktoberfest" topic from the following
> repositories in the "jenkinsci" GitHub organization:

I meant "label" instead of "topic" above. I have deleted the
"hacktoberfest" _topic_ from the following repositories in the
"jenkinsci" GitHub organization:

acceptance-test-harness
active-choices-plugin
amazon-ecr-plugin
analysis-model
ansible-plugin
archetypes
artifactdeployer-plugin
azure-ad-plugin
azure-artifact-manager-plugin
azure-keyvault-plugin
azure-storage-plugin
azure-vm-agents-plugin
badge-plugin
build-timestamp-plugin
checks-api-plugin
ci.jenkins.io-runner
cloudevents-plugin
code-coverage-api-plugin
compact-columns-plugin
config-driven-pipeline-plugin
configuration-as-code-plugin
configurationslicing-plugin
configure-job-column-plugin
console-column-plugin
credentials-plugin
custom-war-packager
cvs-plugin
dark-theme-plugin
dashboard-view-plugin
data-tables-api-plugin
design-library-plugin
digitalocean-plugin
docker
docker-agent
docker-plugin
dotcoverrunner-plugin
ec2-plugin
ecutest-plugin
emailext-template-plugin
embeddable-build-status-plugin
envinject-api-plugin
envinject-lib
envinject-plugin
folder-auth-plugin
forensics-api-plugin
git-forensics-plugin
github-checks-plugin
github-oauth-plugin
gitlab-oauth-plugin
global-build-stats-plugin
helm-charts
http-request-plugin
idea-stapler-plugin
implied-labels-plugin
influxdb-plugin
ionicons-api-plugin
jellydoc-maven-plugin
jenkins
jenkinsfile-runner
jenkinsfile-runner-github-actions
jenkinsfile-runner-image-packs
jenkins-test-harness
JiraTestResultReporter-plugin
job-config-history-plugin
job-dsl-plugin
job-restrictions-plugin
junit-plugin
junit-sql-storage-plugin
kubernetes-credentials-provider-plugin
label-linked-jobs-plugin
lib-annotation-indexer
lib-file-leak-detector
localization-zh-cn-plugin
lockable-resources-plugin
login-theme-plugin
managed-scripts-plugin
maven-hpi-plugin
maven-snapshot-check-plugin
mercurial-plugin
msbuild-plugin
nodelabelparameter-plugin
opentelemetry-plugin
packaging
parameterized-scheduler-plugin
parameterized-trigger-plugin
pipeline-graph-view-plugin
pipeline-restful-api-plugin
plot-plugin
plugin-compat-tester
plugin-installation-manager-tool
plugin-modernizer-tool
priority-sorter-plugin
prometheus-plugin
promoted-builds-plugin
purge-build-queue-plugin
remoting
reverse-proxy-auth-plugin
run-condition-plugin
scriptler-plugin
seleniumhtmlreport-plugin
slack-plugin
stapler
test-results-analyzer-plugin
thin-backup-plugin
validating-string-parameter-plugin
versioncolumn-plugin
warnings-ng-plugin
webhook-step-plugin
winp
winstone

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

Re: [Proposal] Remove "hacktoberfest" topic from all jenkinsci repositories

[Basil Crow]

I have deleted the "hacktoberfest" topic from the following
repositories in the "jenkinsci" GitHub organization:

analysis-model
analysis-pom-plugin
ansible-plugin
apache-httpcomponents-client-4-api-plugin
audit-log-plugin
authorize-project-plugin
autograding-plugin
azure-ad-plugin
azure-artifact-manager-plugin
azure-container-agents-plugin
azure-credentials-plugin
azure-keyvault-plugin
azure-sdk-plugin
azure-storage-plugin
azure-vm-agents-plugin
badge-plugin
basic-branch-build-strategies-plugin
blueocean-plugin
bom
bootstrap5-api-plugin
build-blocker-plugin
build-with-parameters-plugin
clang-scanbuild-plugin
cloudbees-folder-plugin
cloudevents-plugin
code-coverage-api-plugin
configuration-as-code-plugin
console-column-plugin
conventional-commits-plugin
coverage-model
coverage-plugin
custom-war-packager
dark-theme-plugin
database-h2-plugin
database-mysql-plugin
database-plugin
database-postgresql-plugin
data-tables-api-plugin
deploy-plugin
description-setter-plugin
digitalocean-plugin
docker
docker-agent
docker-commons-plugin
docker-workflow-plugin
echarts-api-plugin
elastic-axis-plugin
embeddable-build-status-plugin
envinject-lib
envinject-plugin
folder-auth-plugin
font-awesome-api-plugin
forensics-api-plugin
gerrit-trigger-plugin
gitblit-plugin
git-client-plugin
gitee-plugin
git-forensics-plugin
github-autostatus-plugin
gitlab-plugin
git-parameter-plugin
git-plugin
gradle-plugin
groovy-postbuild-plugin
hashicorp-vault-pipeline-plugin
helm-charts
html5-notifier-plugin
idea-stapler-plugin
implied-labels-plugin
jdk-tool-plugin
jenkins
jenkinsfile-runner
jenkins-infra-test-plugin
jenkins-multijob-plugin
jenkins-test-harness
jira-steps-plugin
job-config-history-plugin
job-restrictions-plugin
jquery3-api-plugin
junit-plugin
junit-sql-storage-plugin
kubernetes-credentials-plugin
label-verifier-plugin
lib-version-number
lighthouse-report-plugin
locale-plugin
localization-zh-cn-plugin
log-file-filter-plugin
login-theme-plugin
mabl-integration-plugin
mailer-plugin
markdown-formatter-plugin
maven-hpi-plugin
maven-snapshot-check-plugin
next-executions-plugin
nodelabelparameter-plugin
ownership-plugin
permissive-script-security-plugin
pipeline-graph-view-plugin
pipeline-input-step-plugin
pipeline-model-definition-plugin
pipeline-npm-plugin
pipeline-stage-view-plugin
pipeline-timeline-plugin
pipeline-utility-steps-plugin
platformlabeler-plugin
plugin-compat-tester
plugin-installation-manager-tool
plugin-pom
plugin-util-api-plugin
pom
popper2-api-plugin
priority-sorter-plugin
prism-api-plugin
promoted-builds-plugin
publish-over-ssh-plugin
purge-build-queue-plugin
release-plugin
remoting
remoting-kafka-plugin
s3-plugin
schedule-build-plugin
scm-filter-aged-refs-plugin
scm-filter-jira-validator-plugin
scm-trait-commit-skip-plugin
script-security-plugin
security-inspector-plugin
seleniumhtmlreport-plugin
slack-plugin
tekton-client-plugin
testng-plugin-plugin
translation-plugin
versioncolumn-plugin
warnings-ng-plugin
webhook-step-plugin
workflow-api-plugin
workflow-cps-global-lib-plugin
workflow-cps-plugin
workflow-multibranch-plugin
xml-job-to-job-dsl-plugin

-- 
You received this message because you are 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/CAFwNDjpPqxrWMGtYhoz9OM2_%3DusQN14S2dtj0G0ppCmNetLCbg%40mail.gmail.com.

Re: Matrix Auth & Loading Permissions

[Basil Crow]

See 
https://github.com/search?q=repo%3Ajenkinsci%2Fjenkins+JENKINS-17200&type=code

-- 
You received this message because you are 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/CAFwNDjphwpyQ6J1YV38SpcZq5-cXraKobOUbQ1fFNW5JaAkN0A%40mail.gmail.com.

Re: Windows on Arm support status?

[Basil Crow]

It is great to see some renewed interest here. When we last left off,
we had gotten a working CI build but the result wasn't releasable, so
it was reverted in https://github.com/jenkinsci/winp/pull/128. From my
perspective, the next step is to revert the revert (i.e., restore the
CI build) and then make it releasable by implementing
https://github.com/jenkinsci/winp/issues/117.

On Tue, Sep 17, 2024 at 3:09 PM Alex Earl  wrote:
>
> I was looking at the PR's for Windows on Arm support for Jenkins controller 
> (mainly needed updates to winp for full support) and it looks like a lot of 
> the work was done. I'd like to see if I can get this over the threshold to be 
> included (as well as create an arm64 installer), but I am unsure what is 
> missing at this point. I went through several issues and comments and PR's 
> and am unsure what the next steps are. Does anyone know the current status?
>
> See the following:
>
> https://github.com/jenkinsci/winp/pull/112
> https://github.com/jenkinsci/winp/issues/117
> https://github.com/jenkinsci/winp/pull/116
> https://github.com/jenkinsci/winp/issues/119
>
> Thanks,
>
> slide
>
> --
> 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/CAPiUgVeNiqVDf3qUzsR6VaC1hxWGGcv9sb7tzLB04PcrZHNaHg%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/CAFwNDjrn4Gsc%2BA6eHpJJx%3DkqWF8ThgDrzhBDnb0BzNo9-9DaAg%40mail.gmail.com.

Re: Spring Security upgrade from 5.x to 6.x

[Basil Crow]

Spring Security 6.x (including EE 9) was delivered in 2.475, with two
follow-on regression fixes in 2.476 and 2.477 respectively. At the
time of this writing, I am not aware of any unresolved issues with
Spring Security 6.x or EE 9. I recommend either 2.476 or 2.477 be
chosen as the next LTS line, and if 2.476 is chosen then the relevant
regression fix should be backported.

https://github.com/jenkinsci/plugin-pom/pull/1004 proposes requiring
Java 17 or newer and Jetty 12 (EE 9) or newer for plugin development.
My recommendation is to merge and release this PR once the next LTS
line is selected. While more aggressive than usual for the plugin
parent POM, this eliminates the need for a number of workarounds when
using newer core releases. We can always create a Java 11 backport
branch if necessary, but I have no plans to do that at present.

-- 
You received this message because you are 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/CAFwNDjpWPudB-OaBfOEwc83iJZh%3DbyRckgWejSMGYEjZ0uOvTA%40mail.gmail.com.

Re: Considering job-dsl-plugin adoption

[Basil Crow]

On Wed, Aug 28, 2024 at 1:27 PM Jerico Pena  wrote:
> I'm still interested but haven't had time to work on it yet.

Great; let me know when you have some time. The Job DSL plugin's own
test suite is using an old version of Spock (for the old version of
Groovy delivered by Jenkins core) but a new version of Ant (from the
Jenkins core BOM), and Dependabot reports no CVEs. A simple fix for
you may be to update Jenkins core to a recent version and import the
Jenkins core BOM (org.jenkins-ci.main:jenkins-bom) as described in
https://docs.gradle.org/current/userguide/platforms.html#sub:bom_import
-- if that works, then please file a PR to update the example at
https://github.com/jenkinsci/job-dsl-plugin/blob/master/docs/Testing-DSL-Scripts.md
accordingly.

-- 
You received this message because you are 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/CAFwNDjqDa5gyP-3pUGT9EmQKN2%2Bc2Br20cCyXm5FjdwpL0ZEhA%40mail.gmail.com.

Re: Considering job-dsl-plugin adoption

[Basil Crow]

Hi Jerico,

Were you still interested in working on Job DSL? I just cut a release
with a few bug fixes and dependency updates. Regarding your issue with
Groovy and Spock:
https://github.com/jenkinsci/job-dsl-plugin/blob/master/docs/Testing-DSL-Scripts.md
is still using Gradle and needs to be converted to Maven, as the
official Jenkins build infrastructure does not support Gradle. Once it
is converted to Maven, we can debug whatever issues are remaining
against recent versions of Jenkins core. I can help review this if you
open a PR.

Basil

On Wed, Aug 7, 2024 at 6:57 AM Jerico Pena  wrote:
>
> Hello,
>
> I recently created the following ticket to address a CVE with the 
> job-dsl-plugin. I'm considering adopting the plugin in order to address the 
> CVE, but would like to get some input on whether this will be a relatively 
> simple undertaking or if I will be getting into "dependency hell" because 
> this plugin relies on an older version of groovy and spock. Are there any 
> videos or other resources that I could access to get up to speed on the code 
> base? I have a fair amount of experience working with pipelines in groovy, 
> but have never worked with the java-side of jenkins.
>
> https://issues.jenkins.io/browse/JENKINS-73463
>
> I also created this post in the google group but no response(s) so far.
>
> https://groups.google.com/g/job-dsl-plugin/c/dkRLK4JxAVk
>
> Thanks,
> Jerico
>
> --
> You received this message because you are 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/c29a44bd-e57d-4790-8c9f-d475ebe1n%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/CAFwNDjq17SfTQF3ncHZ9j_n4uMReXUU3Yugs67ULUHeANRzrxw%40mail.gmail.com.

Re: Backporting for LTS 2.462.2 started

[Basil Crow]

While we're at it, we may want to also backport JUnit plugin version
1291.v60776881903c, since the lack of
https://github.com/jenkinsci/junit-plugin/pull/638 might cause
problems for some scanners as well.

-- 
You received this message because you are 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/CAFwNDjoWpe_T5Zyu56O8m0hgEKZ%3DOKWoK4TGPVkDM%2BfE4eA1%3Dw%40mail.gmail.com.

Re: Backporting for LTS 2.462.2 started

[Basil Crow]

+1

-- 
You received this message because you are 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/CAFwNDjoZepDFD8kBYu0J%3D1GG%2Bg2s1AE%3D_BheDLV_aVq5JL4u1w%40mail.gmail.com.

Re: Considering job-dsl-plugin adoption

[Basil Crow]

Hi Jerico, and thanks for your interest in adopting this plugin. We would
be thrilled to welcome you aboard as a maintainer, and I am available to
help with onboarding as needed.

The first step would be for you to update the minimum Jenkins version to a
recent release
.
Please prepare a PR as described in this tutorial and make any necessary
changes to get tests to pass. Once these changes are complete, you will be
ready to adopt the plugin
.

The next step after that is to process recent PRs (reviewing/testing them
and then merging them) and then do a release. The following PRs all look
like they should be merged/released:

   - https://github.com/jenkinsci/job-dsl-plugin/pull/1381
   - https://github.com/jenkinsci/job-dsl-plugin/pull/1405
   - https://github.com/jenkinsci/job-dsl-plugin/pull/1415
   - https://github.com/jenkinsci/job-dsl-plugin/pull/1416

Once you have successfully performed your first release, you will be
familiar with the build process and prepared to address the issue you
originally came here about.
https://github.com/jenkinsci/job-dsl-plugin/blob/master/docs/Testing-DSL-Scripts.md
is still using Gradle and needs to be converted to Maven, as the official
Jenkins build infrastructure does not support Gradle. Once it is converted
to Maven, we can debug whatever issues are remaining against recent
versions of Jenkins core.

On Wed, Aug 7, 2024 at 6:57 AM Jerico Pena  wrote:
>
> Hello,
>
> I recently created the following ticket to address a CVE with the
job-dsl-plugin. I'm considering adopting the plugin in order to address the
CVE, but would like to get some input on whether this will be a relatively
simple undertaking or if I will be getting into "dependency hell" because
this plugin relies on an older version of groovy and spock. Are there any
videos or other resources that I could access to get up to speed on the
code base? I have a fair amount of experience working with pipelines in
groovy, but have never worked with the java-side of jenkins.
>
> https://issues.jenkins.io/browse/JENKINS-73463
>
> I also created this post in the google group but no response(s) so far.
>
> https://groups.google.com/g/job-dsl-plugin/c/dkRLK4JxAVk
>
> Thanks,
> Jerico
>
> --
> You received this message because you are 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/c29a44bd-e57d-4790-8c9f-d475ebe1n%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/CAFwNDjqgqMGsP-EK-cwtB8bfdTossgSX3nkf%3DHWCKwt59GFPhw%40mail.gmail.com.

Re: Plugin with Java 17 minimum dependencies

[Basil Crow]

On Wed, May 8, 2024 at 12:47 AM timja...@gmail.com  wrote:
>
> [v2] of the reusable workflows is now running on Java 17

Adopted in critical plugin consumers this week.

-- 
You received this message because you are 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/CAFwNDjq0OUeJCSMnq%3DKeMadKT4XTxxRURY%3DyUvsFZXm0tF3d0Q%40mail.gmail.com.

Re: Two week break in LTS schedule at end of 2024

[Basil Crow]

+1

-- 
You received this message because you are 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/CAFwNDjqwQ0dsAdZ3bqoaZxvtC3yzk6QEMpwFvgn3MWJGQn2%3DfQ%40mail.gmail.com.

Re: 2.462 as 7 Aug 2024 LTS baseline?

[Basil Crow]

On Tue, Jun 25, 2024 at 3:21 PM Mark Waite  wrote:
>
> I'm not aware of any other bug reports related to Apache File Upload 2.

There is also JENKINS-73235, but just like JENKINS-73320 we are also
blocked on upstream and the number of affected users is small (0.55%
and 0.79% and of controllers, respectively). I don't think these
numbers are significant enough to affect LTS baseline selection. Those
users can always stick to the previous LTS until upstream takes action
to release the already merged fix (in the case of JENKINS-73320) or to
make the plugin compilable so I can help with a fix (in the case of
JENKINS-73235).

-- 
You received this message because you are 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/CAFwNDjrBgDGzM6QqNzPVjdXo-80%2B2M17oRW1Wf1VpK_gmqXa2w%40mail.gmail.com.

Re: Removing Commons Compress from Jenkins core

[Basil Crow]

I have filed https://issues.jenkins.io/browse/JENKINS-73355 to track this task.

-- 
You received this message because you are 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/CAFwNDjpOouwNvB_sQWGpvnx9Meq1PD7DsUU1W-r-FwzOGZzH9Q%40mail.gmail.com.

Re: Removing JZlib from Jenkins core

[Basil Crow]

I have filed https://issues.jenkins.io/browse/JENKINS-73354 to track this task.

-- 
You received this message because you are 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/CAFwNDjpyX-zJkRSFCjpoMVPVLpKkMeVaO4cO0EoUpxjDKWFRnA%40mail.gmail.com.

Re: Spring Security upgrade from 5.x to 6.x

[Basil Crow]

On Tue, Jun 4, 2024 at 5:21 PM Basil Crow  wrote:
> By creating a backport branch of the test harness that
> continues to be based on Java 11 bytecode, and using this backport
> branch in the plugin parent POM until we decide to drop Java 11
> support in the plugin parent POM (most likely around the timeframe
> when Jetty 12 EE 9 is delivered in LTS). This means that every change
> to the test harness will need to be backported to become available to
> plugin parent POM releases—painful in the short term, but the idea is
> that this phase will not last more than a few months.

With today's release of 2.463, the default branch of the test harness
is now targeting 2.463 and Java 17 or newer. I have created a 2225.x
backport branch that still targets 2.361 and Java 11 or newer. The
plugin POM will still support Java 11 for a bit longer, so test
harness changes should generally be backported to this branch in the
short term. Let me know if you need help doing this.

https://github.com/jenkinsci/jenkins-test-harness/pull/762 and
https://github.com/jenkinsci/jenkins-test-harness/pull/770, both
targeting the default branch of the test harness, add EE 8 and EE 9
support (respectively). These PRs will not be backported; rather, they
will form the basis of a future plugin POM release that requires Java
17 or newer and Jetty 12 or newer.

-- 
You received this message because you are 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/CAFwNDjpww0sQgHW2TPfBxGhyL2RhG%2B_%2B%2BaPDD%2BfyQiXXe8J9YA%40mail.gmail.com.

Re: Spring Security upgrade from 5.x to 6.x

[Basil Crow]

On Tue, Jun 4, 2024 at 5:21 PM Basil Crow  wrote:
> I am planning to follow a lazy consensus approach with this plan. If
> nobody objects to this lazy consensus decision by the end of next
> week, I will consider the matter settled and start executing on the
> plan the week after that, with a weekly release that requires Java 17
> delivered by the end of June.

https://github.com/jenkinsci/jenkins/pull/9358 has been merged toward
2.463, which will require Java 17 or newer.

As a follow-up I proposed
https://github.com/jenkinsci/jenkins/pull/9382 to use pattern matching
for instanceof. Similar PRs could be proposed to adopt enhanced switch
statements, text blocks, and record classes if anyone is interested.

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

Re: Plugin Dev & RequireUpperBoundDeps

[Basil Crow]

See https://github.com/jenkinsci/bom/issues/3098.

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

Re: Spring Security upgrade from 5.x to 6.x

[Basil Crow]

On Sat, May 11, 2024 at 1:34 AM Ivan Fernandez Calvo
 wrote:
>
> Please do it, I am waiting for this change to update the SAML plugin to the 
> latest PAC4J version

Your wish is my command, Ivan! As discussed at the last governance
board meeting, we are going to do it in a weekly release before the
end of June. I plan to release a new version of jenkinsci/pom with
maven.compiler.release set to 17 and adopt it in core and all core
components, producing a weekly release that requires Java 17 bytecode.
I will try to retain Java 11 bytecode in executable.Main to print a
decent user-friendly error message on the controller on Java 11 (no
such plan for agents, though).

The plugin parent POM will continue to support cores with both Java 11
and 17 bytecode (i.e., its minimum jenkins.version will not change)
for a little while longer. The value of maven.compiler.release will
default to 11 but will be dynamically reconfigured to 17 during the
build when jenkins.version is set to a core with Java 17 bytecode.
This should even work fine in IntelliJ this time around thanks to
https://github.com/jenkinsci/maven-hpi-plugin/pull/578 (as long as at
least one Maven build has been done prior to importing the project in
IntelliJ), though developers should still exercise caution when
upgrading libraries to Java 17 bytecode due to Enforcer's
"EnforceBytecodeVersion" check being somewhat crippled during the
transition period (as described in
https://github.com/jenkinsci/maven-hpi-plugin/pull/583). This
transition period is similar to the last one we did when we required
Java 11, but it should be slightly smoother due to improved IDE
support. FTR we had the same gap with Enforcer last time around and a
bug or two slipped through during the transition period, so we need to
be particularly vigilant about upgrading libraries until the
transition period is over.

The astute reader will notice that I wrote "I plan to release a new
version of jenkinsci/pom with maven.compiler.release set to 17 and
adopt it in […] all core components" (including the test harness) as
well as "the plugin parent POM will continue to support cores with
both Java 11 and 17 bytecode […] for a little while longer", two
statements that are seemingly in contradiction due to the fact that a
test harness with Java 17 bytecode will not be usable in a plugin
parent POM that continues to support cores with Java 11 bytecode
(i.e., maven.compiler.release set to 11). How is this contradiction to
be resolved? By creating a backport branch of the test harness that
continues to be based on Java 11 bytecode, and using this backport
branch in the plugin parent POM until we decide to drop Java 11
support in the plugin parent POM (most likely around the timeframe
when Jetty 12 EE 9 is delivered in LTS). This means that every change
to the test harness will need to be backported to become available to
plugin parent POM releases—painful in the short term, but the idea is
that this phase will not last more than a few months. Meanwhile, on
the default branch of the test harness, we hope to soon deliver
functionality to support both Jetty 12 EE 8 and Jetty 12 EE 9,
selecting dynamically based on the core in use. This will be explained
further in a forthcoming JEP, and it will allow plugins with tests
that rely on Jetty APIs to begin migrating to Jetty 12 in advance of
the rest of the ecosystem.

I am planning to follow a lazy consensus approach with this plan. If
nobody objects to this lazy consensus decision by the end of next
week, I will consider the matter settled and start executing on the
plan the week after that, with a weekly release that requires Java 17
delivered by the end of June.

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

Removing JZlib from Jenkins core

[Basil Crow]

JZlib is no longer maintained, and continuing to carry a custom fork
is a burden. I have found the Java 7+ GZIPInputStream and
GZIPOutputStream classes to work well as a drop-in replacement. Once
plugins migrate to these standard Java Platform classes, we can remove
JZlib from the WAR.

Others have correctly identified the opportunity to refactor the stack
to move compression from the web framework layer (Stapler) to the
servlet container layer (Winstone/Jetty) in
https://github.com/jenkinsci/stapler/issues/130 and
https://github.com/jenkinsci/stapler/issues/265. That long-term goal
carries significantly higher implementation effort and risk, since it
is a change to interfaces and not just implementations.

-- 
You received this message because you are 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/CAFwNDjr5gt%2BXWfACMyL5iHS3-7pCXkeA2gf9kTBNZXc3eZL8DQ%40mail.gmail.com.

Removing Commons Compress from Jenkins core

[Basil Crow]

We originally used Ant for tar/untar functionality, but we migrated to
Commons Compress in https://github.com/jenkinsci/jenkins/pull/1670,
which also added the Commons Compress library to the WAR. Fast forward
to today, and recent releases of Commons Compress depend on Commons
Lang 3. We don't want to keep increasing the API surface area of the
WAR by pulling in these random libraries. And adding Commons Lang 3 to
the WAR would override the library plugin we ship today.

A solution was found in 2.460 by migrating from Commons Compress back
to Ant. Our original reason for migrating away from it was that it did
not support large files > 8 GiB in size. Today, it does, as verified
with an automated test. We are unlikely to ever remove Ant from
Jenkins core, as it is used in a lot of places in core, so why not use
it for tar/untar functionality as well. And unlike Commons Compress,
it has no dependency on Commons Lang 3.

In the meantime, we are still blocked from upgrading to the latest
release of Commons Compress, because the latest release depends on
Commons Lang 3, which we do not want to add to the WAR. But the
release of 2.460 shows a path forward. With core's dependency on
Commons Compress removed, plugins can be adapted, and we can
eventually remove Commons Compress from core.

Plugins can be adapted by either (in the vast majority of simple
cases) migrating to core's copy of Ant or (in the case of e.g.
pipeline-utility-steps and jobcacher-plugin, both of which use Commons
Compress features that are not currently available in Ant) a new
Commons Compress library plugin could be created and plugins migrated
to that instead. That Commons Compress library plugin could depend on
Commons Lang 3 as a plugin-to-plugin dependency.

-- 
You received this message because you are 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/CAFwNDjrizy-kCAz6bRFNuemrCGae6G%3DnaQqDG%2Bu%2Bzqs770OJPA%40mail.gmail.com.

Re: 2.452.2 Release Lead

[Basil Crow]

+1, thank you Kris!

On Thu, May 16, 2024 at 9:31 AM Alyssa Tong  wrote:
>
> +1 from me as well. Thank you, Kris for all you do 🫶
>
> On Thu, May 16, 2024 at 9:26 AM 'Bruno Verachten' via Jenkins Developers 
>  wrote:
>>
>> Thank you Kris for proposing to be the release lead.
>> Of course +1 from me.
>>
>> On Thu, May 16, 2024, 13:14 Kris Stern  wrote:
>>>
>>> Hi everyone,
>>>
>>> I volunteer to be the Release Lead for the upcoming LTS 2.452.2.
>>>
>>> The Release Candidate is scheduled for May 29th, 2024, and the Final 
>>> Release for June 12th, 2024.
>>>
>>> Best,
>>> Kris
>>>
>>> --
>>> You received this message because you are 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/TY1P286MB317193827D7C00C70A858668A1ED2%40TY1P286MB3171.JPNP286.PROD.OUTLOOK.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/CAFbR2rp4vndFMxy-xVONiNbnVNTsCEx-NBZuTHDEAEjSp8FjmQ%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/CAC9wNayZ-TF51Q9p9tEkAw91o3y9bH2hSthxWf99tWpYxgQWVg%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/CAFwNDjpCzTMT1OayBiVUUj1mUpZKSWm_nEHq%2B-ufGaSVb%2B8-tg%40mail.gmail.com.

Re: Spring Security upgrade from 5.x to 6.x

[Basil Crow]

On Sat, May 11, 2024 at 8:43 PM Bob Du  wrote:
>
> I am willing to contribute code to achieve this long-term goal.

Great! I have filed https://issues.jenkins.io/browse/JENKINS-73169
with more details about this long-term removal, explaining the
reasoning behind the removal, the relevant portions of our integration
guidelines, and a suggested implementation strategy that spans
Stapler, core, and plugins.

-- 
You received this message because you are 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/CAFwNDjpdbTRzaqGhCvMqRnk7EAeN%3DZw5SCgiUtb7ZutgNOEDwQ%40mail.gmail.com.

Re: Spring Security upgrade from 5.x to 6.x

[Basil Crow]

Unlike snapshot releases, milestone releases are tagged and published
in Maven Central, so I don't see any issues with upgrading to 2.0.0-M2
immediately. In practice, if a Commons FileUpload v2 API did change
between now and GA, it wouldn't be too much work to adapt the few
plugins that consume it. We routinely adapt small sets of plugins here
and there when there are breaking UI changes.

It would be nice to see someone explore the details of removing
Commons FileUpload entirely. Most of the Jenkins APIs that refer to
Commons FileUpload are in Stapler, with consumers in core and plugins.
A good starting point would be to reimplement Stapler, core, and at
least one plugin without Commons FileUpload. That would provide a
broad range of producers and consumers to validate any API changes.
The Testing Done section of
https://github.com/jenkinsci/jenkins/pull/5174 highlights the main
consumers throughout the ecosystem.

-- 
You received this message because you are 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/CAFwNDjo2H8Z5Fdx1rbQ4_64BN4tOe%3DsUPkFVqUp24Rxm3RHqsw%40mail.gmail.com.

Re: Spring Security upgrade from 5.x to 6.x

[Basil Crow]

While still in milestone status, Commons FileUpload 2.x is being
recommended on the project's home page
 and GitHub page
,
and hopefully it will reach GA this year. The Spring 5.3.x EOL

will likely push the whole Java ecosystem toward Java EE 9+.

A custom fork of an actively maintained upstream project is a maintenance
burden. My prototype shows that we can maintain compatibility with plugins
across the package rename with a handful of bridge methods. Once those
(few) plugins are migrated to the new package name, the bridge methods can
be deleted, resulting in a lateral move in API surface area (removal of 1.x
and addition of 2.x) rather than an increase (addition of 2.x to the
existing 1.x).

In the long term, API surface area can be decreased by removing this
library altogether. Multipart file upload is built into the servlet spec
since 3.1 via the HttpServletRequest#getPart()

API. That is a bit of a more involved project (in the sense of being less
of a mechanical rename and more of a logical rewrite of the relevant code)
to redesign the relevant Jenkins APIs in Stapler and core and migrate core
and plugins to these new APIs. A medium-term migration from Commons
FileUpload 1.x to 2.x in no way precludes this long-term strategy.

-- 
You received this message because you are 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/CAFwNDjod%2BqkJut4wd_WykJEMh%3DJUMW2q2JOqxg_VNBY7nuqj-g%40mail.gmail.com.

Re: Spring Security upgrade from 5.x to 6.x

[Basil Crow]

Based on my prototyping in JENKINS-73120, there is quite a bit of work
to support Jetty 12 (even just EE 8 with javax imports), blocked on
the requirement of Java 17. From my perspective the sooner we require
Java 17, the better. Perhaps we can require Java 17 in weeklies two
weeks earlier than planned, acknowledging that this creates two fewer
choices for LTS selection. Thoughts?

On Thu, Mar 28, 2024 at 3:42 PM Mark Waite  wrote:
>
> The Spring project has announced that Spring Security 5.8.x and Spring 
> Framework 5.3.x will be end of life on August 31, 2024.  Jenkins currently 
> uses  Spring Security 5.8.x and Spring Framework 5.3.x.
>
> Jenkins needs to upgrade to Spring Security 6.x.  Spring Security 6.x in 
> Jenkins requires:
>
> Spring Framework 6.x which requires Java 17 and Jakarta EE 9
>
> When Jenkins transitions from Jakarta EE 8 to Jakarta EE 9, we'll also need 
> to use:
>
> Jetty 12
> Apache file uploader 2.x
>
> Given the size of that change and its dependency on Java 17 as a minimum 
> Jenkins version, I think that we want to switch Jenkins to require Java 17 as 
> soon as possible after the last Java 11 LTS baseline is selected.
>
> Proposed Timeline
>
> 26 Jun 2024 - Choose LTS baseline for last LTS to support Java 11
> 3 Jul 2024 - Require Java 17 in Jenkins weekly release
> 7 Aug 2024 -Last LTS.1 release to support Java 11 (likely 2.464.1)
> 31 Aug 2024 Spring Security 5.8.x public support ends
> 18 Sep 2024 - Choose LTS baseline to require Java 17
> 2 Oct 2024 - Last LTS.3 to support Java 11
> 30 Oct 2024 - First LTS.1 to require Java 17 (likely 2.476.1)
>
> Basil prototyped the Jakarta EE 9 upgrade in August 2023.  The prototype 
> showed that the bridge method injector may help with the transition.  The 
> prototype showed that there is a lot of work to be done in order to upgrade 
> Spring Security in Jenkins from 5.x to 6.x
>
> I noted the timeline because I had initially assumed that we would transition 
> Jenkins weekly to require Java 17 in late August or early September 2024.  
> Based on the large amount of work that is needed for the Spring Security 
> upgrade from 5.x to 6.x, I think that we should require Java 17 the week 
> after we've selected the baseline for the final LTS line that will support 
> Java 11.
>
> If you're willing to help with the Spring Security upgrade project, I'd love 
> to have you respond to this email message.  If you have strong objections to 
> the timeline, please respond with your concerns.
>
> I will share more details as I learn more.
>
> 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/4a260cec-dbe4-4b63-a9e6-7c17ebcbfaebn%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/CAFwNDjoVOivWGGAwob%2BLnBj5WRwNrzyDoUgwLqWUaohYyhRnKw%40mail.gmail.com.

Re: Plugin with Java 17 minimum dependencies

[Basil Crow]

Yes, I think the default should be changed to Java 17 and a new
version released for the reasons already given. Why wasn't the
adoption of such a release (along with updating the Java version value
in the Jenkins security scan workflow, pending
https://github.com/jenkins-infra/jenkins-security-scan/issues/29)
performed when we swept through the ecosystem adding Java 17/21 builds
to Jenkinsfiles?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjqUvERjZur9kLMcLmUEQ_K%2B_NcA2Jb3pQnS_MttakAcMA%40mail.gmail.com.

Re: Plugin with Java 17 minimum dependencies

[Basil Crow]

Previously


-- 
You received this message because you are 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/CAFwNDjoRq4Ne8mA5t6F3-3TsmTGF3CxE-_4fu6FJUvKQDbdvPg%40mail.gmail.com.

Re: ASM in core

[Basil Crow]

On Thu, Jun 10, 2021 at 1:46 AM jn...@cloudbees.com  wrote:
>
> 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 […].

Thanks, James! Valentin Delaye has removed ASM from Jenkins core in
https://github.com/jenkinsci/jenkins/pull/9182, bringing a conclusion
to this effort which was started in June 2021. Thanks, Valentin! The
PR was delivered in the Jenkins 2.455 weekly release. No changes were
reverted.

Now that ASM is delivered via the plugin system, updates (such as
those that add support for new Java versions) can be delivered more
quickly outside the Jenkins core weekly/LTS cycle.

The SCM API plugin still depends on the ASM library plugin, a
plugin-to-plugin dependency that could be eliminated in future cleanup
work if desired. That potential cleanup is tracked in JENKINS-72891.

-- 
You received this message because you are 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/CAFwNDjpMB4o%3Dz1ijrcAhcNn5LJkSPjWL9qaDK9BLtbRPe4ZJvA%40mail.gmail.com.

Re: Updating detached plugins

[Basil Crow]

Thanks, Daniel. I'll plan on proceeding with a lazy consensus decision
that from now on, we'll accept the Dependabot PRs that update detached
plugins, we'll keep the test ignored, and we won't run the ignored
test manually for Dependabot PRs. If nobody objects to this lazy
consensus decision by Monday, I'll consider the matter settled and
merge jenkinsci/jenkins#9109.

-- 
You received this message because you are 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/CAFwNDjpYBAg_aa1tCtMx413x7OL%3D9yr9TUSa%2BJh9kiX0ymWUgg%40mail.gmail.com.

Re: Modernize core dependency json-lib library

[Basil Crow]

On Wed, Apr 10, 2024 at 7:50 PM Bob Du  wrote:
>
> Before that, I checked and compared the code and found that the fork 
> dependency version currently in use should have been built and released from 
> the rebase-2.4 branch, not master.

I confirmed that by comparing the sources JAR on Artifactory to the
rebase-2.4 branch. I've swapped the branches as you suggested.

-- 
You received this message because you are 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/CAFwNDjrwSZLQw_f%3DN2%3Dr-kMHkkAF7b_fKT7%2BOfOV_YLKmr10CA%40mail.gmail.com.

Re: Modernize core dependency json-lib library

[Basil Crow]

On Thu, Apr 11, 2024 at 6:31 AM 'Jesse Glick' via Jenkins Developers
 wrote:
>
> I think it is worse than that

Note that I wrote "migrate core *and* plugins", which would mean
creating a new method that returns a different type and adjusting
consumers accordingly. If we were to upgrade to the latest
(org.kordamp-based) JSON-lib, we could possibly provide bridge methods
for the old package namespace, but otherwise consumers would need to
be changed more drastically to consume a different library's JSON
object. Yes, it is the worst category of Jenkins migrations, in the
same category or worse as the Jakarta EE servlet migration; but no, it
is not worse than what I wrote in my previous message.

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

Re: Modernize core dependency json-lib library

[Basil Crow]

Hey Bob, thank you for proposing this!

Jenkins core delivers JSON-lib under the net.sf package namespace,
consumes it itself, and provides it to many consuming plugins. It
looks like Andres Almiray is still maintaining JSON-lib and EZMorph
over at https://github.com/kordamp/json-lib and
https://github.com/kordamp/ezmorph, but these new versions use the
org.kordamp package namespace and depend on Commons Lang 3 — both of
which go against our goal to avoid increasing core API surface area by
exposing additional third-party libraries.

Ultimately core needs to be able to parse JSON itself, and the Java
Platform does not provide a built-in way to do this. Under the current
architecture, where all core dependencies are exposed to plugins, that
means we can't avoid exposing at least _one_ JSON library to plugins:
the one used by core itself, which is currently JSON-lib under the
net.sf package namespace. Even if we did want to migrate core and
plugins to a newer version of JSON-lib or a different JSON library
(and I'm not sure we do), we'd have to continue to support JSON-lib
under the net.sf package namespace during the transition period at the
very least.

So your idea of cleaning up our old fork of (net.sf-based) JSON-lib to
at least avoid Commons Lang 2 sounds practical indeed in the short to
medium-term. At least that will allow us to proceed with cleaning up
Commons Lang, even if the JSON mess remains — a problem which can be
dealt with separately, if we ever need to deal with it at all. Another
argument in favor of this proposal is that it is no worse than the
current status quo, but a strict improvement in that it decreases
core's API surface area — without any risk of regression. These
advantages are not insignificant when dealing with such an old
codebase.

I could support this plan with one minor tweak. As I wrote in another
thread recently, I think modernizing the build and CI system should be
done before any other changes, because it is difficult to review and
test the other changes without a working build and CI system. In part
due to the success of the Jenkins project, the bar for software
development has been raised throughout the industry such that a modern
build and CI system is now considered table stakes. Accordingly, I
think this should be done first, and then the other changes you have
mentioned. So I would kindly request that you first prepare a PR to
update the build to use the latest parent POM and Jenkinsfile. Without
commit access to the repository in question, you won't be able to test
Jenkinsfile changes on ci.jenkins.io, but I can assist with testing
these changes using my permissions. Here are some other core
components that can be used as a reference:

https://github.com/jenkinsci/bridge-method-injector
https://github.com/jenkinsci/core-annotation-processors
https://github.com/jenkinsci/extensibility-api
https://github.com/jenkinsci/extras-memory-monitor
https://github.com/jenkinsci/jelly
https://github.com/jenkinsci/jenkins-test-harness
https://github.com/jenkinsci/jenkins-test-harness-htmlunit
https://github.com/jenkinsci/lib-access-modifier
https://github.com/jenkinsci/lib-annotation-indexer
https://github.com/jenkinsci/lib-crypto-util
https://github.com/jenkinsci/lib-file-leak-detector
https://github.com/jenkinsci/lib-mock-javamail
https://github.com/jenkinsci/lib-process-utils
https://github.com/jenkinsci/lib-support-log-formatter
https://github.com/jenkinsci/lib-symbol-annotation
https://github.com/jenkinsci/lib-task-reactor
https://github.com/jenkinsci/lib-test-annotations
https://github.com/jenkinsci/lib-version-number
https://github.com/jenkinsci/remoting
https://github.com/jenkinsci/stapler
https://github.com/jenkinsci/winstone

-- 
You received this message because you are 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/CAFwNDjpYPes0AZO-picQnRuGL9_PeASAcCK9h51LFyybG2bv6g%40mail.gmail.com.

Re: Updating detached plugins

[Basil Crow]

On Tue, Apr 9, 2024 at 12:33 PM 'Daniel Beck' via Jenkins Developers
 wrote:
>
> Are you aware of examples of this problem other than the two Jira issues?

Daniel, I am not aware of any such examples.

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

Updating detached plugins

[Basil Crow]

Since before my involvement as a core maintainer, we have apparently
had a policy to "only update detached plugins when we are forced to,
for example because there was a security advisory," and to run
LoadDetachedPluginsTest#noUpdateSiteWarnings when updating them. This
policy predates my involvement as a core maintainer, and when it was
introduced to me the reasoning behind it was not explicitly stated.

In recent years a few things have changed. First, we have seen an
increased need to update libraries to satisfy security scanners, even
when the old versions are not exploitable in Jenkins. Second,
Dependabot is now proposing updates to these detached plugins, and
ignoring these updates results in stagnant PRs. Third, we have
occasionally seen a need to mitigate the impact of JENKINS-69361.

Since 2022 I have been regularly updating detached plugins, justified
as an exception to the usual policy in order to mitigate the impact of
JENKINS-69361. At this point in 2024, the exception has become the
rule, so I would like to propose a change in policy to update detached
plugins as the Dependabot PRs come in, for the reasons given in the
preceding paragraph.

Since manually running LoadDetachedPluginsTest#noUpdateSiteWarnings
for each Dependabot PR is a nuisance, I would also like to propose
that we drop the requirement for running this test or that we enable
the test by default, accepting in the latter case that it will cause
some friction during the small window of time after a security
advisory marks a plugin release as vulnerable but before the relevant
Dependabot PR(s) is/are picked up.

The main issue regarding updating detached plugins, if I recall
correctly, was that this may (possibly?) limit users' ability to
downgrade these plugins below the version that we bundle. I am not
sure if this claim was ever verified. If this claim is verified,
either by a user reporting the inability to downgrade such a plugin,
or by manual testing, then I could possibly be fine with retaining the
existing policy but disabling Dependabot updates to detached plugins
to reduce PR noise.

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

Re: ASM in core

[Basil Crow]

On Sat, Jan 13, 2024 at 5:09 AM Valentin Delaye (jonesbusy)
 wrote:
>
> Jumping into this

Are you still interested in removing ASM from core? I checked usage in
plugins, and I believe all significant plugins are now linking against
the ASM library plugin. The last major blocker was the JaCoCo plugin,
which was released today. I also checked the CloudBees Update Center
and didn't find any ASM usages there. We are at the beginning of a new
LTS development cycle, so I think now is the ideal time to remove ASM
from core.

-- 
You received this message because you are 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/CAFwNDjq%3D_LRta%2BfAmBMhpTwBC2aXQ2BriDhnWC2y2FFVrcg8Ug%40mail.gmail.com.

Re: Windows-arm64 native support

[Basil Crow]

On Fri, Apr 5, 2024 at 2:40 AM Tim Jacomb  wrote:
>
> From my point of view GitHub actions is fine.
> I don’t think we want to add something that takes so long to install to our 
> image builds.

That could be a fair position, if it is the consensus of the Jenkins
infrastructure team. But before we draw that conclusion, I think we
should confirm empirically that this is the case. For example, maybe
there is an existing image we could use after adding the Jenkins agent
binaries. In any case, I leave this to the infrastructure team to form
a consensus.

-- 
You received this message because you are 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/CAFwNDjp4nfbZH9kFo-KSts0rd7UkZZG5FdfV6f4F8PugVNQ%2BAQ%40mail.gmail.com.

Re: Windows-arm64 native support

[Basil Crow]

On Fri, Apr 5, 2024 at 1:02 AM Pierrick Bouvier
 wrote:
>
> I reiterate politely my demand: Could we merge the changes required, let 
> someone trusted (you, or any Jenkins core dev, not me) build the binaries, 
> commit them, make a new release, and call it a day?

Is "demand" a bit aggressive? I reiterate politely my _request_: that
we eliminate the checked-in binaries and implement CI/CD as a
prerequisite to _any_ change that modifies the binaries (including
adding ARM64 support), for the reasons stated earlier: that this work
needs to be done, and there won't ever be a strong incentive to do
this at any other time. (I do not see any reasoning for your demand.)

-- 
You received this message because you are 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/CAFwNDjpt3_KtRrLE%3DQZu%3DsKZjh8AWFSe_9L6RNP8w-NLW8C1NA%40mail.gmail.com.

Re: Windows-arm64 native support

[Basil Crow]

On Fri, Apr 5, 2024 at 12:53 AM Pierrick Bouvier
 wrote:
>
> > Even if there is not a simple solution using the Java Platform, I am 
> > guessing winp specifically could be removed in favor of executing `wmic` 
> > commands or something like that, or that could be a fallback in case of an 
> > unsupported binary platform.
>
> Nice idea.

Not from my perspective. With two concurrent implementations, you
haven't really solved the problem. You now just have two problems.

-- 
You received this message because you are 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/CAFwNDjoembKs6RiYgMhQmi7JTxf%3DzQxdjuyUKvEoSvo1n1Mx5A%40mail.gmail.com.

Re: Windows-arm64 native support

[Basil Crow]

On Fri, Apr 5, 2024 at 12:44 AM Pierrick Bouvier
 wrote:
>
> If I follow the documentation you sent (container-agents), it seems that 
> Visual Studio is not available in those containers.
> What should be the steps to add Visual Studio into this:
> - Create a new container?
> - Install it dynamically (takes one hour easily...)?

This is a question for the Jenkins infrastructure team, who from the
beginning has been (trying to) work with you to achieve this. If the
infrastructure team evaluated this request and declined it, then (and
only then) would I support the use of GitHub Actions. We should be
working _with_ the infrastructure team, not around them.

> If you need one last argument, AppVeyor CI was added to this repo a few years 
> ago.
> Probably because without having to modify anything on infra side, someone 
> could have a pipeline running.

But maybe something _should_ have been modified on the infrastructure side.

> But it's a bit rude to hear "it's not that hard" and having a proof like "I 
> installed a java program, and it worked".

Ignoring the first half of your sentence, reaching out to the
infrastructure team _isn't_ that hard, and my proof was that I
installed a _non-Java_ program and it worked.

-- 
You received this message because you are 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/CAFwNDjr_kauAaEw%3DoGxx80Nm2a%2BvZuy5eUg1DbAfbqz%3DMhmyEQ%40mail.gmail.com.

Re: Windows-arm64 native support

[Basil Crow]

I considered writing a similar post myself a few days ago, and I also
think it is time for winp to be retired, but there are a lot of
challenges associated with removing winp in favor of a simpler
implementation using native Java process handling or simpler Windows
primitives. The existing native implementation is highly tuned and
battle-tested, with such behaviors as attaching to the console and
sending literal Control-C events at the console level. I can't think
of a good reason for this, but it is an example of the stereotypical
two-page function described in
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
as a "hairy mess." I am sure the high-level objectives of tracking
child processes and terminating them gracefully (for some definition
of "gracefully") could be achieved with a rewrite using simpler
primitives, but I also fear this would introduce a high risk of
regression—if anything, I suspect many consumers implicitly depend on
the existing implementation details and that any change in behavior
(even a justifiable one) would create some pushback for at least a
subset of users.

While we do run basic test automation on Windows, we don't have much
in the way of test automation that tests the edge cases of native
process handling. That, coupled with the general difficulty of
reviewing rewrites, means that we'd be relying on users of weekly
releases to test the rewritten code and report issues. And the failure
mode here is subtle: mistakes in process handling might not cause
outright failures, but might cause leaked processes to accumulate over
time, delaying the discovery of the problem.

While we do encourage first-time contributors, I think it would be
tricky for a first-time contributor to submit a rewrite like this,
because potential problems might not be discovered for several weeks,
at which point the motivation (or funding) to work on the project
might have decreased. While not insurmountable, I think these
challenges have caused me to have a preference for incremental
improvement rather than a rewrite, especially given that the interest
is coming from a first-time contributor. As annoying as it is to delve
into an unfamiliar codebase and write a CI/CD script for an abandoned
codebase, at least the problem is well-defined, and we can be assured
that the result won't break existing use cases. With a rewrite, that
risk increases and I think we would have to be very careful about
review, testing, and (potential) regression management. If a long-time
contributor like yourself proposed to do such a rewrite, I would feel
more comfortable with it, especially if that long-time contributor
promised to be around to deal with any regressions.

-- 
You received this message because you are 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/CAFwNDjqTOUehtZtVSvCL2T0g_a2guvektiy%3DTB2WCx6XsXi70g%40mail.gmail.com.

Re: Windows-arm64 native support

[Basil Crow]

On Thu, Apr 4, 2024 at 12:24 AM Pierrick Bouvier
 wrote:
>
> Thanks for taking the time to answer and give a direction Basil, it's 
> definitely more constructive than saying "do not ping me".

"Do not ping me" definitely still stands from my side regarding
questions about the current code, even if I did last touch some of the
files in question, trying to keep this component on life support. I
didn't write the current code, I didn't check in the pre-built
binaries, I can't explain the reasoning behind past decisions, and I
can't help you understand the current implementation. The expectation
is that the contributor will have to figure all this out, as I did
when working on a different abandoned repository (PCT) several months
back.

Of course we are willing to guide anyone to the desired end state, and
that desired end state includes running CI builds on Jenkins.

> I'm fine doing this work, it it's allowed on my side. I'll come back to you 
> once I have an answer.

Great! We'd love to see this finally fixed. As you saw in the previous
contributor's PR, this has been an issue for a long time.

> The problem for me is not to install or use my own jenkins server (I did a 
> lot of this in the past), but to be able to understand what is inside your 
> runner image exactly, and how to request new stuff (plus additional time to 
> wait for someone to answer).

Aren't these the same problems as with GitHub Actions? In both cases,
the user does not have access to the server while the CI job is
running. In both cases, the images should have a reasonable amount of
build software installed in order to facilitate efficient development.
In both cases, the software installed needs to be documented to
facilitate efficient development (in our case,
https://github.com/jenkins-infra/documentation/blob/main/ci.adoc#container-agents
describes the setup on our agents). And in both cases, there needs to
be a way to install or enable software dynamically (e.g. using GitHub
Actions' setup-java, or Jenkins' tool installation subsystem). I am
aware of deficiencies on the Jenkins side with regard to Docker,
documented in https://github.com/jenkins-infra/helpdesk/issues/3587,
but that doesn't apply here.

In short, this is essentially the same process, certainly not "a
pretty huge ask and unfair" or "essentially saying no" as Gavin Mogan
claimed. And as proof of this, I have done exactly the same thing
myself in the past, resurrecting the Packaging repository from an
abandoned state and developing a CI job there against a VM agent where
I install Puppet and run a custom non-Maven build.

-- 
You received this message because you are 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/CAFwNDjpi0J63a%2B%3D2gjOd_Wn8zmk9OvPqVppCT0EfNMFoBE4vAg%40mail.gmail.com.

Re: 2.452 as May 15, 2024 LTS baseline?

[Basil Crow]

+1 for 2.452. Recent weeklies have been solid, and 2.452 is a
particularly good choice because it contains the recent Mina SSHD
updates.

-- 
You received this message because you are 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/CAFwNDjqcgrwJGeHPCYccrJLoxH8XERgCuxMuahb1-ggeYnCZLg%40mail.gmail.com.

Re: Windows-arm64 native support

[Basil Crow]

On Thu, Mar 28, 2024 at 11:16 PM Pierrick Bouvier
 wrote:
> Thanks for your help, I'll take a look at this.

And thanks for your interest! Unfortunately I think
https://github.com/jenkinsci/winp/pull/112 is premature, as the
repository is not currently in a state where _any_ outside
contributions to the native C++ code can be accepted, as the Jenkins
CI build uses precompiled binaries rather than building the C++ code
from scratch.

In order for us to be able to accept contributions to the native code
like yours, we first need to set up a proper build environment with no
pre-compiled binaries, a CI build (ideally Jenkins CI) that compiles
both the Java code and the native code and runs the tests, and
(ideally) a CD process on GitHub Actions that compiles both the Java
code and the native code and performs the release. Our existing CI/CD
infrastructure is heavily Maven-centric, so it would be preferred to
use Maven as the entrypoint into the process and then to vector into
the native code compilation from within Maven.

My strong preference is for the above work to be done as a
prerequisite to adding ARM support. The status quo is already
untenable, even without taking into consideration the changes needed
to add ARM support. I am a -1 on using GitHub Actions for CI, and I am
a -1 on adding ARM support using the existing status quo of prebuilt
binaries before solving the existing technical debt of the incomplete
CI/CD process. The reason for this is that I believe there will not be
a strong incentive to work on the long-term CI/CD process once the ARM
support is added. Therefore I am against adding any new features,
including ARM support, before the existing technical debt is
addressed.

Since commit access is required to test Jenkinsfile changes on
ci.jenkins.io, I would propose to first add you as a winp committer
alongside the Jenkins core team (but not a committer on any other
repositories). This would allow you to test Jenkinsfile changes on
ci.jenkins.io.

The next steps after that, in this proposal, would be for you to
develop two PRs, the first PR updating the Jenkinsfile to compile the
native code as part of the Maven build rather than using pre-built
binaries, and the second PR implementing CD with GitHub Actions. The
first of these will require collaboration with the Jenkins
infrastructure team to provide an appropriate stateless build
environment. Once this is working, your commit access can be removed,
and the core maintainers can click the CD button to perform a release
from the sources without any prebuilt binaries. Since this release
will have been compiled entirely on Jenkins infrastructure with no
prebuilt binaries, it can be trusted and adopted by Jenkins core. At
this point, the technical debt would be solved and the repository
would become open to new features again.

Unfortunately there is no existing maintainer to complete this
prerequisite work. But after this is all said and done, you can
proceed with your original PR to add ARM support, which should be easy
for any core maintainer to approve and release (with CD) once the
repository has no more prebuilt binaries and a working CI/CD process.

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

Re: Windows-arm64 native support

[Basil Crow]

I am not aware of anyone who is actively maintaining the winp
component. You could take ownership of the winp component, set up CI
builds and tests, and then do a release with Windows ARM64 support.

-- 
You received this message because you are 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/CAFwNDjqgY054naAeTKFUmYWx9gxo7gLCfzoX%3D%3DkWKqc72sT8SQ%40mail.gmail.com.

Re: Adoption request for scmskip plugin

[Basil Crow]

+1

On Sun, Mar 24, 2024 at 11:34 AM Verachten Bruno  wrote:
>
> +1 from me, of course.
> Thanks, Zbynek.
>
> On Sun, Mar 24, 2024 at 4:10 PM zbyne...@gmail.com  
> wrote:
> >
> > Hi,
> >
> > the scmskip plugin is up for adoption. I'd like to adopt it in order to 
> > deliver some bugfixes.
> >
> > plugin pull request: https://github.com/jenkinsci/scmskip-plugin/pull/25
> > RPU pull request: 
> > https://github.com/jenkins-infra/repository-permissions-updater/pull/3831
> > GitHub username: zbynek (alrady member of jenkinsci organization)
> > Jenkins username: zbynek
> >
> > Cheers,
> > Zbynek
> >
> > --
> > You received this message because you are 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/75c1df3b-0399-47b0-a465-0e40470f9afdn%40googlegroups.com.
>
>
>
> --
> Bruno Verachten
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CACtV%3Dde1R00DK7bxx%2Bh%3DaHj%2BztbABnLBRLt0xKz-RYsVK65pUg%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/CAFwNDjqwq4idj2LWu6KtSAck%3Dt3cEegzmRUYWQTFAGcaR%2B%2BUVQ%40mail.gmail.com.

Re: Aborting pipeline from a plugin

[Basil Crow]

On Fri, Mar 22, 2024 at 2:11 PM zbyne...@gmail.com  wrote:
> What is the correct way to abort pipeline programmatically?

See 
https://javadoc.jenkins.io/plugin/workflow-step-api/org/jenkinsci/plugins/workflow/steps/FlowInterruptedException.html.

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

Re: Stop publishing fat plugin aws-java-sdk

[Basil Crow]

The latest release of Pipeline: AWS Steps (which we use on
ci.jenkins.io) still uses the fat JAR, although Zbynek updated it to
use the new modules in a PR that has been merged but not yet released.

-- 
You received this message because you are 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/CAFwNDjqP7hz9fyyh1CHFJUdZSysswk%3DQfKi7OTh_Cibg-vY%2BCQ%40mail.gmail.com.

Re: Multiple questions on Jenkins plugin repo management

[Basil Crow]

On Wed, Mar 20, 2024 at 9:05 AM Stéphane BOBIN
 wrote:
> I am puzzled because the PR was done on jenkinsci repo for my plugin 
> (https://github.com/jenkinsci/mathworks-polyspace-plugin/actions), which is a 
> sync of the main repo, and all actions worked fine here.
> While on the mathworks repo for my plugin, which is the main repo 
> (https://github.com/mathworks/mathworks-polyspace-plugin/actions), there is a 
> recurring failure on ".github/workflows/release-drafter.yml".
> What does that mean? How can I fix?

Copy the Release Drafter configuration from
https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.yml
into your GitHub organization.

> It looks like the Jenkins release page 
> (https://plugins.jenkins.io/mathworks-polyspace/releases/) is the page where 
> one creates the details on a new release to be displayed on the Jenkins 
> release page (https://plugins.jenkins.io/mathworks-polyspace/releases/).
> Correct?
> Where to find the icons?
> What is the icon/tag spec (rocket/new features, ghost/maintenance, 
> caterpillar/bug fixes, ...)?
> Some documentation available about this?

See 
https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.adoc.

-- 
You received this message because you are 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/CAFwNDjrZo6_URBv8g9wHMf03NdhE%2B7wxt%2BFGAu6FWhDaicdR2g%40mail.gmail.com.

Re: Remove Suggestimate from issues.jenkins.io?

[Basil Crow]

+1

On Mon, Mar 11, 2024 at 6:48 AM Mark Waite  wrote:
>
> The Jenkins Jira instance uses a Jira datacenter license that is donated to 
> the Jenkins project by Atlassian.
>
> The Suggestimate plugin is installed on the Jenkins Jira instance and is 
> reporting that its license has expired.  The Suggestimate pricing page says 
> that the plugin would cost $4500 per year based on the number of users of our 
> Jira instance.  The question and answer section indicates that our donated 
> Jira Datacenter license does not include the license for the plugin.
>
> I propose that we should remove that plugin from issues.jenkins.io rather 
> than pay a licensing fee for the plugin.
>
> Any objections to the removal of that plugin from issues.jenkins.io?
>
> 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/a96f9c00-ff28-47fb-a3eb-210826ae5d7dn%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/CAFwNDjpaspVJWUAHtyYjNSMxrvkhZmws5GwNbqZjCshgND0vbQ%40mail.gmail.com.

Jakarta Activation 2.1.3, Jakarta Mail 2.1.3, and Eclipse Angus

[Basil Crow]

A year after I reported
https://github.com/jakartaee/mail-api/issues/665 upstream, a fix has
finally been released in Jakarta Mail 2.1.3, allowing me to finally
migrate the Jenkins ecosystem to Jakarta Activation 2.1.3, Jakarta
Mail 2.1.3, and Eclipse Angus. This in turn finally eliminates the
namespace conflict with the old javax plugins, resolving
JENKINS-70627. The change has been deployed to production users for a
few days with no reported issues. Thanks to Olivier Lamy for making
the first commit in this direction over a year ago.

There is some low-priority cleanup work remaining, which I do not have
the energy to do right now. JENKINS-72822 describes how to remove the
last remaining workaround in this subsystem, something that is
possible now that we are on Jakarta Activation 2.1.3 if the Jakarta
Activation API plugin and Jakarta Mail API plugins were first merged
into a single plugin. Upstream has assured me the workaround is part
of a stable API and should continue to work, so I see no urgent need
to work on this in the short to medium term. But if anyone is
interested, once the plugins are combined into one, removing the
workaround should be as simple as deleting all Java files from Jakarta
Mail API plugin.

The other bit of cleanup is migrating Mock JavaMail usages to the new
APIs. This is low priority since it only affects tests and is not
blocking any production users or BOM/PCT work. I filed a handful of
PRs to update the most important consumers in the jenkinsci GitHub
organization, but for the sake of posterity the instructions are as
follows:

1. Upgrade jakarta-activation-api and jakarta-mail-api to 2.1.3-1 in a
 section (until these are in a BOM release).
2. Upgrade mock-javamail to 2.2, adding exclusions for
jakarta.activation-api, jakarta.mail-api, angus-activation, and
angus-mail.
3. Ensure the dependency on jakarta-mail-api is above the dependency
for mock-javamail, after configuring Surefire to use system property
variables for mail.smtp.class, mail.pop3.class, and mail.imap.class.

Examples here:

https://github.com/jenkinsci/claim-plugin/pull/278
https://github.com/jenkinsci/email-ext-plugin/pull/503
https://github.com/jenkinsci/mailer-plugin/pull/272
https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/300

-- 
You received this message because you are 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/CAFwNDjrXpvow8PKmgmkjdT%2B78VUqgdwCVD_oMrN%2B7Dn4gX3cOQ%40mail.gmail.com.

Re: Error in Javadoc when attempting to publish a new plugin version

[Basil Crow]

You can reproduce locally by running mvn clean verify -Pjenkins-release and
on CI by enabling incrementals
. Be
sure to use the same version of Java you intend to use when doing the
release, as different Java versions produce different errors.

-- 
You received this message because you are 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/CAFwNDjqEWaYB9Kb21Mkzr9VCW9H8v6%2BG%3Dr6_UpuaGg3PyTUTnA%40mail.gmail.com.

Re: Error: Could not find or load main class com.mathworks.polyspace.jenkins.PolyspaceHelpers

[Basil Crow]

This seems to assume the build is running on the built-in node,
something we no longer recommend:

https://www.jenkins.io/doc/book/security/controller-isolation/#not-building-on-the-built-in-node

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

Re: Proposal: Stefan Spieker to join the core PR reviewers team

[Basil Crow]

+1

On Sun, Feb 18, 2024 at 10:07 PM Mark Waite 
wrote:

>
>
> On Sunday, February 18, 2024 at 9:30:35 AM UTC-7 Alexander Brandes wrote:
>
> Hey everyone,
>
> I would like to propose Stefan Spieker (@StefanSpieker
> ) to join the core PR reviewers team.
>
> Stefan has been a core contributor since October 2022, and filed 172
>  pull
> requests, where 171 PRs have been merged.
> Additionally, he has been active in reviewing core PRs and has voiced his
> opinion in almost 300
> 
>  pull
> requests.
>
> I would welcome him as an addition to the core pr team :)
>
>
> +1 from me.
>
> 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/28e931e5-26e9-47c4-80c7-87871a4a929en%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/CAFwNDjrpBy1cWe%3DXGyhub1jKnExrd-Zr6GD%3Dn2KT3ObvgTRTBg%40mail.gmail.com.

Re: 2.440.1 Release Lead

[Basil Crow]

+1

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

Re: 2.440 as Feb 21, 2024 LTS baseline?

[Basil Crow]

+1

-- 
You received this message because you are 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/CAFwNDjrgB%3Db0QfV2UmaW%2B1ssoBahJBesda4BK9PEa5nPgQoKJg%40mail.gmail.com.

Re: January 8, 2024 Governance Board Agenda

[Basil Crow]

On Mon, Jan 8, 2024 at 11:48 AM 'Gavin Mogan' via Jenkins Developers
 wrote:
>
> is that alternatives to locking it down?

Alternatives to restoring from backup. We ended up restoring from backup.

-- 
You received this message because you are 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/CAFwNDjqJvLJLbkuN%3DDYtw%2B%2BimA-HHN%2BcLFSDh-A9158xgF8%2B-g%40mail.gmail.com.

Re: ASM in core

[Basil Crow]

Fast forward a little over a year and removing ASM from core in favor
of dynamic linking through a library plugin seems more achievable,
though still quite a bit of work. The following plan seems achievable:

- Create a new ASM library plugin. It would be unused as long as core
keeps shipping ASM, since core's copy would take precedence.
- Make the JNR POSIX library plugin depend on the ASM library plugin.
- Make the JSON Path library plugin depend on the ASM library plugin.
- Make anything that consumes ASM directly depend on the ASM library
plugin (using usage-in-plugins to find all the things).
- Make anything that currently ships the JARs mentioned above depend
on the corresponding library plugin instead (using usage-in-plugins to
find all the things).
- Remove ASM from core.

This is probably a dozen or so PRs to cover plugins with over 10,000
installations, and maybe another dozen or so PRs to cover plugins with
over 1,000 installations, if anyone is interested.

On Mon, Aug 22, 2022 at 7:22 PM Basil Crow  wrote:
>
> I think detaching is riskier than I expected: a lot of plugins bundle
> old copies of ASM (or depend on other plugins that do). With core's
> copy no longer taking precedence, I fear that there might be a high
> risk of regression with a detached plugin. Seems safer to deal with
> each plugin on a case-by-case basis.
>
> I searched for usages of ASM (both direct and transitive) in both
> open-source and proprietary plugins. After filtering out plugins that
> bundled a recent (9.x) ASM JAR in their JPI, plugins whose only usage
> of ASM was through Commons Compress Pack200 support (probably not
> used), plugins with fewer than 1,000 installations, and plugins that
> have already been deprecated, I came up with the following list:
>
> https://plugins.jenkins.io/analysis-model-api - via cglib (via Commons
> Digester) and com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/checkmarx - via xbean-reflect-3.7.jar
> https://plugins.jenkins.io/clearcase - via cglib (via Commons Digester)
> https://plugins.jenkins.io/clover - via cglib (via Commons Digester)
> https://plugins.jenkins.io/cvs - via cglib (via Commons Digester)
> https://plugins.jenkins.io/dependency-check-jenkins-plugin - via cglib
> (via Commons Digester)
> https://plugins.jenkins.io/deploy - via
> org.glassfish.main.deployment:deployment-common
> https://plugins.jenkins.io/git-changelog - via
> com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/github-autostatus - via JNR
> https://plugins.jenkins.io/github-pr-coverage-status - via
> com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/hp-application-automation-tools-plugin -
> com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/jacoco - directly
> https://plugins.jenkins.io/jnr-posix-api - via JNR
> https://plugins.jenkins.io/kubernetes-pipeline-devops-steps - via JNR
> https://plugins.jenkins.io/maven-dependency-update-trigger - via Plexus
> https://plugins.jenkins.io/maven-info - via cglib (via Commons Digester)
> https://plugins.jenkins.io/multibranch-scan-webhook-trigger -
> com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/pipeline-model-definition - directly
> https://plugins.jenkins.io/scm-api - directly
> https://plugins.jenkins.io/synopsys-coverity - via
> com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/teamconcert - via cglib (via Commons Digester)
> https://plugins.jenkins.io/token-macro - via
> com.jayway.jsonpath/net.minidev:json-smart
> https://plugins.jenkins.io/warnings-ng - via
> com.jayway.jsonpath/net.minidev:json-smart
>
> These could all be dealt with, but dealing with the long tail
> (anything less than a few thousand installations) would be a huge
> amount of work. If we expect someone to do that work for all the
> plugins listed above, then count me out because the expected value is
> just not worth the effort. If, on the other hand, we would be OK with
> leaving behind a substantial number of the above plugins (especially
> those that have only a few thousand installations and/or have not been
> released in years), then I think this could be doable.

-- 
You received this message because you are 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/CAFwNDjrLMjtskWOeh0ptBeDjoUa41j0WAAqqoQ34yb5DwHg_-Q%40mail.gmail.com.

Re: CVE-2023-50164 Struts question

[Basil Crow]

My unofficial answer: Jenkins uses Stapler as its web framework (not
Struts), so I strongly suspect there are zero Jenkins plugins
distributed on our Update Center that bundle Struts 2 or 3. For an
official answer, contact the Security Team at:

https://www.jenkins.io/security/team/

-- 
You received this message because you are 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/CAFwNDjqffiHNRYsaTiqV_RBBmTvCs%3DDMZiz%2BFW_KabTpfw%3D1rA%40mail.gmail.com.

Re: Banned dependencies error compiling SAML plugin PR

[Basil Crow]

Agreed; this is neither recommended nor supported.

On Mon, Dec 18, 2023 at 1:09 PM James Nord  wrote:
>
> All the supporting code for providing a warning about this has been removed 
> from the update center and Jenkins IIRC.
>
> So you will have no warning when you try and install the plugin - but it will 
> blow up at runtime if you try and use it.
>
> Which is probably not a good idea for a critical plugin like an 
> Authentication or Authorisation based plugin.
>
> /James
> On Wednesday 13 December 2023 at 12:20:09 UTC ullrich...@gmail.com wrote:
>>
>> The correct setting is:
>>
>> 17
>> 17
>>
>>
>> Am 13.12.2023 um 12:55 schrieb 'Jesse Glick' via Jenkins Developers 
>> :
>>
>> On Wed, Dec 13, 2023 at 5:56 AM Ullrich Hafner  wrote:
>>>
>>> I think our tool chain will accept Java 17 dependencies if you explicitly 
>>> declare it as supported by setting the java.version in you pom.
>>
>>
>> If you meant java.level, no, this is gone as of 
>> https://github.com/jenkinsci/plugin-pom/releases/tag/plugin-4.40
>>
>> --
>> You received this message because you are 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/CANfRfr0H-T7OQ8bUcw7KUFkA7bi8YZMXeY-n%2B4O_xkP%2BR5-%3DvA%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/a24e7247-9be1-4d4b-91ac-76ef52a21009n%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/CAFwNDjqWfXKzZvEaCthXQnWJuUPJOiwWV3fX5nCtYELXp6GoXA%40mail.gmail.com.

Re: 2.426.3 Release Lead

[Basil Crow]

+1

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

Re: JSON license

[Basil Crow]

We have also explicitly clarified that public domain dedications and
public-domain-equivalent licenses are acceptable in the project
governance document.

-- 
You received this message because you are 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/CAFwNDjoZW2uaZY-cmhZZ30N19h4SGLCu7AQMMjceJtno9UG-Uw%40mail.gmail.com.

Re: Banned dependencies error compiling SAML plugin PR

[Basil Crow]

As of v6.x, pac4j requires Java 17 or newer. The Jenkins plugin
development toolchain will not accept Java 17 bytecode as long as
Jenkins core still supports Java 11. You will need to stay on v5.x of
pac4j until around fall of next year when Jenkins requires Java 17 or
newer.

-- 
You received this message because you are 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/CAFwNDjrCoZb186jw%2BOOXtF2JzBVw7X%2BUZw_LT2D0r7ngYdxeOQ%40mail.gmail.com.

Re: License for library plugins

[Basil Crow]

I proposed a (soft) recommendation to the documentation in
https://github.com/jenkins-infra/jenkins.io/pull/6936.

-- 
You received this message because you are 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/CAFwNDjqBVmOuVpQgGM8c85Sn_Xju5tAYo7-GVCwr%3DJ7kGkYGMg%40mail.gmail.com.

Re: License for library plugins

[Basil Crow]

This is a subjective question, but I feel that when the only thing in
src/main is src/main/resources/index.jelly the wrapper should be
licensed the same way as the library being wrapped, because our own
contribution to production code is de minimis. It seems strange to use
a different license when our unique contribution is just build/test
code. In cases where our contribution to src/main is nontrivial then I
am fine with applying our own MIT license to the plugin.

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

Re: Artifactory brownout Wed 6 Dec 2023 1:00 PM UTC - 3:00 PM UTC

[Basil Crow]

+1, I think we have done all the preparation we can for this change.

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

License for library plugins

[Basil Crow]

Library plugins are inconsistently licensed: sometimes, they adopt the
license of the wrapped library, while in other cases, they follow the
MIT license as normally used by Jenkins plugins. Does anybody have a
preference as to what we should recommend?

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

Re: How to implement writing to console log in pipeline?

[Basil Crow]

On Sun, Nov 19, 2023 at 2:50 AM tzach@gmail.com
 wrote:
> I'm developing a new plugin and I was able to write to log in FreeStyleJob  
> but it does not work in pipeline.

See 
https://www.jenkins.io/doc/developer/plugin-development/pipeline-integration/
for more information: Pipeline builds are instances of WorkflowRun and
therefore ParameterValue#createBuildWrapper(AbstractBuild) does not
apply to them. It is difficult to give a concrete suggestion without
seeing your code, but you may wish to refer to the tests in the
Pipeline plugins for examples.

-- 
You received this message because you are 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/CAFwNDjonx6X1ZFDybdmFe6DM2M7P2dY3Lvmi6-0O91rEbKS2vQ%40mail.gmail.com.

Re: Tests are failing with Unable to inject class hudson.model.UserIdMapper after upgrading the build from java 8 to java 11

[Basil Crow]

It looks like most of this was taken care of already in
https://github.com/jenkinsci/fortify-plugin/pull/72. I created
https://github.com/jenkinsci/fortify-plugin/pull/74 with some minor
cleanup on top of that.

-- 
You received this message because you are 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/CAFwNDjrTbdOXORgS99K6b4bQvwd97z%3DF3%3D0MXzTF3vUc7kefmA%40mail.gmail.com.

Re: DescriptorImpl which is not public static inside the parent class

[Basil Crow]

On Tue, Nov 7, 2023 at 7:31 AM tzach@gmail.com
 wrote:
>
> can I create a class which will function as DescriptorImpl but not reside 
> inside the parent class as public static class?

What problem are you trying to solve that leads you to this question?

-- 
You received this message because you are 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/CAFwNDjqzroXLwof3PHfqiZeiKu1%3D5fyMK4bG49tSYqQkLZJ1vQ%40mail.gmail.com.

Re: Backporting for 2.426.1 has started

[Basil Crow]

I created https://github.com/jenkinsci/jenkins/pull/8674 to get this
into a weekly release.

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

Re: Backporting for 2.426.1 has started

[Basil Crow]

On Sat, Oct 28, 2023 at 9:49 PM Mark Waite  wrote:
> If there are other issues that you would like to see backported to 2.426.1, 
> please add the lts-candidate label to the issue so that it can be reviewed.

As described in JENKINS-70994, SnakeYAML plugin
1.33-95.va_b_a_e3e47b_fa_4 is still bundled in the Jenkins WAR as a
detached plugin, which trips up security scanners. I recommend this be
upgraded to the latest version.

-- 
You received this message because you are 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/CAFwNDjrCFaxYhMYWexarNJCJRYNoRaQc1bX5-sMaD%3Deg0_p-4w%40mail.gmail.com.

JEP template improvements

[Basil Crow]

Not a JEP in and of itself, but some improvements to the JEP template:

- https://github.com/jenkinsci/jep/pull/401 Improve section order and
add clarity to existing sections
- https://github.com/jenkinsci/jep/pull/402 Add work estimate section
to template
- https://github.com/jenkinsci/jep/pull/403 Add migration section to template

I also intend, as time permits, to create a fourth PR to break up the
monolithic "Reasoning" section into distinct "Evaluation" and
"Solution" sections, as well as to retroactively file a JEP for the
completed Prototype removal project.

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

Re: Partially released plugin due to 403

[Basil Crow]

Have you read the instructions at
https://www.jenkins.io/doc/developer/publishing/releasing-manually/
which include making sure your plugin uses a reasonably up-to-date
parent POM? I created
https://github.com/jenkinsci/aws-codepipeline-plugin/pull/4 to try to
help with that. That document has two other pieces of troubleshooting
advice for 403 errors. If you still have problems after going through
all of that then you can create an issue at
https://github.com/jenkins-infra/helpdesk for an Artifactory
administrator to check your permissions.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjp2PGKrDCOEpDF1GMfNqpLtvA8vMDpCPsE%2BbEbN3Ni9CQ%40mail.gmail.com.

Re: auto release form branch or manual release of multimodule project

[Basil Crow]

On Thu, Oct 26, 2023 at 7:04 AM Jiri Vanek  wrote:
>
> I was fiddling with 
> https://github.com/jenkinsci/report-jtreg-plugin/blob/master/pom.xml#L27  
> (mostly reset to jenkinsci but it did not did the 
> job.

Just replace  with .

-- 
You received this message because you are 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/CAFwNDjpysG0nokQ31G5T9joyu9aqGXMpw%2BU60GheWPj%3DYqDPXg%40mail.gmail.com.

Re: Request to adopt AccuRev plugin (up for adoption)

[Basil Crow]

+1, thank you for stepping up to maintain this plugin.

This plugin's build has not been updated in a long time, so you should
expect to modernize some portions of the build before being able to do
a release. See the tutorial here:

https://www.jenkins.io/doc/developer/tutorial-improve/

-- 
You received this message because you are 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/CAFwNDjq_qi1yb-JvcZwZK8tYV5T%2BcptJT3QVjv5k_7xgiwd8xw%40mail.gmail.com.

Re: 2.426 as Nov 15, 2023 LTS baseline?

[Basil Crow]

On Fri, Oct 6, 2023 at 12:56 AM Jan Meiswinkel 
wrote:
>
> I would appreciate if PR-7056 would make it into the next LTS, if that is
possible without any downsides.

One downside is that jenkinsci/jenkins#7056
 causes JENKINS-72181
.

-- 
You received this message because you are 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/CAFwNDjoCnVaRKGPa2fyrJ9uFtVAhdtRyygzgAnN5NwP-5XL8xg%40mail.gmail.com.

Re: Backporting for LTS 2.414.3 has started

[Basil Crow]

That is the ideal technique, but it might be a lot of effort for the
release team for minimal gain. In practice I think it would suffice to
simply upgrade Remoting to the regular 3160.vd76b_9ddd10cc release on
the LTS line. Yes this is pulling in a few unrelated changes, but as
long as they are shipping in weeklies I don't see a big risk here. If
the release team wants to go through the extra effort, I would not
stop them, either.

-- 
You received this message because you are 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/CAFwNDjqC0yELqdQmnG%3Dn749i5Yz1gE_s8FqDCNtS4K-huB37jA%40mail.gmail.com.

Re: 2.426 as Nov 15, 2023 LTS baseline?

[Basil Crow]

On Wed, Oct 4, 2023 at 11:49 AM Mark Waite  wrote:
> I think that we'll also need to backport the fix for JENKINS-72026, though a 
> fix pull request has not been submitted yet.

AFAICT the fix for JENKINS-72026 is to add jenkins-table__link to the
class list of the anchor tags in
https://github.com/jenkinsci/branch-api-plugin/blob/fe580db4ea71e6a2ce440d8d79d55d8c1c6a4b93/src/main/resources/jenkins/branch/ItemColumn/column.jelly
which would not require a core PR or backport.

-- 
You received this message because you are 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/CAFwNDjoMpW2VhtqDSLjD%3DDmy%2BOH5Uvwnn42yp%2BsWJvnytVH1ew%40mail.gmail.com.

Re: 2.426 as Nov 15, 2023 LTS baseline?

[Basil Crow]

+1

We'll likely need to backport the fix for JENKINS-71937.

-- 
You received this message because you are 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/CAFwNDjpVnas%2BsRLfP1BPW02vCu%3DF97_My6KyVP55%2B0Mc-TH_ZQ%40mail.gmail.com.

Re: Proposal: Kris Stern to join the release team

[Basil Crow]

+1

On Mon, Oct 2, 2023 at 5:06 AM Hervé  wrote:

> FWIW, +1 from me too!
>
> --
> You received this message because you are 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/CAE1M8%2B9yQf3YzbEPkv%3DnAEQyPFoihRJL5cWGi6myVzwqM9EzZQ%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/CAFwNDjr3h1gnWGTSP0hfwVHd0-VWWA%3DYW_fnvQLr5VAume03Nw%40mail.gmail.com.

Re: remove j-interop and jcifs from core?

[Basil Crow]

On Mon, Sep 18, 2023 at 4:19 AM 'jn...@cloudbees.com' via Jenkins
Developers  wrote:
>
> What do you think?

I think this is a great idea. I am doing something similar for the old XML
Pull Parser 3rd Edition libraries in jenkinsci/jenkins#8503
.

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

Re: [ci.jenkins.io] JDK21 availability

[Basil Crow]

On Fri, Aug 11, 2023 at 1:11 PM Basil Crow  wrote:

> Thanks! This was already very helpful as it enabled me to file
> JENKINS-71805 <https://issues.jenkins.io/browse/JENKINS-71805>.
>

I meant JENKINS-71800 <https://issues.jenkins.io/browse/JENKINS-71800>.

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

Re: [ci.jenkins.io] JDK21 availability

[Basil Crow]

Thanks! This was already very helpful as it enabled me to file JENKINS-71805
.

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

Re: Jenkins 2.413 as next LTS baseline?

[Basil Crow]

On Mon, Jul 17, 2023 at 8:41 AM Basil Crow  wrote:

> There do not appear to be any known user-visible regressions in production
> code in 2.414, but jenkinsci/jenkins#7872
> <https://github.com/jenkinsci/jenkins/pull/7872> implies a change in
> Login Theme (3,757 installations) which has not yet been completed (tracked
> in JENKINS-71238 <https://issues.jenkins.io/browse/JENKINS-71238>) and
> jenkinsci/jenkins#7942 <https://github.com/jenkinsci/jenkins/pull/7942>
> implies a change in Calendar View (1,866 installations) which has not yet
> been completed (tracked in JENKINS-71663
> <https://issues.jenkins.io/browse/JENKINS-71663>). If these tasks are not
> completed by the time 2.414 LTS ships, they should be documented as known
> defects in the release notes.
>

How close are we to completing these tasks? It is not desirable to ship an
LTS release with known defects. If our users upgrade and encounter
regressions, they will lose trust in our software.

In addition to the above, jenkinsci/jenkins#7951
<https://github.com/jenkinsci/jenkins/pull/7951> implies a change in Global
Build Stats (6,641 installations) which has not yet been completed (tracked
in JENKINS-71741 <https://issues.jenkins.io/browse/JENKINS-71741>). If this
task is not completed by the time 2.414.1 LTS ships, this should be
documented as a known defect in the release notes.

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

Re: JSON license

[Basil Crow]

Ought to be made into a library plugin I think.

-- 
You received this message because you are 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/CAFwNDjrGMWc1S7GN8PNQR5qVaWe%2BmhU8V3%2Be208vbQxc4go%2Brg%40mail.gmail.com.

Re: Jenkins 2.413 as next LTS baseline?

[Basil Crow]

On Fri, Jul 21, 2023 at 10:42 AM 'jn...@cloudbees.com' via Jenkins
Developers  wrote:
> 2.414 has a regression in the plugin manager.
> I would be -1 on this unless that is fixed (currently missing a Jenkins bug 
> but has been the cause of a lot of ATH failures)
> https://github.com/jenkinsci/acceptance-test-harness/issues/1284 for the 
> current status/investigation, I will file a Jenkins bug on Monday to track.

Thanks for starting to investigate this. As I wrote in the discussion
at jenkinsci/acceptance-test-harness#1284, I was able to definitively
implicate jenkinsci/jenkins#8025 as the cause of the ATH test failure
by widening the race window with some sleeps, and I may have been able
to chase away the ATH test failure and/or fix the bug by removing the
asynchrony from the original change.

Since jenkinsci/jenkins#8025 was the last commit in 2.414 and since
2.414 contains some other changes that we want, I would like to
propose that we keep 2.414 as the next LTS baseline but simply revert
jenkinsci/jenkins#8025 from the stable branch before shipping. (An
equally plausible alternative would be to choose 2.413 and backport
the other changes that we want.)

As far as the main branch is concerned, now that I have come up with a
way to reproduce the original problem, I would like to propose that we
give folks a limited amount of time (say, a week) to come up with a
solution and otherwise revert jenkinsci/jenkins#8025 on the main
branch as well to restore stability to the ATH test suite.

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

Re: Prototype.js replacing JSON.stringify

[Basil Crow]

Many thanks to everyone who has contributed PRs to remove usages of
Prototype.

I did a more thorough search for usages of Prototype, this time scanning
every .jelly and .js file in the Update Center. I updated the spreadsheet

.

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

Re: Removing inactive CERT members to reduce risk

[Basil Crow]

On Tue, Jul 18, 2023 at 10:56 AM 'wfoll...@cloudbees.com' via Jenkins
Developers  wrote:
>
> I prefer to have an incremental approach that provides value right now 
> instead of waiting on a larger effort that will provide value only later in 
> the future.

Why not proceed on both fronts concurrently?

> I would suggest you to start a new thread, as it's beyond the original scopes 
> of the existing ones.

The essence of my argument is that the scope of the current effort is
too limited. I suggest you expand the scope of the current effort as
described.

-- 
You received this message because you are 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/CAFwNDjqieTCixwJutUJ2-PYATVwKCxgjvbBW8rKfWif04Ow6QA%40mail.gmail.com.

Re: Removing inactive CERT members to reduce risk

[Basil Crow]

On Tue, Jul 18, 2023 at 1:05 AM 'wfoll...@cloudbees.com' via Jenkins
Developers  wrote:
> Your proposal about a more extreme approach was discussed and rejected.

But not with a valid justification.

> that discussion seemed to be sterile from my PoV

I fail to see how that discussion is sterile. Neither of the arguments
in my last post to that thread had been raised previously.

-- 
You received this message because you are 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/CAFwNDjoQwckBSX%3DuR%2B6KQihLw2erbznrbF5ccrvOiuVC8ZyEOw%40mail.gmail.com.

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

[Basil Crow]

On Mon, Jul 17, 2023 at 3:58 PM Basil Crow  wrote:
>
> AFAICT it is so that plugins whose required core is 1.577 or earlier
> will continue to work if installed on a clean installation. There are
> 343 such plugins. Once releases are created whose required core is
> 1.578 or later (or the plugin(s) formally deprecated in the Update
> Center) then we can stop bundling the JUnit plugin in the WAR.

I forgot to mention that not all of those 343 plugins are necessarily
actually consuming the JUnit plugin, just the older version of Jenkins
core. If it can be determined, e.g. through the usage-in-plugins tool,
that one of those old plugins is not consuming the JUnit plugin, then
that plugin can be crossed off the list.

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

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

[Basil Crow]

On Mon, Jul 17, 2023 at 1:05 PM Ullrich Hafner  wrote:
>
> Is there a reason that we are still bundling the JUnit plugin in our war? It 
> has been removed from core quite some years ago...

AFAICT it is so that plugins whose required core is 1.577 or earlier
will continue to work if installed on a clean installation. There are
343 such plugins. Once releases are created whose required core is
1.578 or later (or the plugin(s) formally deprecated in the Update
Center) then we can stop bundling the JUnit plugin in the WAR.

-- 
You received this message because you are 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/CAFwNDjpJKT58AqwWMaCNv%2BeBvVqrw%2Bhqta1A_OeYhDg9yt-Ykw%40mail.gmail.com.

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

[Basil Crow]

On Mon, Jun 12, 2023 at 10:39 AM Basil Crow  wrote:
>
> Then
https://github.com/jenkinsci/jenkins/blob/c886642632d81091c17d93f16b50c97ffb04d146/war/pom.xml#L406-L412
> needs to be adjusted.

JENKINS-71666 <https://issues.jenkins.io/browse/JENKINS-71666> FTR

-- 
You received this message because you are 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/CAFwNDjrev6_AbRXZpgf_%3Dx6iRU%2Bwo2eAicsWY-iiUTihBBGoww%40mail.gmail.com.

Re: Removing inactive CERT members to reduce risk

[Basil Crow]

On Fri, Jul 14, 2023 at 6:55 AM 'wfoll...@cloudbees.com' via Jenkins
Developers  wrote:
>
> This email is a continuation of 
> https://groups.google.com/g/jenkinsci-dev/c/8cy8w7ZqyB8/m/eZfaenQzEAAJ.

Is it a continuation if the last post to that thread remains unacknowledged?

-- 
You received this message because you are 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/CAFwNDjoyQ7RH8zhWTVdKkK1L_oW-bdiyK4b_eNvycTWAAh0NWg%40mail.gmail.com.

Re: Jenkins 2.413 as next LTS baseline?

[Basil Crow]

There do not appear to be any known user-visible regressions in production
code in 2.414, but jenkinsci/jenkins#7872
 implies a change in Login
Theme (3,757 installations) which has not yet been completed (tracked in
JENKINS-71238 ) and
jenkinsci/jenkins#7942 
implies a change in Calendar View (1,866 installations) which has not yet
been completed (tracked in JENKINS-71663
). If these tasks are not
completed by the time 2.414 LTS ships, they should be documented as known
defects in the release notes.

-- 
You received this message because you are 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/CAFwNDjrXi2EDDmc6qJht%3DeOmTgLsN8DYAKJOgz3nHbZWem-1JA%40mail.gmail.com.

Re: Jenkins 2.413 as next LTS baseline?

[Basil Crow]

2.414 does have some benefits, like a Prototype fix and an
optimization to the End of Life subsystem. The only risky portion is
the Safe Restart change, but as Mark mentioned, this could always be
patched or backed out if necessary. I audited the Safe Restart change,
and it seems safe (no pun intended) to me. So my vote is for 2.414.
But I don't feel strongly either way.

-- 
You received this message because you are 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/CAFwNDjprw-o3PbFsUroNNg_STNkVeehYqodwhDLLtvxyJ-XT8g%40mail.gmail.com.

Re: Drop 2.375.x support from plugin bom

[Basil Crow]

No strong feeling one way or another from me. When we began requiring
2.361.x or newer, there was a strong technical reason; namely, it was
prohibitively difficult to support Java 11 as a first-class citizen in
the toolchain alongside Java 8. There is no similar technical
justification in this case, since the relevant changes to bring the
2.375.x BOM line up to feature parity with the 2.387.x BOM line with
regard to the plugin parent POM and test harness (i.e., the HtmlUnit
migration) could be backported if desired. So the question comes down
to whether we feel the benefit justifies the cost. If I were doing
this work myself, I would try to retain support for 2.375.x since
there is some minor inconvenience in dropping support for 2.375.x and
since I think the cost of backporting is relatively low. But since I
believe the people doing the work should make the decisions, it is not
up to me.

-- 
You received this message because you are 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/CAFwNDjoCH9orjtO1NaA94gFzF5gz7AuEKa-Kn4RNP50yBqyJYw%40mail.gmail.com.

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

[Basil Crow]

On Wed, May 24, 2023 at 2:50 PM Ullrich Hafner  wrote:
>
> Popper is now part of the Bootstrap plugin. (So somehow in my own Jenkins UI 
> "core“ to create rich user interfaces without hassle.)

Then 
https://github.com/jenkinsci/jenkins/blob/c886642632d81091c17d93f16b50c97ffb04d146/war/pom.xml#L406-L412
needs to be adjusted.

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

Re: Backporting for LTS 2.401.2 has started

[Basil Crow]

That makes sense to me, and I think an exception is justified for
time-sensitive areas, such as EOL notifications. The feature has been
in weeklies without any reports of regression.

On Fri, Jun 9, 2023 at 8:34 AM Mark Waite  wrote:
> I would like to inform users earlier about end of life operating systems, if 
> that difference from the standard LTS backporting rules would be allowed.
>
> Specifically, we would backport:
>
> Warn when operating system end of life is approaching - 
> https://github.com/jenkinsci/jenkins/pull/7913 (Jenkins 2.407)
> Fix Fedora 38 date in operating system end of life warning - 
> https://github.com/jenkinsci/jenkins/pull/8082 (Jenkins 2.409)
>
> That would make the operating system end of life warning visible to LTS users 
> 8 weeks before it would naturally become visible.
>
> This is backporting a feature, so I am also just fine if this is rejected, 
> since it is not according to the standard backporting rules where we rarely 
> backport features to an LTS line.
>
> I would revise the blog post that announces the end of life operating system 
> warning to state that the warning is available to LTS users in 2.401.2
>
> 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/CAFwNDjoEguYDuOAuw2yxJ82HnT1WOvtvDaN8-0O5XdTvwyUKuw%40mail.gmail.com.