Keeping the RouterOS test lab on the newest release

2 hours ago

The two RouterOS containers this repository tests against stay on whatever release they first started with. The lab here ran 7.21.4 for months, and every fix was checked against an old RouterOS without anyone noticing. This pull request makes the drift visible and gives you the steps to fix it.

Ask about this presentation

Chapters

  1. 0:00The lab quietly goes stale
  2. 0:20Two causes
  3. 0:46What the pull request adds
  4. 1:21Evidence
  5. 1:45Where it stands
Show transcript
  1. The two RouterOS containers this repository tests against stay on whatever release they first started with. The lab here ran 7.21.4 for months, and every fix was checked against an old RouterOS without anyone noticing. This pull request makes the drift visible and gives you the steps to fix it.

    Slide text
    RouterOS test lab

    The lab tests against RouterOS from months ago, and nothing tells you.

    This change makes that visible, and fixes it.
  2. There are two causes. First, docker compose up never pulls a newer latest. An image that is already on the machine is used as it is. Second, each data volume keeps the disk of the image that first filled it. The author tried booting 7.23.8 on a volume that 7.21.4 had filled, and the container exited immediately because it could not open its disk file. So upgrading means removing the volumes.

    Slide text

    Compose never upgrades, and old volumes can't boot new images.

    No pull docker compose up uses an image already on the machine, even when latest has moved on.
    Old disk in the volume Version 7.23.8 on a volume filled by 7.21.4 exits at once: could not open chr-7.23.8.vdi.
  3. The new script, check_versions.py, uses only the standard library. It prints the newest release on each MikroTik channel, what Docker Hub has, and the version every lab router runs. It exits with 1 when a router is older than the newest long-term release. In the compose file, one variable per router chooses its image, and the old single variable still sets both, so defaults are unchanged. A fleet with mixed versions is normal for this server, so the lab can now mimic one. The README documents the upgrade steps and how to build a release Docker Hub doesn't have yet.

    Slide text

    A version check, a per-router image, and the upgrade steps.

    check_versions.py Compares each router with MikroTik's channels and Docker Hub. Exits 1 when a router trails the long-term release.
    ROUTEROS_IMAGE_A / _B Pick the image per router, so the lab can run two releases side by side.
    README steps pull, down -v, up -d, and how to build a version Docker Hub lacks.
  4. This is the output from a lab rebuilt with the new steps. Router A runs a local build of 7.25 and reports up to date. Router B runs the Docker Hub latest, 7.23.8, and the script flags it as older than the newest stable release. That shows a second finding: Docker Hub has no 7.25 tag yet, which is why the README explains building one.

    Slide text

    The check spots the router that is behind.

    Newest per channel: long-term 7.23.8 | stable 7.25
    Docker Hub: `latest` is 7.23.8
    routeros-a: RouterOS 7.25 (local build)   up to date
    routeros-b: RouterOS 7.23.8 (latest)   <- older than newest stable 7.25
  5. One more thing before you review. In a comment on the pull request, the author said they think it may be abandoned, and asked whether the owner of the Docker image keeps latest current. That question is still open. The change touches only the lab, docs and a script, nothing under src, so merging it would not publish a release. If the lab matters to you, review the script and the compose variables.

    Slide text
    Before you review

    The author may drop this change.

    Nothing under src/ changes, so merging does not release. The open question is whether the image owner keeps latest current.

What happened in AI today, in your inbox

One short email each evening. Read it and you’re caught up.

Built with ❤️ in New York