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

Migrating testing & coverage services #124

Closed
jGaboardi opened this issue Jan 10, 2021 · 8 comments · Fixed by #135
Closed

Migrating testing & coverage services #124

jGaboardi opened this issue Jan 10, 2021 · 8 comments · Fixed by #135

Comments

@jGaboardi
Copy link
Member

jGaboardi commented Jan 10, 2021

@slumnitz Here is a list of stuff to go over & do for tomorrow's mini-sprint. (I also wanted to get a running list of things that can be added to the submodule_templat). This list may not be exhaustive and I have probably left off a few things, but I would imagine it will get us at least 95% there. Some of 1 is already taken care of in #111. I you like/have time, review #111 + this list of stuff, and take a first stab at this, otherwise we can get started tomorrow as planned.

Migrating testing & coverage services

  1. Travis to GitHub Actions for testing

    1. create an action workflow file in .github/workflow/
    2. create a ci/ directory with all the environment files to be tested (*.yml)
      • see example: ci/
    3. add all environments to the testing matrix
    4. These changes must be merged into the main branch before testing initializes, they will not run on the first PR
    5. remove .travis.yml and turn off Travis services
    6. swap out testing badge in README.md
  2. nose to pytest for testing

    1. swap out nosetests for pytest in the testing file created in 1.i
    2. remove the test_suite and tests_require keyswords from setup() in setup.py
    3. remove any nose-related packages from requirements*.txt files
    4. add pytest and pytest-cov to requirements_tests.txt (or a similar file)
  3. coveralls to codecov for coverage reporting

    1. create a code coverage schema file in root dir
      • see example: codecov.yml
      • set both after_n_builds variable to the number of builds that should complete before coverage testing is performed
    2. add codecov to requirements_tests.txt (or a similar file)
    3. add a .coveragerc file to the root dir (if not already present)
    4. turn on codecov from their website
      • may need Serge to hit the "OK" button for this
    5. add CODECOV_TOKEN (obtained from Codecov) to Settings -> Secrets.
    6. add coverage badge to README.md
      • see example in here (in the README.md table it's row 3, column3)
  4. Using a GHA for releases

    1. see example: release_and_publish.yml
    2. add wheel and twine to a requirements*.txt file
    3. add PYPI_PASSWORD (see details here) to Settings -> Secrets.
  5. Using a GHA for building & hosting docs

    1. create workflow
    2. ensure needed changes in Makefile
    3. ensure consistent name for doc folder in:
      • build_docs.yml
      • Makefile
    4. ensure consistent file path in conf.py
    5. after the first successful build change the source for docs in Settings -> GitHub Pages to gh-pages/(root) and save
  6. Add dependabot

    1. see example: dependabot.yml
@martinfleis
Copy link
Member

These changes must be merged into the main branch before testing initializes, they will not run on the first PR

Are you sure about this? I think I have fine tuned GHA in the PR before merging them.

Using a GHA for releases

Remember to add a PyPI token, otherwise it will not be uploaded.

@jGaboardi
Copy link
Member Author

Are you sure about this? I think I have fine tuned GHA in the PR before merging them.

I am not sure about this... could you share how you did it? Then we could kick start testing in #111.

Remember to add a PyPI token, otherwise it will not be uploaded.

Good catch.

@martinfleis
Copy link
Member

I have no clue how I did that. I think that it just worked? If you look at https://github.com/martinfleis/momepy/pull/208 which implemented switch from Travis/AppVeyor to GHA, it is already checked by GHA.

Maybe check repo settings/actions. I don't have rights to see that in splot.

@jGaboardi
Copy link
Member Author

If you look at martinfleis/momepy#208 which implemented switch from Travis/AppVeyor to GHA, it is already checked by GHA.

Huh... After checking back in spaghetti and spreg, it seems that when I migrated spaghetti to GHA the workflow did not run until it was actually merged, whereas in spreg it ran straight away in the PR. Not sure what is going on differently...

@martinfleis
Copy link
Member

Note: We should ensure to have environments with and without optional dependencies and test ImportError messages. It will apply at least to ipywidgets (#132).

@jGaboardi
Copy link
Member Author

jGaboardi commented Jun 30, 2021

Following the merge of #132, we should probably get rid of the master branch, right? Then we can loop back with streamlining/pruning down testing schema (see here). We also need to:

  • update supported Python versions in setup.py
  • (what else?)

In my opinion splot should migrate over to codecov and gh-pages, and implement GHA solutions for these, along with a release action. However, that is @slumnitz final decision in the end.

@martinfleis

@martinfleis
Copy link
Member

It uses codecov, I got a report in #132.

and gh-pages

Don't ask me, I am a fan of RTD. The solution for docs we have elsewhere is not optimal in my perspective (esp. docs versioning).

@jGaboardi
Copy link
Member Author

OK, let's stick with just the GHA for CI, then hold off on everything else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants