Add GitHub Actions Workflows

[bdice]

Description

This PR adds GitHub Actions workflows to cuspatial.

Wait until after the 22.12 release is complete (and potentially until other repos are ready to migrate to GHA) to merge.

Task list

Coverage required for this PR:

• C++ tests
• Python tests
• Codecov
• Style checks

Possibly in scope for this PR:

• Java tests (not currently tested in gpuCI?)
• Notebooks (not currently tested in gpuCI?)

Future work:

• Build Metrics Report (copy from cudf when it is added)
• JUnit output annotations? https://github.com/marketplace/actions/junit-report-action
• Reduce exit code handling verbosity (use global variable with trap function)
• Set up rapids-dependency-file-generator pre-commit hook
• Docs builds

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (branch-23.02@6549248). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files

@@               Coverage Diff               @@
##             branch-23.02     #836   +/-   ##
===============================================
  Coverage                ?   92.55%           
===============================================
  Files                   ?       24           
  Lines                   ?     1007           
  Branches                ?        0           
===============================================
  Hits                    ?      932           
  Misses                  ?       75           
  Partials                ?        0           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[bdice]

I'd like a critical CMake eye here. I saw failures like the following:

CMake Error at tests/CMakeLists.txt:33 (target_link_libraries):
  Target "QUADTREE_LINESTRING_FILTERING_TEST" links to:

    GTest::gtest_main

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Call Stack (most recent call first):
  tests/CMakeLists.txt:101 (ConfigureTest)

I adapted this code to run get_gtest.cmake from libcudf, and added run dependencies for gmock and gtest to libcuspatial-tests.

[vyasr]

cudf exports the gtest targets in the case where cpm downloads gtest. My suspicion is that with GHA we're doing a better job of ensuring that gtest is already present in the conda environment than we were before (or in some other way we are ensuring that it's available), and as a result cudf isn't exporting the target and it's revealing the fact that cuspatial wasn't finding it on its own. Assuming that diagnosis is correct, though, I am not sure how best to handle this going forward. I have a feeling that we're going to need to revisit this anyway re: some of the ClobberWarnings that we discussed, it's not clear that we should be packaging up some pieces that we currently are.

@robertmaynard what do you think? Do we really want to be in a situation where cuspatial could also install a copy of gtest if it didn't find one? That's what copying in get_gtest.cmake will do AFAICT.

[bdice]

Aha. This sounds like it should be solved by adding gtest packages and avoiding the CPM fetch entirely. Maybe adding the logic for fetching gtest is fine, in case a user is missing those packages, but at CI build/test time I think we should be avoiding CPM fetches and use conda packages instead.

[robertmaynard]

No we should fix the underlying issue here instead of calling get_gtest.cmake. It would be good to back out the change and see what the full error message is, so we can find the root issue

[bdice]

In commit a629048, I fixed an issue with the specification of gtest in the conda recipe. The gtest/gmock conda packages are now available at build time and test run time, so CPM is not needed and this is no longer an issue for CI. As for source build correctness and whether CPM fetching should be possible outside the CI or conda context, I don’t have a concrete answer. I plan to revisit CPM/conda conflicts and ClobberWarnings from excessive CPM fetching in conda builds for all RAPIDS packages at some point in the future and may follow up with more questions. For now, we should not hold up the GitHub Actions migration on this packaging question.

[trxcllnt]

The C++ projects should configure correctly without conda. I'll clone this PR and see what's going on.

[trxcllnt]

This configures fine for me outside conda:

# Configure RMM
cmake -S /rmm -B /rmm/build -GNinja -DBUILD_TESTS=ON -DBUILD_BENCHMARKS=ON
​
# Configure cuDF
cmake -S /cudf/cpp -B /cudf/cpp/build -GNinja -DBUILD_TESTS=ON -DBUILD_BENCHMARKS=ON -Drmm_ROOT=/rmm/build
​
# Compile the jitify headers so `/cudf/cpp/build/include` dir exists for cuSpatial
# (this is a bug in cuDF's cmake, we shouldn't have to compile anything for the CMake package to be a valid target)
ninja -C /cudf/cpp/build jitify_preprocess_run
​
# Configure cuSpatail
cmake -S /cuspatial/cpp -B /cuspatial/cpp/build -GNinja -DBUILD_TESTS=ON -DBUILD_BENCHMARKS=ON -Drmm_ROOT=/rmm/build -Dcudf_ROOT=/cudf/cpp/build

[ajschmidt8]

Approving ops-codeowner file changes

[bdice]

I did a final pass of (self-)review and all looks good from my side.

[ajschmidt8]

@gpucibot merge