Telegram
Follow us
Aktualizacja API GitHub Actions usprawnia śledzenie przepływu pracy dla programistów
Peter Zhang
19 lutego 2026 r., godz. 23:29
Interfejs API wysyłania przepływu pracy GitHub zwraca teraz identyfikatory uruchomień, dzięki czemu nie są już potrzebne niestandardowe rozwiązania do odpytywania podczas programowego uruchamiania zautomatyzowanych przepływów pracy.
GitHub po cichu rozwiązał jeden z bardziej irytujących problemów programistów automatyzujących swoje potoki CI/CD. Punkt końcowy API wysyłania przepływu pracy zwraca teraz identyfikatory uruchomień bezpośrednio w swojej odpowiedzi — niewielka zmiana, która eliminuje konieczność stosowania godzin pracy nad kodem obejściowym.
Wcześniej uruchomienie przepływu pracy za pośrednictwem API powodowało jedynie wyświetlenie statusu 204 No Content. Wiedziałeś, że przepływ pracy został uruchomiony, ale ustalenie, który run należał do Ciebie, wymagało wielu wysiłków, takich jak wielokrotne sprawdzanie API lub tworzenie niestandardowych systemów śledzenia. Problem ten został teraz rozwiązany.
Aktualizacja, ogłoszona 19 lutego 2026 r., wprowadza nowy opcjonalny parametr o nazwie return_run_details. Ustaw go na true, a otrzymasz odpowiedź 200 OK z identyfikatorem przepływu pracy, adresem URL API i adresem URL przepływu pracy. Pomiń ten parametr, a stare zachowanie 204 pozostanie niezmienione — zachowana zostanie kompatybilność wsteczna.
Użytkownicy GitHub CLI w wersji 2.87.0 lub nowszej otrzymają to automatycznie. Uruchom gh workflow run, a zobaczysz adres URL utworzonego uruchomienia oraz polecenie gh run view, aby je sprawdzić. CLI domyślnie ustawia teraz return_run_details na true.
Jest to ważne dla wszystkich, którzy tworzą automatyzację w oparciu o GitHub Actions. Należy tu wymienić systemy koordynacji wdrożeń, potoki przetwarzania wsadowego lub inne narzędzia, które muszą śledzić to, co wygenerowały. Poprzednie podejście – pobieranie danych z punktu końcowego runs i dopasowywanie znaczników czasu lub SHA commitów – było podatne na awarie i wymagało wysokiego limitu szybkości.
Czas jest niezwykły. Zaledwie dwa dni wcześniej, 17 lutego, GitHub zaprezentował swoją koncepcję Agentic Workflows, sygnalizując tym samym, że zamierza zainwestować więcej w programową kontrolę przepływu pracy. Platforma nadal pracuje nad odbudową swojej reputacji po poważnej awarii, która miała miejsce 2 lutego i wpłynęła na hostowane runnery, zakłócając działanie potoków CI/CD w całym ekosystemie.
Dla kontekstu: w grudniu 2025 r. GitHub zwiększył maksymalną liczbę wejść workflow_dispatch z 10 do 25, co oznacza dalszą poprawę jakości życia w przypadku złożonych scenariuszy automatyzacji.
Funkcja jest już dostępna w REST API. Dokumentacja jest dostępna w przewodniku GitHub po zdarzeniach przepływu pracy Actions dla wszystkich, którzy są gotowi porzucić swoje niestandardowe hacki śledzenia.
Źródło obrazu: Shutterstock
