-
Notifications
You must be signed in to change notification settings - Fork 107
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
[WIP] New files for putting icepyx examples on pangeo-gallery #125
Conversation
Should be using reg_a.granules.avail instead of reg_a.granules
Reformat CONTRIBUTORS.rst, add myself, fix typo
Updated Contributers, added my name
update documentation and readme with clearer install instructions (including for windows users)
Update codecov badge to point to 'development' branch
Fix test failures in test_granules.py
mac OS upgrades can lead to machines unable to get IP from hostname. this is a fix to revert to using 'localhost' in case of a gaierror from socket.gethostbyname
…py#96) * add black pre-commit hook and reformat files using black * add github action workflow with flake8 on PRs
35e543a
to
975ae6c
Compare
If I understand it right, everything is controlled by the GitHub Actions, which are triggered when there are pushes/PRs to the specified branches. It makes sense to rebuild the notebooks when there is a new release (e.g. a push/PR/release on master) AND when there is a change to the gallery files that is merged (via PR) into development (for testing purposes). Right now it only does the former and we're looking to set it up to also do the latter, with the trigger either by changes to certain directories or a commit message code. |
I agree. I think the main problem to solve then is where do you put the content in the latter case? I think as written, the action will build notebooks and put them on the As far as changes to certain directories, the GitHub Action currently looks at:
|
I agree completely. Doing a test build for things going into |
Yeah, unsure what can be done there. I can dig into that a bit.
I have never really messed with Travis CI, I could probably do it with GitHub Actions though. If you know a bit about Travis, does it seem viable to take the Action in |
Oh, I think it does provide what you are saying. Check out this log from the |
- name: Commit files | ||
if: github.ref == 'refs/heads/master' | ||
run: | | ||
git config --local user.email "[email protected]" | ||
git config --local user.name "GitHub Action" | ||
git add binder-gallery.yaml doc/source/_static/icepyx_logo.png examples/*.ipynb | ||
git commit -m "Binderbot output" | ||
- name: Push commit | ||
if: github.ref == 'refs/heads/master' | ||
uses: ad-m/github-push-action@master | ||
with: | ||
github_token: ${{ secrets.GITHUB_TOKEN }} | ||
branch: ${{ steps.parse.outputs.binderbot_target_branch }} | ||
force: true | ||
- name: Trigger repository dispatch on Pangeo Gallery | ||
if: github.ref == 'refs/heads/master' | ||
run: curl -f https://pangeo-gallery-bot.herokuapp.com/gallery/submodule-dispatch/${{ github.repository }} |
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.
With the if: github.ref == 'refs/heads/master'
line(s), it seems that the commit-push-deploy will only happen on the master branch (which is good). Would it make sense then to run this binderbot GIthub Action on Pull Requests targeting both the master and development branches then, so we can test that it works on development too? (See suggestion on other comment).
Would it make sense to add this as part of the test suite (currently done with Travis CI)? It tests both the branch and the PR merge.
I have never really messed with Travis CI, I could probably do it with GitHub Actions though. If you know a bit about Travis, does it seem viable to take the Action in
binderbot.yaml
and get it in Travis?
It should be fine having both Travis CI and Github Actions CI, a rewrite won't be needed. Travis will run the icepyx
unit tests as usual and Github Actions will 'test' that the example gallery can be built correctly.
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.
Aha! I think you are right @weiji14 . It should only run those last three on master
, so we might have everything we need if we just add development
to the branches for the Action to listen to.
Co-authored-by: Wei Ji <[email protected]>
And now |
Oh. I think the problem is that the only record of the
Seems like another thing that won't be properly tested until the merge happens. |
gallery_repository: gallery_repository | ||
binder_url: binder_url | ||
binder_repo: binder_repo | ||
binder_ref: binder_ref |
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.
Oh. I think the problem is that the only record of the
Dockerfile
is on myenable-gallery
branch.binder-gallery.yaml
is told to look on themaster
branch for the image information and doesn't find anything, so it gets the error:ModuleNotFoundError: No module named 'xarray'
Seems like another thing that won't be properly tested until the merge happens.
Would it be possible to set the binder_ref
to just point to the branch it is building on? E.g. development
in this case.
Might be good to share a link to the pangeo-gallery documentation somewhere, so that others will know how this can be configured in the future.
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.
Yeah, I can change that for a test to see if it builds correctly.
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.
Not sure if it will help, but you can try to run Github Actions locally using https://github.com/nektos/act. Might be easier than just trial and error pushes to this Pull Request.
Per @weiji14 's suggestion, here is the Pangeo Gallery Contributor Guide that I have followed for this work. |
Pointing to my fork and looking at the enable-gallery branch. Will remove later.
@weiji14 Hopefully the emails aren't too much. I think I will try pushing to my fork's |
I think I've narrowed down the issue of 500 errors to something to do with the notebooks being in not the root directory. I've raised an issue on |
Thanks for tracking down the issue! I was struggling to understand the error messages too. Just as an idea, would it be better (or easier) if we move the examples to a separate |
I think most of the gallery repos are just that: standalone repos with content showcasing how to use something from a different repo. I do think it would be much easier to set that up, but it is a separate thing to maintain. I'm more than happy to help with that if y'all want to go that route. |
Thanks for all your conversation and troubleshooting, @salvis2 and @weiji14! It looks like this is shaping up quite well. As you've no doubt seen, we've already got a mix of GitHub actions and Travis CI, which I think is fine.
I'm not opposed to this idea, and the icesat2py organization is meant for this type of thing. Now that |
@@ -0,0 +1 @@ | |||
FROM uwhackweeks/icesat2:2020.06.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.
With the most recent updates to icepyx
, if we try to build against this Hackweek Docker image the examples will fail, since the icepyx
example notebooks have been updated to use Query
objects instead of Icesat2Data
objects.
cb9fa86
to
e7a9af0
Compare
Closing in favor of setting up https://github.com/icesat2py/icepyx-gallery |
This is the start of the work that will get some icepyx example notebooks onto Pangeo Gallery. @JessicaS11 and I have had some conversation about what this will look like and we are now putting the conversation on GitHub.
This building of notebooks can be another entry point / set of learning resources for users new to Pangeo and ICESat-2. Some of this work may be relevant later for the icepyx gallery that would be on ReadTheDocs; binderbot can maybe be repurposed for that. Currently, we still need to choose / work on:
a mechanism for naming the notebooks that we want built (because we do not want all of the notebooks built). This should look like a wildcard-style pattern for file names and will replace paths: - '**.ipynb' in .github/workflows/binderbot.yaml.This new PR is attempting to fix my
git
issues by having a specific feature branch...