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

[WIP] New files for putting icepyx examples on pangeo-gallery #125

Closed
wants to merge 54 commits into from

Conversation

salvis2
Copy link

@salvis2 salvis2 commented Aug 18, 2020

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 binderhub to build notebooks on. I've put mybinder.org as the default.
  • a docker image to use as the computing environment for building the notebooks. Dockerfile is currently blank.
  • an updated description in binder-gallery.yaml (if desired)
  • what notebooks to build
  • 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.
  • how to reference the desired thumbnail image in a way that isn't thumbnail.png at the root of the repo
  • Adding this repo as a submodule to the Pangeo Gallery. I will set this up near the end via the instructions present in Pangeo Gallery's Contributor Guide.

This new PR is attempting to fix my git issues by having a specific feature branch...

weiji14 and others added 30 commits June 17, 2020 09:45
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
@JessicaS11
Copy link
Member

Okay, should I add the development branch to the GitHub Actions (which only has master right now) or have only the development branch there?

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.

@salvis2
Copy link
Author

salvis2 commented Aug 19, 2020

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 binderbot_built branch. I don't think we would want test commits to development to overwrite / break the master rendered notebooks. Could maybe make another GitHub Action that skips the commit / push steps to just verify that the notebooks build when changes are made to the relevant files on development.

As far as changes to certain directories, the GitHub Action currently looks at:

paths:
  - 'examples/*.ipynb'
  - 'binder-gallery.yaml'
  - 'doc/source/_static/icepyx_logo.png'

@JessicaS11
Copy link
Member

I don't think we would want test commits to development to overwrite / break the master rendered notebooks. Could maybe make another GitHub Action that skips the commit / push steps to just verify that the notebooks build when changes are made to the relevant files on development

I agree completely. Doing a test build for things going into development seems like a good approach to me, provided it can provide more useful output than "failed" in the case of failure (e.g. the error message and traceback and failed notebook). 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.

@salvis2
Copy link
Author

salvis2 commented Aug 26, 2020

I agree completely. Doing a test build for things going into development seems like a good approach to me, provided it can provide more useful output than "failed" in the case of failure (e.g. the error message and traceback and failed notebook).

Yeah, unsure what can be done there. I can dig into that a bit.

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?

@salvis2
Copy link
Author

salvis2 commented Aug 26, 2020

Oh, I think it does provide what you are saying. Check out this log from the binderbot action on the Landsat-8 Gallery and let me know if that seems good enough.

Comment on lines +60 to +76
- 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 }}
Copy link
Member

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.

Copy link
Author

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.

.github/workflows/binderbot.yaml Outdated Show resolved Hide resolved
@salvis2
Copy link
Author

salvis2 commented Aug 26, 2020

And now binderbot is doing an Action! Nice.

@salvis2
Copy link
Author

salvis2 commented Aug 26, 2020

Oh. I think the problem is that the only record of the Dockerfile is on my enable-gallery branch. binder-gallery.yaml is told to look on the master 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.

gallery_repository: gallery_repository
binder_url: binder_url
binder_repo: binder_repo
binder_ref: binder_ref
Copy link
Member

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 my enable-gallery branch. binder-gallery.yaml is told to look on the master 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.

Copy link
Author

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.

Copy link
Member

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.

@salvis2
Copy link
Author

salvis2 commented Aug 27, 2020

Per @weiji14 's suggestion, here is the Pangeo Gallery Contributor Guide that I have followed for this work.

@salvis2
Copy link
Author

salvis2 commented Aug 27, 2020

@weiji14 Hopefully the emails aren't too much. I think I will try pushing to my fork's master branch until it works. I'm not supremely familiar with binderbot; I've only used it to set up galleries from master branches of repos that are just gallery entries of other work. The errors listed are rather unfamiliar.

@salvis2
Copy link
Author

salvis2 commented Aug 27, 2020

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 binderbot to investigate: pangeo-gallery/binderbot#32. This PR may have to wait until I figure that out.

@weiji14
Copy link
Member

weiji14 commented Aug 27, 2020

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 icepyx-examples repository under the same icepyx umbrella?

@salvis2
Copy link
Author

salvis2 commented Aug 28, 2020

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.

@JessicaS11
Copy link
Member

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.

would it be better (or easier) if we move the examples to a separate icepyx-examples repository under the same icepyx umbrella?

I'm not opposed to this idea, and the icesat2py organization is meant for this type of thing. Now that icepyx is available to install with pip I think that alleviates many issues you might have with the code and examples in different repos. My only concern about separating them is whether or not it will make it feel more cumbersome (or simply be confusing) to new contributors to have the code and examples in different repos. Since git has such a steep learning curve, I'm hesitant to introduce any potential barriers to contributions by scientists who aren't trained in software development and don't have the time to invest in learning it.

@@ -0,0 +1 @@
FROM uwhackweeks/icesat2:2020.06.15
Copy link
Member

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.

@salvis2
Copy link
Author

salvis2 commented Oct 22, 2020

Closing in favor of setting up https://github.com/icesat2py/icepyx-gallery

@salvis2 salvis2 closed this Oct 22, 2020
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.

8 participants