Jak mały błąd parsera wersji zepsuł autoaktualizacje WP Staging CLI

Jeśli używasz WP Staging CLI v1.10.0 lub v1.11.0, wbudowane polecenie wpstaging update odmówi sprawdzenia aktualizacji i wypisze „Update check skipped for development version". CLI nie może zaktualizować się w miejscu na tych dwóch wersjach. Ten wpis wyjaśnia, co poszło nie tak, co naprawiliśmy oraz jednorazowe polecenie, które przywraca Cię do zdrowej instalacji.

W skrócie

Wersje, których dotyczy problem: tylko v1.10.0 i v1.11.0. Aby przywrócić sprawność, uruchom ponownie nasz oficjalny instalator. Wykrywa on Twoją istniejącą instalację, zastępuje plik binarny w miejscu i pozostawia Twoje witryny, licencję i konfigurację nietknięte.

Linux, macOS, WSL:

curl -fsSL https://wp-staging.com/install.sh | bash

Windows PowerShell:

irm https://wp-staging.com/install.ps1 | iex

Windows CMD:

curl -fsSL https://wp-staging.com/install.cmd -o install.cmd && install.cmd && del install.cmd

Następnie będziesz na v1.11.1 lub nowszej, a wpstaging update znów działa normalnie.

Co się stało

Aktualizator traktuje wszystko, co nie wygląda jak czysty ciąg semver, jako kompilację deweloperską i po cichu pomija sprawdzanie aktualizacji. Intencja była rozsądna: gdy kompilujesz CLI lokalnie za pomocą go run lub make build bez flagi wersji, w przeciwnym razie widziałbyś mylący komunikat „Update vX.Y.Z available (current: vdev)" przy każdym uruchomieniu polecenia.

Błąd: nasze tagi wydań są wypychane jako v1.10.0, v1.11.0 i tak dalej, z wiodącym v. Parser wersji wymagał jednak samego 1.10.0. Wiodące v miało być usuwane najpierw, ale sprawdzenie kompilacji deweloperskiej uruchamiało się przed krokiem usuwania. Tak więc każdy plik binarny otagowany jako wydanie widział siebie jako kompilację deweloperską i po cichu pomijał własne sprawdzanie aktualizacji.

Dotyczyło to obu ścieżek kodu:

• Jawnego polecenia wpstaging update, dlatego jego uruchomienie przerywało się komunikatem „skipped" zamiast aktualizować.
• Automatycznego sprawdzania w tle, które uruchamia się raz dziennie przy dowolnym poleceniu, dlatego nigdy nie pojawił się też baner aktualizacji.

Efekt netto jest taki, że instalacje v1.10.0 i v1.11.0 nie mogą same się naprawić. Poprawka musi przyjść spoza zepsutego pliku binarnego, dlatego krokiem przywracania jest jednowierszowy instalator powyżej, a nie wpstaging update.

Co zrobiliśmy

1. Wydaliśmy v1.11.1 z poprawką. Sprawdzanie kompilacji deweloperskiej najpierw usuwa wiodące v i pomija ścieżkę aktualizacji tylko dla prawdziwych tagów deweloperskich, takich jak v0.0.0-dev i dev.
2. Dodaliśmy testy regresji obejmujące cztery istotne formy: v1.11.1, 1.11.1, v0.0.0-dev i dev. Pierwsze dwie muszą przejść sprawdzenie deweloperskie; dwie ostatnie muszą pominąć ścieżkę aktualizacji. Testy zawiodą głośno, jeśli kolejność kiedykolwiek znów się cofnie.
3. Zaczęliśmy budować kanał powiadomień po stronie serwera w naszym API licencji, aby w rzadkim przypadku podobnego zablokowania w przyszłości móc wyświetlić komunikat w produkcie, bez polegania na samej ścieżce aktualizacji.

Co musisz zrobić

Uruchom jednowierszowy instalator dla swojej platformy z sekcji W skrócie powyżej. Zrobi on:

• Pobierze v1.11.1 (lub nowszą) dla Twojego systemu operacyjnego.
• Zweryfikuje sumę kontrolną.
• Zastąpi istniejący plik binarny wpstaging w miejscu.
• Pozostawi Twoje witryny, licencję, pamięć podręczną i konfigurację nietknięte.

Gdy się zakończy, potwierdź, że aktualizacja się powiodła:

wpstaging --version

Powinieneś zobaczyć v1.11.1 lub wyższą (wydane pliki binarne wypisują wiodące v). Od tego momentu wpstaging update działa zgodnie z oczekiwaniami, a codzienne sprawdzanie w tle automatycznie wychwyci przyszłe wydania.

Zapobieganie tej klasie błędów

Ten błąd był szczególnie dotkliwy, ponieważ zepsuta ścieżka kodu to ta sama, która normalnie powiedziałaby Ci o aktualizacji. Obejście po stronie użytkownika nie było możliwe; przywrócenie musiało przyjść od nas. Aby mieć pewność, że podobne zablokowanie nie może się powtórzyć po cichu, wprowadzamy trzy warstwy:

• Testy regresji, które poddają parser wersji próbie zarówno wobec prawdziwych tagów wydań, jak i tagów deweloperskich, tak aby kolejność między usuwaniem a sprawdzaniem nie mogła zostać ponownie po cichu odwrócona.
• Sprawdzenie typu smoke w momencie wydania na skompilowanym pliku binarnym, które potwierdza, że ścieżka pomijania deweloperskiego nie jest brana dla rzeczywistego tagu wydania. Jeśli wydanie kiedykolwiek zostanie wysłane z błędnie aktywnym sprawdzeniem deweloperskim, kompilacja zawiedzie, zanim plik binarny dotrze do użytkowników.
• Kanał powiadomień po stronie serwera w API licencji. Po wdrożeniu CLI będzie mogło wyświetlać krótkie komunikaty, które publikujemy po naszej stronie, tak aby każdy przyszły incydent można było zakomunikować bez przechodzenia przez samą ścieżkę aktualizacji.

Dziękujemy za korzystanie z WP Staging CLI i przepraszamy za niedogodności, które wywołał ten przypadek.

To był zwykły, ludzki błąd inżynieryjny, a nie problem z kodem wygenerowanym przez SI. Przeoczyliśmy go, naprawiliśmy i dodaliśmy testy regresji oraz sprawdzenia w momencie wydania, aby właśnie ta usterka nie mogła ponownie po cichu trafić do wydania.

Pytania lub problemy

Jeśli instalator nie działa u Ciebie lub po ponownej instalacji widzisz coś nieoczekiwanego, skontaktuj się z nami:

• Formularz kontaktowy
• GitHub: otwórz zgłoszenie w repozytorium wydań WP Staging CLI