Mark tests requiring network access and add a test workflow that disables network access

[jwodder]

Closes #87.

[codecov]

Codecov Report

Merging #88 (9d8a47d) into master (d4c1378) will increase coverage by 6.80%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #88      +/-   ##
==========================================
+ Coverage   89.47%   96.28%   +6.80%     
==========================================
  Files          14       16       +2     
  Lines        1378     1399      +21     
==========================================
+ Hits         1233     1347     +114     
+ Misses        145       52      -93     

Flag	Coverage Δ
unittests	96.28% <100.00%> (+6.80%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
dandischema/tests/conftest.py	100.00% <100.00%> (ø)
dandischema/tests/test_datacite.py	100.00% <100.00%> (+53.48%)	⬆️
dandischema/tests/test_metadata.py	100.00% <100.00%> (ø)
dandischema/tests/utils.py	100.00% <100.00%> (ø)
dandischema/datacite.py	95.32% <0.00%> (+43.92%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d4c1378...9d8a47d. Read the comment docs.

[yarikoptic]

are test fails against dandi-cli the same as recently encountered in dandisets (dandi/dandisets@7ec49de) requiring to wait for it to become "valid"? I even wonder now if such logic should be somehow incorporated into .publish with some time out (e.g. of 5 seconds, which should be sufficient for unittesting) since it seems to become a common pattern and ideally should not be duplicated across codebase?

[jwodder]

@yarikoptic That failure reason only applies to one test (fixed in dandi/dandi-cli@024b93b). Most of the failing tests are likely due to some mismatch in dandischema versions, and the failure is only exacerbated by the fact that trying to show the validation errors fails because dandi-cli's master branch expects version validation errors to be reported in a key that was removed from the API without telling me (addressed in dandi/dandi-cli@45a4215).

[yarikoptic]

is only exacerbated by the fact that trying to show the validation errors fails because dandi-cli's master branch expects version validation errors to be reported in a key that was removed from the API without telling me (addressed in dandi/dandi-cli@45a4215).

shouldn't we have caught it somehow by integration testing in dandi-api against dandi-cli -- https://github.com/dandi/dandi-api/actions/workflows/cli-integration.yml seems to stay green

[jwodder]

@yarikoptic We don't have any tests that expect Dandiset validation to fail.

[yarikoptic]

Thank you @jwodder, let's proceed.

@TheChymera , set DANDI_TESTS_NONETWORK=1 env var while running tests and those which require outbound network will be skipped

[TheChymera]

thanks, it worked ^^