Jak planuję posty na Bluesky bez użycia SaaS
Codziennie planuję trzy posty na Bluesky, korzystając z GitHub Actions i pliku JSONL. Nie używam zewnętrznych usług do planowania.
System działa w oparciu o pojedynczy plik: content/bluesky-queue.jsonl.
Każda linia w tym pliku to obiekt JSON.
- Nieopublikowane linie zawierają tylko tekst.
- Opublikowane linie zawierają znacznik czasu i URI posta.
Skrypt czyta plik od góry do dołu. Znajduje pierwszą linię bez znacznika czasu, publikuje ją, a następnie aktualizuje tę linię.
Dlaczego używam JSONL zamiast bazy danych:
- Łatwo śledzić zmiany w Git.
- Każde zadanie CI może dopisać nową linię do pliku.
- Dzięki temu konfiguracja pozostaje prosta i bezpłatna.
Obsługa wymagań Bluesky API Bluesky wymaga użycia „facets” dla linków i hashtagów. Nie można po prostu wysłać tekstu. Należy podać dokładne pozycje bajtowe tych elementów.
Używam skryptu do obliczania tych pozycji. Wykorzystuję TextEncoder, aby uzyskać przesunięcia bajtowe UTF-8. Zapobiega to błędom przy użyciu emoji. Znaki i bajty to nie to samo.
Optymalizacja GitHub Actions GitHub Actions często uruchamia się z opóźnieniem, jeśli zaplanujesz zadania na pełną godzinę. Aby temu zapobiec, stosuję przesunięcie czasowe (offset). Zamiast 00:00, używam 23:37. Zmniejsza to opóźnienia.
Dodaję również losowe opóźnienie od 0 do 5 minut przed publikacją. Dzięki temu wzorzec publikowania wygląda bardziej ludzko. Pozwala to uniknąć idealnie mechanicznego timingu, który niektóre algorytmy mogą traktować mniej przychylnie.
Zapobieganie nieskończonym pętlom Kiedy skrypt aktualizuje kolejkę, zatwierdza (commituje) zmianę z powrotem w repozytorium. Może to ponownie wyzwolić workflow.
Rozwiązuję to za pomocą mechanizmu ochronnego w wiadomości commita:
- Skrypt dodaje [skip bluesky-queue] do wiadomości commita.
- Workflow sprawdza obecność tego tagu.
- Jeśli tag istnieje, workflow nie zostanie uruchomiony.
System ten jest częścią długoterminowego eksperymentu z witrynami kuratorowanymi przez AI. Pozostaje lekki, tani i niezawodny.