On 26.10.21 16:17, Geertjan Wielenga wrote:
I like this a lot!
I've been looking at GitHub Actions and setup/java a lot recently.
The issue with using just a plain latest release version, e.g., 8 or 11 is
that we won't know which exact version that is, i.e., that is always
whatever is the latest minor release of that major release. For debugging
purposes, e.g., when the build fails, it would be helpful to have a fixed
version as well as the latest version, e.g., 11.0.3 (which is a fixed
version) as well as 11 (which would be whatever the latest version is).
Zulu lends itself better to this, having many more versions than Temurin,
which is brand new. From the point of view of my employer, Azul, invested
in both Temurin and Zulu, both are great options -- though objectively Zulu
has more versions available to do this kind of regression testing against.
thanks for taking a look geertjan.
Yeah that is not a big problem I believe, since we can just add another
node testing baseline N.0.0 JDKs additional to latest as you said - now
that tests are decoupled from the build.
I actually had zulu nodes too, its just that i did not want to waste
resources while testing the pipeline, so i kept only a very basic node
setup.
I was wondering if it is "ok" resource wise having the base-build upload
a 1.56 GB workspace as an artifact with one day expiry. It certainly
would be convenient to have everything in it (extracting it does not
take long for the nodes either compared to everything else).
-michael
Gj
On Mon, Oct 25, 2021 at 7:22 AM Michael Bien <[email protected]> wrote:
Hello,
I tried to create a github actions config which is closer to a classic
CI pipeline.
base-build job (~22 mins):
- JDK 8 on linux
- full build of netbeans + commit-validation task but without zip
distribution
- archives the entire workspace and uploads it as artifact
secondary jobs:
- jdk 11/17 on various OSes etc
- only start if base-build succeeds
- extract the workspace
- run more tests with that workspace
- upload junit results (yey - main reason why i started this)
example run:
https://github.com/mbien/netbeans/actions/runs/1379449244
(note: you can download the entire workspace if you want which might be
useful for debugging purposes, currently retained for 1 day)
(note2: i disabled a lot of tests on the secondary jobs for now to not
waste resources)
(note3: someone has to fix the tests on JDK 17(!))
(note4: php tests don't generate test result xmls, thats why nothing is
uploaded)
My questions for those who are more familiar with the NB build:
Are there any tasks which can be run without having to build anything,
e.g license checks?
Is there anything else i should put on the secondary jobs beside
commit-validation (and the php cluster specific tests)? Reliable tests
which don't break like those on travis - which only leads to devs
completely ignoring them.
What do you think about this in general?
regards,
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
