Create HDMF_dev.yaml - Githubissues

hdmf-dev / hdmf-zarr

Zarr I/O backend for HDMF

https://hdmf-zarr.readthedocs.io/

Other

7 stars 7 forks source link

Create HDMF_dev.yaml #136

Closed mavaylon1 closed 10 months ago

mavaylon1 commented 10 months ago

Motivation

What was the reasoning behind this change? Please explain the changes briefly.

This introduces a new workflow to run the tests on HDMF-Zarr using the dev branch of HDMF.

How to test the behavior?

Show how to reproduce the new behavior (can be a bug fix or a new feature)

Checklist

[x] Did you update CHANGELOG.md with your changes?
[x] Have you checked our Contributing document?
[x] Have you ensured the PR clearly describes the problem and the solution?
[x] Is your contribution compliant with our coding style? This can be checked running ruff from the source directory.
[x] Have you checked to ensure that there aren't other open Pull Requests for the same change?
[x] Have you included the relevant issue number using "Fix #XXX" notation where XXX is the issue number? By including "Fix #XXX" you allow GitHub to close issue #XXX when the PR is merged.

codecov-commenter commented 10 months ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (70bf35b) 85.92% compared to head (5185146) 85.92%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## dev #136 +/- ## ======================================= Coverage 85.92% 85.92% ======================================= Files 13 13 Lines 3189 3189 ======================================= Hits 2740 2740 Misses 449 449 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

mavaylon1 commented 10 months ago

Fix #126

mavaylon1 commented 10 months ago

@oruebel As I was making this, I started to think about how much did we want to test. Within tox.ini, it installs the latest release of HDMF. It will run pytest according to different environment versions.

Now ideally, this workflow could do something like that, but we can't use tox.ini because we would have to edit the install requirements to use the dev branch. What I have now is a proof of concept that it works for only python 3.11. Do we want this workflow to only do that or should we get creative and test for all python versions?

rly commented 10 months ago

@mavaylon1 I think testing on python 3.11 (or whatever is the latest version supported by both packages) is sufficient. We could test this workflow on all python versions, on all OSs, with minimum, pinned, upgraded, and pre-release requirements, but I think that is overkill and unlikely to catch issues.

rly commented 10 months ago

Unlikely to catch any issues that testing on each package independently would not catch.

mavaylon1 commented 10 months ago

Unlikely to catch any issues that testing on each package independently would not catch.

Agreed.

mavaylon1 commented 10 months ago

Since this is a workflow change, I am not updating the Changelog