Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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

Merged
merged 1 commit into from
Jan 16, 2022
Merged

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions .github/workflows/ci.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
name: Java CI

on: [push, pull_request]
Copy link
Contributor

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

Copy link
Collaborator Author

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 ;)

Copy link
Contributor

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.

Copy link
Owner

@mathieucarbou mathieucarbou Jan 16, 2022 •
edited
Loading

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.

👍

Copy link
Owner

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.

Copy link
Contributor

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.

Copy link
Owner

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 👍


jobs:
test:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, macOS-latest, windows-latest]
java: [8, 11, 17, 18-ea]
distribution: ['zulu']
fail-fast: false
max-parallel: 4
name: Test JDK ${{ matrix.java }}, ${{ matrix.os }}

steps:
- uses: actions/checkout@v2
- name: Set up JDK
uses: actions/setup-java@v2
with:
java-version: ${{ matrix.java }}
distribution: ${{ matrix.distribution }}
- name: Test with Maven
run: ./mvnw test -B -D"license.skip=true"