Repository navigation
v2-preview: check-latest wrongly defaults to "false" #148
Description
The default value of "false" for check-latest in the proposed v2-preview is a dramatic and unwelcome change in behavior, and one that will be hard to change if v2.0 ends up being released with this surprising default behavior in place.
The current default behavior (check-latest: false) silently overrides the expected meaning of the SemVer specified java-version [which is, properly, a required property]. In place of the specified SemVer version, it may silently deliver some non-matching and/or stale versions of the JDK, resulting in different-than-expected behaviors.
See #141 for some discussion about the addition of the check latest property and about its default value..
An option to not actually get the latest version that matches the provided SemVer version spec may make sense in some use cases. In those case, people who want this new an non-intuitive behavior (of semi-randomly picking a version based on what happen to be on the image used, and of not updating to the latest versions even when new versions become available) in order to gain some temporary speed benefits for some specific distro versions, can choose to turn the option on by saying "check-latest: false". But since doing that this is a clear counter-to-best-practice behavior from a configuration control point of view, it should be something you choose to do explicitly, and definitely not be the default behavior.
Let's be clear on somatic meaning here: "check-latest: false" is the semantic equivalent of the following statements:
"Actually include the security fixes expected in the specified version": false.
"Actually include the bug fixes expected in the specified version": false.
"Actually include the behavior enhancements expected in the specified version": false.
"Actually include the new bugs introduced in the specified version": false.
Non of those are a good "default" behavior in e.g. a CI/CD environment. Especially so in an ecosystem where distros update 4-6 times a year, with a well published list of 100s of changes and often 10s of security changes.
And yes, "test my repo against the latest released version of Java 11" is a common, best practice thing to do, with the expectation that tests started after the release and dissemination of a new version will run on that new version, and with the intent of finding out if that latest release breaks your stuff. As a practical example, OpenJDK 11.0.9 broke a bunch of stuff that was detected this way, with breakages widely detected in CI/CD systems the first couple of days after GA releases, leading to the subsequent urgent release of Op[enJDK 11.0.9.1.
Bottom line: if the check-latest properly is kept in v2.x, it should default to true.
Activity
konradpabjan commentedon Apr 2, 2021
This is by design and we'll not be changing this
Reiterating some of the main points I brought up in the PR
This is to optimize for the most common use cases of GitHub Actions
setup-javaand othersetup-*actions are used by millions of actions. Using a cached version when possible on the image makes the action near instant. The time saving compound pretty significantly and that means lots of 💲 savings because we're not wasting time downloading. Reducing the time of the most common workflows is incredibly important if we want to ensure we have the capacity to keep actions free like they currently are. A couple seconds isn't that much, but over millions of runs, it's pretty significantcheck-latestguarantees this. Calling this "unwelcome" from my perspective is unwarranted as it's quite the opposite and many users will surely appreciate faster more consistentsetup-javaexperiencescheck-latestdoes absolutely nothing and there will always be a download. Calling this "dramatic" thus is an extreme exaggeration that once again is unwarranted from my perspectiveREADMEwill be able to recognize what this does and make an informed decision.setup-nodefollow the same behavior so we're being consistent across the board: https://github.com/actions/setup-node/blob/5c355be17065acf11598c7a9bb47112fbcf2bbdc/action.yml#L12-L14We make it clear in the documentation, if you want the absolute latest versions (and with it security updates, enchantments etc that you mention), you can change the default value but it's at the expense of a slower workflow
Consider your last point
That's a very big con for the most common users of
setup-javaand precisely why having the latest and greatest immediately is not the best, the workflow breaks and their CI/CD systems fail causing lots of frustration that could have been avoided. Waiting a little bit before updating has its benefits and this is one of them. By using a slightly older cached version on our images, most workflows would be fine and there would be no disruption.