On 19/01/2021 11:48 pm, Magnus Ihse Bursie wrote:

On 2021-01-19 00:13, David Holmes wrote:
Hard-wiring build numbers seems a maintenance PITA. :( Is there not a way to do this that is independent of the actual build installed?
I agree that hard-wiring numbers in the code is bad. However, having explicit version numbers for our dependencies is good. That is the philosophy behind jib, and it has served us well. We should look at finding a way to store the actual versioon numbers outside the submit.yml file, though.

I think this is a bit different to the way we use jib to manage our own build environment.

But what do you mean by "independent of the actual build installed"?

We have AFAIK no control over what toolkit versions are installed for Github actions, so they could change at any time. We update today to request 14.28 and tomorrow they replace 14.28 with 14.29 and our builds fail again even though they would likely be perfectly fine on 14.29. To me if we just were able to say "Use latest VS 14.x" then that would suffice most of the time. Occasionally we could hit an issue where our sources are not yet compatible with the latest VS but hopefully that is less frequent than the frequency these VS builds change.

Would it not also be good to add a check for the existence of the build that we do hard-wire? That way the problem will be very clear next time.
It would be fantastic! Please tell me how to to that in the limited, brain-dead Github Actions environment. :-(

If we put those hard-wired version/build numbers into a file readable by configure, then couldn't configure check it?

Cheers,
David

/Magnus

Cheers,
David

-------------

Commit messages:
  - 8259679: GitHub actions should use MSVC 14.28

Changes: https://git.openjdk.java.net/jdk/pull/2126/files
  Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2126&range=00
   Issue: https://bugs.openjdk.java.net/browse/JDK-8259679
   Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
   Patch: https://git.openjdk.java.net/jdk/pull/2126.diff
   Fetch: git fetch https://git.openjdk.java.net/jdk pull/2126/head:pull/2126

PR: https://git.openjdk.java.net/jdk/pull/2126


Reply via email to