GHA: split into more workflows #325
Conversation
I'm fine with that, let's see how that works. The ability to share an artifact that has been built once might enable a different workflow architecture, but first let's see how this split works. |
vhotspur
changed the title
There was a problem hiding this comment.
LGTM. I would like to see this merged now.
As to where to go next, we have discussed this a bit during the telco. We should primarily test LTS versions, because those are what people care about (the moment an LTS version is released, the intermediate versions between two LTS version become relatively less important). Also, we would probably not add workarounds for compatibility issues in those versions to Renaissance if a later LTS version worked fine.
Instead of intermediate non-LTS versions, we should make sure to test with latest non-LTS version discover compatibility issues early. There are (not only) early-access Docker images with various JVM versions that we might use in the CI.
|
FYI, the icon showing the status of the latest build on https://renaissance.dev/ seems to be broken since this PR got merged. |
Fixed in renaissance-benchmarks/renaissance-benchmarks.github.io@e65c60f |
An attempt for something that we discussed with @lbulej off-line.
Currently, CI using GitHub actions builds everything in one workflow. Unfortunately, unlike GitLab or Travis, one cannot restart individual jobs inside a workflow but only the whole workflow. That means that a single failing job (e.g. because SBT cannot fetch dependencies because of temporary network outage or similar) fails the whole workflow and restarting it is a very costly operation.
Therefore, this PR splits the workflow into the following parts:
Mainfor building on latest JDK on Linux, Windows and MacOS. This also checks for encoding and coding style issues. This is meant as always-must-be-in-the-green workflow.Pluginsfor building and testing plugins (JDK 8 only)Windows (legacy)is a matrix build for all out-of-the-box supported JDKs on Windows excluding JDK 17.MacOS (legacy)is just like the above but on Mac.Linuxis a matrix build for JDKs 8 to 16, including also OpenJ9 (8, 11, 16).This should simplify restarting the jobs and might also simplify identifying the failing job a bit more quickly.
@lbulej Does this initial split somehow seem reasonable to you? I have not yet tackled the idea of sharing builds between individual jobs but it at least solves the issue of restarting smaller units of jobs.