test_server_info failing due to no good version provided

[yarikoptic]

now that there is no redirector with hardcoded version and version is reported of dandi-archive itself we hit good old dandi/dandi-archive#222 leading to

_______________________________ test_server_info _______________________________
dandi/tests/test_utils.py:321: in test_server_info
    assert Version(data["version"]) >= Version("1.2.0")
/opt/hostedtoolcache/Python/3.7.12/x64/lib/python3.7/site-packages/semantic_version/base.py:105: in __init__
    major, minor, patch, prerelease, build = self.parse(version_string, partial)
/opt/hostedtoolcache/Python/3.7.12/x64/lib/python3.7/site-packages/semantic_version/base.py:311: in parse
    raise ValueError('Invalid version string: %r' % version_string)
E   ValueError: Invalid version string: '0+unknown'

dandi/dandi-archive#1054 might be the one to resolve it for the main deployments but I don't know if it would apply to our dockerized server testing since it hardcodes to 0.0.0 in https://github.com/dandi/dandi-archive/pull/1054/files#diff-8fbdfcdd92c90a7625fcf215e3b363869ff8ce725869824d28380b863498d35dR14

[jwodder]

@yarikoptic That test is not run against the local Docker setup. The references to Docker in the test's code are for the integration tests with the old redirector.

[yarikoptic]

so you think test would pass after dandi/dandi-archive#1054 merged/deployed?

since placing into production would take time, should we just for now mark it as xfail and then reenable after deployed?

[jwodder]

@yarikoptic

so you think test would pass after dandi/dandi-archive#1054 merged/deployed?

Yes.

since placing into production would take time, should we just for now mark it as xfail and then reenable after deployed?

You tell me.

[yarikoptic]

if you have no opinion, then let's indeed proceed with mine of xfail.

[github-actions]

🚀 Issue was released in 0.39.3 🚀