-
Notifications
You must be signed in to change notification settings - Fork 224
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
Github Actions CI for testing GMT master branch #485
Conversation
Signed-off-by: Wei Ji <weiji.leong@vuw.ac.nz>
Signed-off-by: Wei Ji <weiji.leong@vuw.ac.nz>
Signed-off-by: Wei Ji <weiji.leong@vuw.ac.nz>
Signed-off-by: Wei Ji <weiji.leong@vuw.ac.nz>
See https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast Signed-off-by: Wei Ji <weiji.leong@vuw.ac.nz>
Signed-off-by: Wei Ji <weiji.leong@vuw.ac.nz>
Try just caching ~/.gmt/cache and ~/.gmt/server.
Co-authored-by: Dongdong Tian <seisman.info@gmail.com>
I'm thinking if it's easier and more cross-platform if we build the gmt master branch via conda-build and then install it, i.e.,
|
That's a smart idea. But we might as well make gmt-nightly builds a thing and pull that (and users who want the latest bugfix can benefit). The Rapids AI organization has a good documented example, see e.g. cudf https://anaconda.org/rapidsai-nightly/cudf/files and blog post at https://medium.com/rapids-ai/in-the-heat-of-the-nightlies-6ed3be57ac64. I seem to recall they designed the build so it only happens if there's been commits, so no compute time is wasted. I'll open an issue for that later. |
Do you mean a separate gmt-nightly feedstock? We actually have a devel branch in the gmt-feedstock, but I'm not sure if it's a good idea to have a nightly release, since the packages (Linux, macOS and Windows) would be almost 200 MB for each release. Found this one conda-forge/cfep#3, but haven't read it yet. |
I've started a new thread at conda-forge/gmt-feedstock#95. We can continue that part of the discussion there. |
58cd99b
to
3f136bb
Compare
12f5b90
to
575baa7
Compare
I think we should move the "testing GMT master branch" into a separate file. Sometimes it's impossible to make all the tests for the current release and master branch. Then we will always see a failing badge in the README file. |
Also run the tests only on PRs that are ready for review or have a review requested (i.e. non-draft PRs). Based on https://github.saobby.my.eu.orgmunity/t/dont-run-actions-on-draft-pull-requests/16817/6.
eff332b
to
19c38d0
Compare
:alt: GitHub Actions Tests status | ||
:target: https://github.com/GenericMappingTools/pygmt/actions?query=workflow%3ATests | ||
.. image:: https://github.com/GenericMappingTools/pygmt/workflows/GMT%20Master%20Tests/badge.svg | ||
:alt: GitHub Actions GMT Master Tests status | ||
:target: https://github.com/GenericMappingTools/pygmt/actions?query=workflow%3A"GMT+Master+Tests" |
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.
I think we should move the "testing GMT master branch" into a separate file. Sometimes it's impossible to make all the tests for the current release and master branch. Then we will always see a failing badge in the README file.
Ok, I've moved it into a separate file and added a separate badge. It would be nice if we could have separate badges for different jobs in a workflow but it doesn't look to be possible yet according to https://github.saobby.my.eu.orgmunity/t/separate-workflow-badges-when-using-matrix-testing-possible/16708.
pull_request: | ||
types: [review_requested, ready_for_review] |
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.
Found this nice way to limit the GMT Master Tests to non-draft PRs (see https://github.saobby.my.eu.orgmunity/t/dont-run-actions-on-draft-pull-requests/16817/6 and also https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull_request). I think this strikes a nice balance between testing GMT master "on every PR commit" and testing "only on the PyGMT master branch". Let me know if this is okay.
As an aside, we could apply this to other expensive tests too (e.g. *coughs* Windows).
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.
Looks a good idea. Do we still want to test GMT master when a PR is merged into master 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.
Do we still want to test GMT master when a PR is merged into master branch?
Up to you. I'd prefer to save on CI resources, and there's a daily cron job anyway.
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.
OK. Daily cron job is enough.
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.
I just made a new commit b911366 to this branch. The GMT master workflow is not triggered. I need to click the "Re-request review" icon to trigger the GMT master test.
I think It's good. The GMT master workflow only runs when:
- A draft PR is ready for review
- A review is request or re-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.
Yes, it's a nice feature. We don't need to test this too often anyway so I'm happy with it 😄 Should I document this in MAINTENANCE.md?
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.
Yes, please.
fail-fast: false | ||
matrix: | ||
python-version: [3.8] | ||
os: [ubuntu-20.04, macOS-10.15] |
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.
Would love to test on Windows here, but I think we might have to do conda-forge/gmt-feedstock#95 first 😉
1. `ci_tests.yaml` (Style Checks, Tests on Linux/macOS/Windows) | ||
|
||
This is ran on every commit on the *master* and Pull Request branches. | ||
It is also scheduled to run daily on the *master* 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.
Ok, I've reorganized the Continuous Integration section a bit since it was getting complicated. You can insert a comment here about 'skipping ci-tests' later in #534.
Description of proposed changes
Running Continuous Integration tests on the gmt-master branch. Based on code I had lying around on my computer from May 2020 (tested locally on https://github.com/nektos/act/), but updated with stuff from #475 et al.
This is similar to #462, but on Github Actions (instead of Azure Pipelines), and currently only on Ubuntu and macOS only (may try on Windows someday).
Fixes #345, Closes #462.
Reminders
make format
andmake check
to make sure the code follows the style guide.doc/api/index.rst
.