With the install fixed, the tests ran and passed on 3.10-3.12, and the job
then failed at the last step: upload-artifact@v4 refuses to run on Gitea
(GHESNotSupportedError).
Every CI run died at "pip install -e .[dev]": pyproject.toml asks for
napalm_device_types, which lives in git.netork.io/NAPALM rather than on PyPI,
and pip found only an unrelated 0.1.0 there. Not one test had run in CI.
The workflow now installs napalm-device-types from git first. The matrix
drops 3.8/3.9 and requires-python says >=3.10, because napalm-device-types
itself needs 3.10 -- the package never installed on anything older.
Replayed in a fresh venv: napalm-device-types 2.0.0 from git, then the
package with its dev extras, tests green.
Closes netork#116.
`get_port_forwards` reports IPv4 mappings and IPv6 pinholes together, which is
right — both are inbound rules someone configured. `get_nat_translations` then
iterated all of them, and that is not: a pinhole is a firewall hole, and IPv6
does not do NAT at all.
The entries it produced were nonsense in two ways. They paired an IPv6 host with
the IPv4 WAN address, and `inside_local` came out as "2001:db8::10:22", where
the last colon is a port separator and everything before it is an address that
also contains colons.
The two failing tests were pulling in opposite directions.
`TestGetNatTranslations` was right and the implementation had drifted past it
when pinhole support landed. `TestGetPortForwards::test_returns_all_rules` was
the opposite: it still expected one rule from before pinholes existed, which put
it in direct contradiction with TestIPv6Pinholes further down the same file.
get_device_warnings() now returns only {code, meta} — severity, title,
message, and action are resolved centrally by netork's
WARNING_CATALOG (netork/core/device_warnings.py), not by the driver.
Also renames meta.version -> meta.latest_version for
firmware_update_available so it matches the netgear driver's shape and
the shared catalog message template.
Christian Manivong