[actions] Add CI for jdk 8, 11, 17, and 18-ea

[hazendaz]

No description provided.

[hazendaz]

@mathieucarbou

• Please grant me to also bypass the review block as this otherwise blocks me from really doing much other than basic contributer with wait time :(

What I'm doing at the moment will include at least this below and probalby will happen pretty fast once I can move.

• Adding CI via github actions with far more jdk and os checks (this which you can see far out performed travis on 4 jdks and 3 OS - 12 builds)
• Dropping travis-ci entirely (will need you to drop that from PR checks as you can see here not needed).
• Boarding dependabot
• Will fix maven core scopes once dependabot finishes (new requirements from maven backported from 4.0).
• Some minor code cleanup
• Review some of the open PRs
• Add support for licensing spring.factories
• Probably other generized items once I get going.

[dbwiddis]

Recommend adding workflow_dispatch to allow manual triggering, and limiting pushes to master branch.

on: 
  workflow_dispatch:
  pull_request:
  push:
    branches:
      - master

[hazendaz]

If i get that one properly, it would not normally auto run on other branches (say on a fork with many as I just did to raise a bunch of PRs - but would on pull request for sure) unless going into the workflow_dispatch and triggering said branch. I had not seen that one but looked on oshi and sort of understand that and just wanted to clarify my assumptions. Assuming I have that correct, sounds like a good idea as most contributors will never have anything but master anyways ;)

[dbwiddis]

Yep.

As I wrote it above the branch restriction only applies to "push" to the repository, so doesn't stop any PR runs.

I think it's always a good idea to add workflow_dispatch.

The master branch restriction may not be relevant here, but there is a generate-site branch that can be pushed to, and there's no need to run actions when that happens. Adding workflow_dispatch allows you to manually choose to run it on any other branches if needed.

[mathieucarbou]

Recommend adding workflow_dispatch to allow manual triggering, and limiting pushes to master branch.

👍

[mathieucarbou]

The master branch restriction may not be relevant here, but there is a generate-site branch that can be pushed to

This branch cannot be used: this is a temporary branch that is automatically generated by a GA after a PR is merged in order to generate the snapshot doc.

Any change to the master branch will be detected by Gihub and it will re-generate the Jekyll website.

[dbwiddis]

This branch cannot be used: this is a temporary branch that is automatically generated by a GA after a PR is merged

I know this PR has been merged, but I did want to point out that any branch, temporary or otherwise, generated by anyone (human or automation) qualifies as a "push" to the repository and would trigger a build. It's not a big deal if it's only done rarely (and it's free anyway).

Speaking of free and to close the loop on billing, GHA is free with no quota for public repos like this one. I migrated my project over two years ago (well, @hazendaz did!) and have run 3400 workflows since then, most in the 5 minute range, some taking hours. I haven't paid a dime. GHA is owned by Microsoft and backed by the massive Azure cloud, so resource limits and backlogs aren't really a thing.

Travis claims to be free but allocates minutes to OSS projects that must be applied for, but more importantly they have a limited number of machines and I honestly don't know how long they'll be around. I still use Travis only for an ARM hardware build because GHA doesn't have those (yet... guess what one of the things I'm supporting at work is) and ARM provides those machines for free.

[mathieucarbou]

@dbwiddis : I've just merged this PR and did the updates in a subsequent commit after ;-) You can have a look at the code in master now. It's clean IMO. Let me know 👍

[mathieucarbou]

@hazendaz : the reason I didn't implement the CI as part of GA is because Travis allows to run MLP builds on a free plan. Last time I've checked, GitHub does not have any unlimited quota for OSS projects, and, besides, this is much more a quota per user or organization. And from the billing doc: Jobs that run on Windows and macOS runners that GitHub hosts consume minutes at 2 and 10 times the rate that jobs on Linux runners consume.

So until GitHub becomes more supportive of OSS projects running GA, I don't see how we could enable this atm...

=> On average: 4x 1min for linux, 4x 1min x 2 for Win, 4x 1min x10 for Mac == 52min => This is nearly 40% of a monthly quota of 2,000 min

And that is for each PR build (even when it is updated) and each master build...

[mathieucarbou]

@hazendaz : the reason I didn't implement the CI as part of GA is because Travis allows to run MLP builds on a free plan. Last time I've checked, GitHub does not have any unlimited quota for OSS projects, and, besides, this is much more a quota per user or organization. And from the billing doc: Jobs that run on Windows and macOS runners that GitHub hosts consume minutes at 2 and 10 times the rate that jobs on Linux runners consume.

So until GitHub becomes more supportive of OSS projects running GA, I don't see how we could enable this atm...

=> On average: 4x 1min for linux, 4x 1min x 2 for Win, 4x 1min x10 for Mac == 52min => This is nearly 40% of a monthly quota of 2,000 min

And that is for each PR build (even when it is updated) and each master build...

Oh !!!! I never saw that!

GitHub Actions usage is free for both public repositories

@hazendaz : can you please confirm that adding build though GA won't affect any quota and thus be limited ?

[hazendaz]

All looks good!