Create HDMF_dev.yaml

[mavaylon1]

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

• Did you update CHANGELOG.md with your changes?
• Have you checked our Contributing document?
• Have you ensured the PR clearly describes the problem and the solution?
• Is your contribution compliant with our coding style? This can be checked running ruff from the source directory.
• Have you checked to ensure that there aren't other open Pull Requests for the same change?
• 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]

Codecov Report

All modified and coverable lines are covered by tests ✅

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

Additional details and impacted files

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mavaylon1]

Fix #126

[mavaylon1]

@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]

@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]

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

[mavaylon1]

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

Agreed.

[mavaylon1]

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

[rly]

LGTM