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.

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

Setup GitHub Actions CI and SNAPSHOT uploading #440

Merged
merged 14 commits into from
Jan 5, 2021

Conversation

lazaroclapp
Copy link
Collaborator

This change sets up GitHub Actions as a parallel build CI to Travis (for now). GitHub Actions should build NullAway on MacOS X and Linux using JDK 8, and on Linux using JDK 11, mirroring our existing Travis config.

Additionally, this migrates snapshot uploading and coverage tracking to GitHub Actions, disabling the equivalent Travis CI events as they will likely conflict. This might break snapshot uploading after landing, since it's not possible to easily test that from the PR. If it does, follow up PRs might be needed.

See #408

@lazaroclapp
Copy link
Collaborator Author

Do not merge yet. WIP. Testing.

@lazaroclapp
Copy link
Collaborator Author

@msridhar No idea if Snapshot publishing works yet, but GitHub action CI builds themselves look sane :)

Copy link
Collaborator

@msridhar msridhar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks great! Just a couple non-blocking comments

run: ./gradlew :nullaway:test
if: matrix.java == '11'
- name: Report jacoco coverage
run: ./gradlew jacocoTestReport coveralls
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the logs I see for coveralls:

> Task :nullaway:coveralls
no available CI service

Is that ok for now?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, let me look into that a bit. Might be ok, but we are not in a rush.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the author of kt3k/coveralls-gradle-plugin is looking for a new maintainer (see kt3k/coveralls-gradle-plugin#107) and nbaztec/coveralls-jacoco-gradle-plugin supports GitHub Actions out-of-the-box, it might be worth migrating to the latter.

https://github.com/nbaztec/coveralls-jacoco-gradle-plugin#github-actions

publish_snapshot:
name: 'Publish snapshot'
needs: [build]
if: github.event_name == 'push' && github.repository == 'uber/NullAway' && github.ref == 'refs/heads/master'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could test the snapshot upload out by changing the branch here temporarily, and then changing it back. I'm also ok with just testing on master.

java-version: 8
- name: 'Publish'
env:
SONATYPE_NEXUS_USERNAME: ${{ secrets.SONATYPE_NEXUS_USERNAME }}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For WALA I had to do this to get env vars to show up as Gradle properties in the build:

          ORG_GRADLE_PROJECT_SONATYPE_NEXUS_USERNAME: ${{ secrets.SONATYPE_NEXUS_USERNAME }}
          ORG_GRADLE_PROJECT_SONATYPE_NEXUS_PASSWORD: ${{ secrets.SONATYPE_NEXUS_PASSWORD }}

But the WALA Gradle scripts are different from NullAway's so maybe this is correct here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our scripts look for SONATYPE_NEXUS_USERNAME, etc, in env vars. So I suspect this will work, but let me test it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, you were right, ORG_GRADLE_PROJECT_SONATYPE_NEXUS_USERNAME works for some reason and SONATYPE_NEXUS_USERNAME doesn't. I could check out why, but since it seems to be working now, I'll just update the branch and land.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's because the Gradle scripts are looking for a project property SONATYPE_NEXUS_USERNAME, etc., and you need the ORG_GRADLE_PROJECT_ prefix to have Gradle read the environment variable as a project property: https://docs.gradle.org/current/userguide/build_environment.html#sec:project_properties

@msridhar
Copy link
Collaborator

msridhar commented Jan 4, 2021

BTW, I was a little surprised this "just worked" without doing anything explicit to set up the Android SDK in the builds. Looks like Android comes pre-installed on the GH Actions runners; nice!

@lazaroclapp
Copy link
Collaborator Author

BTW, I was a little surprised this "just worked" without doing anything explicit to set up the Android SDK in the builds. Looks like Android comes pre-installed on the GH Actions runners; nice!

Yup. I had to read into that. Was similarly confused for a while, could have probably saved you the time in searching, though 😅

@msridhar
Copy link
Collaborator

msridhar commented Jan 4, 2021

BTW does each PR creation really imply a push? What if it's a PR from someone without push access to this repo?

@lazaroclapp
Copy link
Collaborator Author

lazaroclapp commented Jan 4, 2021

BTW does each PR creation really imply a push? What if it's a PR from someone without push access to this repo?

Not sure. I guess the only way to test it is to try to create a PR from a fork or some other repo. The problem with pull_request (as configured in WALA) is that it will only trigger at PR creation and it will then duplicate what we see from just push (so you get twice as many jobs in the PR). There is a way to also trigger when the PR changes, but again that will cause these jobs to show twice... I'd want to test if nothing shows right now for a PR from a different repo before enabling that much redundancy.

Might experiment with that tomorrow (also, there seems to be still a step missing in uploading coverage results :) )

Comment on lines +56 to +67
- name: Cache Gradle caches
uses: actions/cache@v1
with:
path: ~/.gradle/caches
key: ${{ runner.os }}-gradle-caches-${{ hashFiles('**/*.gradle') }}
restore-keys: ${{ runner.os }}-gradle-caches-
- name: Cache Gradle wrapper
uses: actions/cache@v1
with:
path: ~/.gradle/wrapper
key: ${{ runner.os }}-gradlew-wrapper-${{ hashFiles('gradle/wrapper/gradle-wrapper.properties') }}
restore-keys: ${{ runner.os }}-gradlew-wrapper-
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using eskatos/gradle-command-action might reduce the boilerplate necessary to set up proper caching for Gradle builds.

https://github.com/eskatos is working for Gradle, so it's not some random 3rd party GitHub action.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me. Thanks! :)

@@ -15,9 +15,6 @@
*/
plugins {
id "java"
// For code coverage:
id 'jacoco'
id 'com.github.kt3k.coveralls'
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coverage plugin has multi-project support. But:
a) It's a bit convoluted
b) We have never had proper coverage support for JarInfer before (this bit above is long broken)
c) We mostly care about coverage for core NullAway

That said, it's worth having JarInfer coverage in the future as well, just not high priority.

@lazaroclapp
Copy link
Collaborator Author

Coveralls plug-in was sometimes failing with a timeout. Not sure if this will keep happening after merging or if the last change I made truly fixed it (ran it twice, successfully), but I'd say let's keep an eye on it and fix as needed.

Also, not sure if the GitHub Actions CI will trigger for third-party PRs. Since we are running both GitHub Actions and Travis CI for the time being, I suggest we just keep an eye out for anything that seems to be skipping GitHub Actions.

Will merge unless there are concerns from @msridhar

@msridhar
Copy link
Collaborator

msridhar commented Jan 5, 2021

LGTM; I'm fine with landing. My feeling is that CI won't run for 3rd-party PRs right now, but we can easily test that once this lands

@lazaroclapp lazaroclapp merged commit eed3fc0 into master Jan 5, 2021
@lazaroclapp lazaroclapp deleted the lazaro_ci_to_github_actions branch January 5, 2021 19:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants