Coder Social home page Coder Social logo

jenkinsci / bom Goto Github PK

View Code? Open in Web Editor NEW
48.0 9.0 51.0 3.24 MB

Define plugin dependencies via BOM

Home Page: https://jenkins.io/doc/developer/plugin-development/dependency-management/#jenkins-plugin-bom

Shell 35.29% Groovy 22.23% Java 42.48%
jenkins developer-tools

bom's Issues

Retire 2.222.x BOM line

README.md states:

The UC currently maintains releases for the past 400 days so it is reasonable to retire BOMs for lines older than that.

2.222.4 was released on May 24, 2020, which was 430 days ago. Therefore it is reasonable to retire the 2.222.x BOM line.

Commit a687bdb was pointless

What feature do you want to see added?

a687bdb did not stop #1635 from being filed as intended. Moreover it was not necessary to begin with as demonstrated by #1642.

Upstream changes

No response

Build passes even after PCT fails to run on a plugin

https://github.com/jenkinsci/bom/pull/893/checks?check_run_id=5266351579 did not run any tests. https://ci.jenkins.io/job/Tools/job/bom/job/PR-893/1/execution/node/5973/log/ “passed” yet

…
 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-cli) on project script-security: Execution default-cli of goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed: java.lang.NoClassDefFoundError: com/google/common/io/NullOutputStream: com.google.common.io.NullOutputStream -> [Help 1]
 [ERROR] 
 [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
 [ERROR] 
 [ERROR] For more information about the errors and possible solutions, please read the following articles:
 [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
 succeeded artifactIds: [maven-hpi-plugin, maven-hpi-plugin]
 executed classname tests: []
 [INFO] -------------------------------------------------------
 [INFO] Solving test names
 [INFO] -------------------------------------------------------
 [WARNING] No test reports found!
 org.jenkins.tools.test.exception.PomExecutionException: [mvn, --show-version, --batch-mode, -ntp, --settings=/home/jenkins/workspace/Tools_bom_PR-893@tmp/settings-azure.xml, --define=failIfNoTests=false, --define=forkCount=.75C, --define=jth.jenkins-war.path=/home/jenkins/workspace/Tools_bom_PR-893/megawar.war, --define=surefire.excludesFile=/home/jenkins/workspace/Tools_bom_PR-893/excludes.txt, --define=surefire.rerunFailingTestsCount=4, --define=types=failsafe,surefire, --define=forkCount=.75C, hpi:resolve-test-dependencies, hpi:test-hpl, surefire:test, -Djenkins.version=2.335, -Denforcer.skip=true, failsafe:integration-test] failed in /home/jenkins/workspace/Tools_bom_PR-893/pct-work/script-security
 	at org.jenkins.tools.test.maven.ExternalMavenRunner.run(ExternalMavenRunner.java:105)
 	at org.jenkins.tools.test.PluginCompatTester.testPluginAgainst(PluginCompatTester.java:569)
 	at org.jenkins.tools.test.PluginCompatTester.testPlugins(PluginCompatTester.java:312)
 	at org.jenkins.tools.test.PluginCompatTesterCli.main(PluginCompatTesterCli.java:178)
 Plugin slack not in included plugins => test skipped !
…
 + grep -q -F -e '<status>INTERNAL_ERROR</status>' pct-report.xml
 + grep -q -F -e '<status>TEST_FAILURES</status>' pct-report.xml
 + rm -fv 'pct-work/*/target/surefire-reports/TEST-InjectedTest.xml' 'pct-work/*/*/target/surefire-reports/TEST-InjectedTest.xml'

Use JEP-229

It is annoying to have to do reincrementalify sample-plugin after every release, and easily forgotten (2b7c488 was delayed by a week). See also https://issues.jenkins.io/browse/JENKINS-58641. Better to use JEP-229 to release on workflow_dispatch (I do not think we want automatic releases from this component).

Switch sample plugin to an IT

It would be better to use the Invoker plugin to demonstrate that a plugin can properly consume the BOM than to use the current submodule hack.

Not obvious when `bom-weekly` is to be used

Describe your use-case which is not covered by existing documentation.

In jenkinsci/workflow-job-plugin#261, a question was raised regarding whether bom-weekly should be used when jenkins.version is a weekly version in a plugin's pom.xml. The answer is surprisingly subtle:

You should only use the weekly bom if you are tracking every weekly release as a plugin could be updated to a newer weekly version than you require currently.

This answer makes perfect sense in retrospect, but it was non-obvious to at least three people in two separate situations that I am aware of. As a result, I think this is a good candidate to add to the documentation in order to prevent additional people from being confused in the future.

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

jenkinsci/workflow-job-plugin#261

Version mismatch for `org.jenkins-ci.main:jenkins-test-harness` dependency in BOM versions above 1461.vb_3c6de28f2b_a_

Jenkins and plugins versions report

N/A

What Operating System are you using (both controller, and any agents involved in the problem)?

N/A (problem occurs when compiling a plugin with Maven)

Reproduction steps

BOM versions newer than 1461.vb_3c6de28f2b_a_ (such as 1500.ve4d05cd32975) seem to have a mismatch between the version of org.jenkins-ci.main:jenkins-test-harness that they specify, and the one that is transitively brought in through the io.jenkins.configuration-as-code:test-harness dependency. This makes mvn validate fail.

This can be seen in the PR jenkinsci/aws-secrets-manager-credentials-provider-plugin#223

To reproduce:

  1. Take a clean checkout of a plugin that uses BOM 1461.vb_3c6de28f2b_a_
  2. Ensure that it builds (or at least passes validation)
  3. Upgrade the BOM version to something newer (such as 1500.ve4d05cd32975)
  4. Run mvn validate again and see the error

Expected Results

The BOM upgrade should 'just work' without a dependency error.

Actual Results

The Maven Enforcer plugin fails with:

Failed while enforcing RequireUpperBoundDeps. The error(s) are [
Require upper bound dependencies error for org.jenkins-ci.main:jenkins-test-harness:1736.vc72c458c5103 [test] paths to dependency are:
+-io.jenkins.plugins:aws-secrets-manager-credentials-provider:1.999999-SNAPSHOT
  +-org.jenkins-ci.main:jenkins-test-harness:1736.vc72c458c5103 [test]
and
+-io.jenkins.plugins:aws-secrets-manager-credentials-provider:1.999999-SNAPSHOT
  +-io.jenkins.configuration-as-code:test-harness:1512.vb_79d418d5fc8 [test]
    +-org.jenkins-ci.main:jenkins-test-harness:1736.vc72c458c5103 [test] (managed) <-- org.jenkins-ci.main:jenkins-test-harness:1802.v9de0d87365d2 [test]
]

Anything else?

I also tried bumping the plugin's major/minor version of Jenkins as far as 3.3.19.x (and likewise the BOM), but this did not make a difference.

Consider running PCT matrix for all lines on GitHub Action?

I been toying with the idea to generate github actions manifest to run PCT testing for each plugin. Potentially run the matrix for each line.
One the goal would be reduce the load on ci.jenkins.io and two Jenkins pipeline could default in the future to mvn verify if the PCT matrix would run faster and on all lines here on GitHub WDYT?
Another benefit would be would could take advantage of caching of maven dependencies and potential caching of WAR if we can find a good way to only update a single/few plugin.

So I had something like this in mind.

graph TD
    A[GitHub Actions] 
    A --> B(MVN Verify)
    B --> C[Prepare WAR 2.319.x]
    B --> D[Prepare WAR 2.332.x]
    B --> E[Prepare WAR 2.346.x]
    B --> F[Prepare WAR Weekly]
    C --> G[Plugin 1]
    C --> H[Plugin 2]
    C --> I[Plugin 3]
    D --> G1[Plugin 1]
    D --> H1[Plugin 2]
    D --> I1[Plugin 3]
    E --> G2[Plugin 1]
    E --> H2[Plugin 2]
    E --> I2[Plugin 3]
    F --> G3[Plugin 1]
    F --> H3[Plugin 2]
    F --> I3[Plugin 3]
Loading

cc @jglick @timja @basil

Keep pinned dependencies in `2.nnn.x/pom.xml` up to date

Currently only bom-weekly is managed by Dependabot. For example, #1006 updated the version of credentials in bom-weekly to one which includes a recent security fix (among other changes); but bom-2.303.x and bom-2.332.x both continue to specify an older version, despite the availability of versions 2.6.1.1 and 1087.1089.v2f1b_9a_b_040e4, respectively. (Not sure offhand what line 1074.1076.v39c30cecb_0e2 exists for.)

We deliberately decline to mention these POMs in .github/dependabot.yml because then we would constantly be rejecting suggestions to update pinned versions to plugin releases which in fact require a new core (see #266), so to do this automatically we would need to use updatecli or something else customizable (e.g., checking the public update center for updates for a given LTS line).

Pipeline: Declarative tests are too unstable

In this repository, we set surefire.rerunFailingTestsCount=4 to run failing tests up to 4 times, and we also have a retry(2) block in the Jenkinsfile. A test that manages to fail despite all of this is too flaky to be included in the suite. We recently excluded org.jenkinsci.plugins.pipeline.modeldefinition.BasicModelDefTest and org.jenkinsci.plugins.pipeline.modeldefinition.MatrixTest from the suite because they were causing too many problems for unrelated PRs. We should try re-enabling those tests in a new PR and investigate how to get them to pass reliably again.

`JobPropertyStepTest` had been ignored for one reason but is now failing for another reason

Jenkins and plugins versions report

Pipeline: Multibranch 696.v52535c46f4c9

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 20.04.3 LTS x86_64

Reproduction steps

  • Remove any exclusions for JobPropertyStepTest, if any remain in the source tree.
  • Run: PLUGINS=workflow-multibranch TEST=org.jenkinsci.plugins.workflow.multibranch.JobPropertyStepTest#configRoundTripParameters bash local-test.sh

Expected Results

The test passes.

Actual Results

This regression went noticed because these test results were being ignored for a different reason (jenkinsci/workflow-multibranch-plugin#128). That PR was merged, but the test results were never un-ignored, so this new regression slipped by unnoticed.

This test now fails with:

java.lang.AssertionError: expected:<1> but was:<3>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:647)
	at org.junit.Assert.assertEquals(Assert.java:633)
	at org.jenkinsci.plugins.workflow.multibranch.JobPropertyStepTest.configRoundTripParameters(JobPropertyStepTest.java:116)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:601)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.lang.Thread.run(Thread.java:829)

Anything else?

No response

Weekly updates stopped working

Jenkins and plugins versions report

Environment
Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 20.04.4 LTS x86_64
Jenkins 2.344

Reproduction steps

Release a weekly, then wait a few days for Updatecli to propose an update.

Expected Results

A PR is proposed for the update, such as #1023.

Actual Results

#1023 was the last such PR that was proposed (for 2.344). For the past month, no additional PRs have been proposed for 2.345, 2.346, or 2.347.

Anything else?

This is correlated with (but not necessarily caused by) the introduction of #1063 CC @jetersen

Parent pom update fails from 4.51 to later releases

Jenkins and plugins versions report

As documented in #1635

What Operating System are you using (both controller, and any agents involved in the problem)?

Linux on the controller

Reproduction steps

  1. Attempt to build #1635
  2. Confirm that the build fails

Expected Results

Passing build so that the sample-plugin can be upgraded to parent pom 4.53

Actual Results

CI job fails

Anything else?

I'm not able to resolve the issue. I placed a build / pluginManagement section in the bom-2.346.x/pom.xml file with the maven hpi plugin version set to 3.37 but that did not change the behavior.

2.289.x

Need to get started on the new LTS line.

Do not forgot to add to RPU first.

test failures are ignored (if all tests failed?)

Jenkins and plugins versions report

The OSS BOM is broken when running the PCT for various scenarious.

e.g. https://ci.jenkins.io/job/Tools/job/bom/job/PR-893/1/testReport/ has not tests for script-security using the weekly the failure is that the guava method is DOA (so there is a linkage error in running the test so it is not failed)
pct-script-security-weekly -> https://ci.jenkins.io/job/Tools/job/bom/job/PR-893/1/pipeline-console/

[2022-02-20T19:30:30.052Z] [INFO] --- maven-surefire-plugin:3.0.0-M4:test (default-cli) @ script-security ---
[2022-02-20T19:30:33.047Z] [INFO] 
[2022-02-20T19:30:33.047Z] [INFO] -------------------------------------------------------
[2022-02-20T19:30:33.047Z] [INFO]  T E S T S
[2022-02-20T19:30:33.047Z] [INFO] -------------------------------------------------------
[2022-02-20T19:30:33.047Z] [INFO] 
[2022-02-20T19:30:33.047Z] [INFO] Results:
[2022-02-20T19:30:33.047Z] [INFO] 
[2022-02-20T19:30:33.047Z] [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[2022-02-20T19:30:33.047Z] [INFO] 
[2022-02-20T19:30:33.047Z] [INFO] ------------------------------------------------------------------------
[2022-02-20T19:30:33.047Z] [INFO] BUILD FAILURE
[2022-02-20T19:30:33.047Z] [INFO] ------------------------------------------------------------------------
[2022-02-20T19:30:33.047Z] [INFO] Total time:  14.613 s
[2022-02-20T19:30:33.047Z] [INFO] Finished at: 2022-02-20T19:30:32Z
[2022-02-20T19:30:33.047Z] [INFO] ------------------------------------------------------------------------

the stage in BO is marked as failing, but overall the build is marked as passing - causing changes to be merged when the plugins tests are DOA.

Also occurs with bitbucket-branch-source probably various others.

What Operating System are you using (both controller, and any agents involved in the problem)?

ci.jenkins.io

Reproduction steps

https://ci.jenkins.io/job/Tools/job/bom/job/PR-893/1/pipeline-console/

Expected Results

The CI status of the PCT tests is accurate and if a plugins test blow up so spectacurlay that they are not run that the PCT fails the tests and the build is marked unstable.

Actual Results

the build is marked stable, resulting in incorrect merges of plugins.

Anything else?

N/A

`WorkflowRunRestartTest` had been ignored for one reason but is now failing for another reason

Reproduction steps

  • Remove any exclusions for WorkflowRunRestartTest, if any remain in the source tree.
  • Run: PLUGINS=workflow-job TEST=org.jenkinsci.plugins.workflow.job.WorkflowRunRestartTest#interruptedWhileStartingPerformanceOptimized,org.jenkinsci.plugins.workflow.job.WorkflowRunRestartTest#interruptedWhileStartingMaxSurvivability bash local-test.sh

Results

This regression went noticed because these test results were being ignored for a different reason (jenkinsci/workflow-job-plugin#158). That PR was closed because the underlying problem was fixed, but the test results were never un-ignored, so this new regression slipped by unnoticed.

These two tests now fail with:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script1.groovy: -1: unable to resolve class org.jenkinsci.plugins.workflow.libs.Library
 @ line -1, column -1.
1 error

        at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
        at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:958)
        at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:605)
        at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:554)
        at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
        at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
        at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
        at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
        at groovy.lang.GroovyShell.evaluate(GroovyShell.java:584)
        at groovy.lang.GroovyShell.evaluate(GroovyShell.java:623)
        at groovy.lang.GroovyShell.evaluate(GroovyShell.java:594)
        at groovy.lang.GroovyShell$evaluate.call(Unknown Source)

`jenkins.plugins.http_request.HttpRequestStepRoundTripTest#configRoundTripGroup1` tends to time out

Jenkins and plugins versions report

Environment
Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 22.04 LTS x86_64

Reproduction steps

Remove the exclusion for jenkins.plugins.http_request.HttpRequestStepRoundTripTest in excludes.txt added in #1355, then run the test suite a few times.

Expected Results

The tests should reliably pass.

Actual Results

jenkins.plugins.http_request.HttpRequestStepRoundTripTest#configRoundTripGroup1 tends to time out with the thread dump showing many threads doing work in HtmlUnit.

Anything else?

Should debug this further to find the root cause and then re-enable the test.

Use `surefire.excludesFile`

Currently the BOM PCT runs every test and then deletes test results from known failures, which is wasteful. Better to switch to -Dsurefire.excludesFile with entries like InjectedTest.class or pkg/SomeTest.class.

`org.jenkinsci.plugins.pipeline.modeldefinition.TriggersTest` tends to run out of memory

Jenkins and plugins versions report

Environment
Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 22.04 LTS x86_64

Reproduction steps

Remove the exclusion for org.jenkinsci.plugins.pipeline.modeldefinition.TriggersTest in excludes.txt added in #1359, then run the test suite a few times.

Expected Results

The tests should reliably pass.

Actual Results

org.jenkinsci.plugins.pipeline.modeldefinition.TriggersTest tends to run out of memory and crash with exit code 137.

Anything else?

No response

2.380 update failed

Jenkins and plugins versions report

Jenkins 2.380

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 22.04.1 LTS x86_64

Reproduction steps

With the update to 2.380 as in #1611 run PLUGINS=matrix-auth TEST=org.jenkinsci.plugins.matrixauth.ReadOnlyTest bash local-test.sh.

Expected Results

The test passes in less than 30 seconds.

Actual Results

The test passes in more than 30 seconds, or times out on CI builds that have a 180-second timeout.

Anything else?

Analysis in #1611 (comment).

2.289.x and 2.303.x BOMs include Git Server 1.9 which relies on the detached SSHD Module in the Jenkins Core

Jenkins Core to 2.303.1 LTS excluded the SSHD Module and converted it to a plugin. It impacted the Git Server plugin that it is transiently loaded by the Pipeline: Global Libraries plugin. jenkinsci/git-server-plugin#24 fixes it in 1.10, but apparently 1.9 is bundled in Jenkinsfile Runner Vanilla Package

FTR https://www.jenkins.io/doc/upgrade-guide/2.289/#sshd-module-unbundling

Causes jenkinsci/jenkinsfile-runner#560

`org.jenkinsci.plugins.durabletask.BourneShellScriptTest` is too unstable

In this repository, we set surefire.rerunFailingTestsCount=4 to run failing tests up to 4 times, and we also have a retry(2) block in the Jenkinsfile. A test that manages to fail despite all of this is too flaky to be included in the suite. We recently excluded org.jenkinsci.plugins.durabletask.BourneShellScriptTest from the suite because it was causing too many problems for unrelated PRs. We should try re-enabling that test in a new PR and investigate how to get it to pass reliably again.

Plugin PCT runs should use current BOM version, not the BOM version defined by the plugin

Jenkins and plugins versions report

Environment
Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 20.04.3 LTS x86_64

Reproduction steps

Run e.g. PLUGINS=mailer bash local-test.sh.

Expected Results

The PCT run should use the versions of all plugins defined in this repository.

Actual Results

Mailer defines its BOM version as 1075.v14bef33e5d7b, and the PCT run will use that BOM version when building up the test classpath, though the Jenkins WAR will be the "megawar" with the plugin versions defined in this repository.

Anything else?

No response

Purpose of this repository is unclear

Describe your use-case which is not covered by existing documentation.

From the readme:

This repository implements a Maven BOM which can be used in a plugin POM to more easily manage dependencies on other common plugins.

Looking through the bom-weekly, I see plugins like custom-folder-icon (0.2% installs, no dependent plugins), dark-theme (~2% installs, no dependents), file-parameters (<1% installs, no dependents).

I do not understand how this aligns with the stated purpose of this repository. Why are plugin included that are neither popular, nor used as dependencies from other plugins?

While the documentation explains how to add new plugins, it does not explain which plugins are an appropriate choice to include, or what criteria they should fulfill (if any).

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

No response

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.