Vlákno názorů k článku
GitHub Action tj-actions/changed-files napadena, krade tokeny, hesla a další údaje od prochac - Akce, co najde přes git změněné soubory. Lol....

Akce, co najde přes git změněné soubory. Lol. Já v GitHub Actions vidím prostě stejnou mentalitu, jaká je v JavaScript ekosystému.

Javascript mi pride viacej homebrew. Tento Github je DevOps prasárna. Ja sa ani nečudujem, že ľudia tomu nerozumejú. Keď niekto nakopí DevOps gibberish, je to to dosť odstrašujúce.

Ja len dúfam, že sa vývojárčina vráti do nejakého ľudskejšieho režimu.

Ono ty GH akce ale jsou JS prasárny - lidi používají desítky GHA v jejich CI, o kterých nic neví, a pak konfrontace něčeho takového právě způsobuje tyto problémy.

Já se třeba ve vlastních workflow snažím používat co nejmíň GHA od třetích stran, a přijde mi to tak celkem OK - lepší vlastní skript, který můžu zmigrovat na jinou službu než mít workflows napsané tak, že migrace znamená kompletní přepis všeho.

však jsou většinou napsané v JavaScriptu , typescriptu nebo tak něco

Ano, všechno si každý napíšeme od začátku, ideálně 100x jinak, vypalíme na tom haldu času... Stačí se podívat kolik má ta akce parameterů.

máme všechny action homemady a není to rozhodně tolik času, naopak je to ve výsledku jednoduší, přehlednější a udržovanější.

GH actions jsou super na zapouzdření devops prasáren, aby nemusely být přímo v repu nebo si to nějak klonovat/stahovat s každou prací.

Osobně jsem psal do Jenkinse, Gitlabu a Gitea (ekvivalent GH actions). Vím že (aspoň za mě) to jsou dny a dny práce než člověk vychytá co potřebuje (ale záleží na složitosti software a deploymentu). A osobně nerad přidávám další dny na psaní kola (tj. to co už napsal někdo předemnou a dal to public na GH)
GH actions jsou hlavně dobré kvůli deduplikování kódu a abstrakci (protože když pipeline chce deployovat, chce deployovat -- a je jí fakt jedno jestli je ve finále deploy řešený přes argocd, kubectl apply, ftp, rsync...). A taktéž aby člověk furt nepsal dokola kolo