-
-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[actions] Add CI for jdk 8, 11, 17, and 18-ea #254
Conversation
What I'm doing at the moment will include at least this below and probalby will happen pretty fast once I can move.
|
@@ -0,0 +1,25 @@ | |||
name: Java CI | |||
|
|||
on: [push, pull_request] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recommend adding workflow_dispatch
to allow manual triggering, and limiting pushes to master
branch.
on:
workflow_dispatch:
pull_request:
push:
branches:
- master
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recommend adding
workflow_dispatch
to allow manual triggering, and limiting pushes tomaster
branch.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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!
@hazendaz : can you please confirm that adding build though GA won't affect any quota and thus be limited ? |
All looks good! |
No description provided.