Bump jenkins from 1.76 to 1.77 #444
Conversation
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
dependabot
bot
added
dependencies
|
|
@dependabot rebase |
Bumps [jenkins](https://github.com/jenkinsci/pom) from 1.76 to 1.77. - [Release notes](https://github.com/jenkinsci/pom/releases) - [Changelog](https://github.com/jenkinsci/pom/blob/master/CHANGELOG-old.md) - [Commits](jenkinsci/pom@jenkins-1.76...jenkins-1.77) --- updated-dependencies: - dependency-name: org.jenkins-ci:jenkins dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
force-pushed
the
dependabot/maven/org.jenkins-ci-jenkins-1.77
branch
from
00b4ff3
to
f7c3e10
Compare
|
From JENKINS-68570:
|
| check naturally fails. To work around this, we relax the bytecode version check | ||
| when we are executing the Java 17 branch in the CI environment. | ||
|
|
||
| TODO When the minimum Jenkins baseline is bumped past 2.357, this can be deleted. | ||
| --> | ||
| <profile> | ||
| <id>test-recent-cores-on-ci</id> | ||
| <activation> | ||
| <jdk>17</jdk> | ||
| <property> | ||
| <name>env.CI</name> | ||
| </property> |
There was a problem hiding this comment.
Or just
| check naturally fails. To work around this, we relax the bytecode version check | |
| when we are executing the Java 17 branch in the CI environment. | |
| TODO When the minimum Jenkins baseline is bumped past 2.357, this can be deleted. | |
| --> | |
| <profile> | |
| <id>test-recent-cores-on-ci</id> | |
| <activation> | |
| <jdk>17</jdk> | |
| <property> | |
| <name>env.CI</name> | |
| </property> | |
| check naturally fails. To work around this, we relax the bytecode version check | |
| when we are executing the Java 17 branch. | |
| TODO When the minimum Jenkins baseline is bumped past 2.357, this can be deleted. | |
| --> | |
| <profile> | |
| <id>test-recent-cores-on-ci</id> | |
| <activation> | |
| <jdk>17</jdk> |
to simplify?
There was a problem hiding this comment.
But then someone who happens to be running locally with Java 17 but has not customized the Jenkins version would get the looser Enforcer semantics of 11 and may accidentally depend on a Java 11 API. The CI build would catch this before it is merged and released, but I think local and CI builds should be as close as possible. I like restricting this to CI builds since that is the only place where we are programmatically using a recent weekly version.
There was a problem hiding this comment.
local and CI builds should be as close as possible
Well of course that was my point as well, from another perspective. 馃榿 Anyway, this is fine.
There was a problem hiding this comment.
Right, someone who is running locally with jenkins.version would need to set CI=true to get this logic. I dunno if there is a good solution here. Really what I need is a way to activate the profile if the version number is greater than or equal to some value, but I can't think of a way to do that with Maven profile activation.
There was a problem hiding this comment.
activate the profile if the version number is greater than or equal to some value
Yeah that is moving into Gradle territory I think.
Bumps jenkins from 1.76 to 1.77.
Release notes
Sourced from jenkins's releases.
Commits
f7b9fd2[maven-release-plugin] prepare release jenkins-1.77b4939c5Require Java 11 (#209)52864e9Bump maven-enforcer-plugin from 3.0.0 to 3.1.0 (#267)1b7133bBump maven-hpi-plugin from 3.27 to 3.28 (#266)980357f[maven-release-plugin] prepare for next development iterationDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)