Infrastruktura CI to lada kolos dla tak prostej roboty jak ‘sprawdź RSS, wyślij webhook’.

– Nowoczesne przysłowie leniwego admina

W poprzednim wpisie cieszyłem się z automatyzacji opartej na GitLab CI. Ale umówmy się – rozwiązanie, które działa, szybko zaczyna uwierać, jeśli pachnie “legacy”. Każda zmiana to push, każdy test to commit, a bash w 2026 roku? No cóż, bywają lepsze sposoby na spędzanie wieczorów niż debugowanie skryptów wewnątrz runnera.

Dlaczego uciekłem z GitLab CI?

Stary flow miał kilka wad, które zaczęły mnie irytować bardziej niż brak kawy o poranku:

  1. Zależność od repo: Nie ma pusha – nie ma sprawdzenia. System był reaktywny, nie proaktywny.
  2. Brak stanu (Persistence): Próba zapamiętania, co już wysłaliśmy, wymagała hackowania z artefaktami lub dziwnych commitów “state”.
  3. Ciężar: Odpalanie całego runnera, żeby zrobić prosty curl, to jak wyjeżdżanie czołgiem po bułki do sklepu obok.

Nowa architektura – Edge Computing

Zamiast czekać na pipeline, zaprzągłem do pracy Cloudflare Workers. Przeniosłem logikę na “krawędź” sieci. Teraz flow wygląda tak:

RSS Feed → Worker (Cron co 1h) → KV Store (Pamięć) → Discord + X

Zalety? Działa 24/7, ma natywny scheduler (crony!) i własną bazę klucz-wartość (KV), która służy nam za mózg. No i deploy trwa 5 sekund.

Discord – Bułka z masłem

Discord jest prosty jak budowa cepa (a jak wiadomo cep składa się z przedcepia, śródcepia i zacepia…). Podajesz mu Webhook URL, wysyłasz JSON-a i gotowe. Worker sprawdza RSS, porównuje datę ostatniego wpisu z tym, co ma w KV, i jeśli widzi coś nowego – strzela powiadomieniem.

// Minimalizm, który nie boli
if (!lastPublished || new Date(post.published) > new Date(lastPublished)) {
  await sendDiscordNotification(post, env.DISCORD_WEBHOOK_URL);
  await env.KV.put(LAST_POST_KEY, post.published);
  return new Response('New post notified: ' + post.title);
}

PRO TIP: W treści wiadomości na Discordzie używaj <${post.link}>. Bez tych nawiasów trójkątnych Discord czasami “zgaduje” embedy i chowa URL pod podglądem. Upierdliwe do debugowania.

X (Twitter) – Powrót do roku 2007

O ile Discord to nowoczesny standard, o tyle API Twittera (v2) to czysta partyzantka. Do publikowania tweetów wymaga OAuth 1.0a User Context. Zapomnij o prostym Bearer Tokenie – ten jest tylko do odczytu. Tutaj wkraczamy w krainę mroku:

  • Podpisy HMAC-SHA1 (tak, w 2026 roku!),
  • Generowanie Nonce,
  • Ręczne sortowanie parametrów (bo jeden błąd w kolejności i dostajesz 401 Unauthorized),
  • Konstruowanie nagłówka, który wygląda jak instrukcja do reaktora jądrowego.

W Cloudflare Workers nie chcemy ciągnąć ciężkich paczek npm, więc używamy natywnego Web Crypto API.

// Fragment magii OAuth 1.0a
const signingKey = `${encodeURIComponent(creds.apiSecret)}&${encodeURIComponent(creds.accessSecret)}`;
oauth.oauth_signature = await hmacSha1(baseString, signingKey);

Konfiguracja (Bez wycieków!)

Nigdy, przenigdy nie hardcoduj kluczy API. Nawet jeśli Twój kod jest “prywatny”. Używamy wrangler secrets:

# Discord
npx wrangler secret put DISCORD_WEBHOOK_URL

# Twitter (potrzebujesz wszystkich 5!)
npx wrangler secret put TWITTER_API_KEY
npx wrangler secret put TWITTER_API_SECRET
# ...itd.

Sekrety lądują zaszyfrowane w chmurze i są dostępne w Workerze przez obiekt env.

Scenariusze “co poszło nie tak”

1. “No new posts” (a post właśnie wyszedł)

Prawdopodobnie data w Twoim KV jest nowsza niż ta w RSS. Wyczyść stan i spróbuj ponownie:

npx wrangler kv:key delete last_post_published --namespace-id <twoje-id>

2. Twitter Error 401/403

Sprawdź, czy Twoja aplikacja na Twitter Developer Portal ma uprawnienia Read and Write. Domyślnie dostajesz tylko Read, co przy próbie tweetowania kończy się soczystym błędem.

Podsumowanie praktyczne

Ewolucja od “działa” do “działa dobrze” to proces. GitLab CI był świetnym poligonem, ale Cloudflare Workers to rozwiązanie klasy produkcyjnej. Lżejsze, szybsze i całkowicie niezależne od Twojego repozytorium.

Twój nowy zestaw narzędzi:

  • Wrangler – deploy w mgnieniu oka.
  • KV Store – żeby bot nie zapominał, co już zrobił.
  • Cron Triggers – automatyzacja, która faktycznie działa sama.

OSTATNIE SŁOWO: Testuj boty na dev-webhooku. Wysłanie 50 testowych powiadomień na produkcyjny kanał Discorda to najszybsza droga do zostania legendą (z tych negatywnych) w swojej firmie/projekcie. Ask me how I know.

Kolejny krok? Może Bluesky (AT Protocol)? Architektura jest gotowa, teraz czas wrócić do pisania konkretów.

PS. Jeśli czytasz to na Discordzie, to znaczy, że Edge Computing właśnie wykonał za mnie robotę, a ja piję herbatę.