GitHub Actionsはマジで苦痛！みんな困ってる？使いにくいと話題沸騰
引用元：https://news.ycombinator.com/item?id=43419701
GitLabの方が良いって言う人がもういるね。確かにそうだけど、GitLabにも別の意味で困ったところがあるんだよね。Jenkins、GitLab、GitHubと色々使ってきたけど、CIのロジックはできるだけ自分のコードに書くのが一番だって結論になったよ。シェルスクリプトでもmakeでも、何でも良いけど、ちゃんとメンテできるコードにするのが大事。それと、パイプラインをローカルでも実行できるように時間を使うべき。そうしないと、テストとかデバッグがマジで大変になるからね。あと、YAMLはできるだけ避けるべき。CIを解決してくれるみたいなVCが出資してる新しいものには、あんまり期待しない方が良いよ。EarthlyとかDaggerとかね。ランナーはいつも自分で用意して、できればオンプレミスが良いと思うな。
数年前、Tech Leadとして初めての仕事で、偶然にも全く同じ結論にたどり着いたんだよね。大規模なCMSプロジェクトで、クライアントがセキュリティ上の理由でデプロイの自動化は無理だって言ってたんだ。だから、コードとか設定のデプロイは、複雑な手順書に従ってサポートエンジニアが手動でやってたんだ。まあ、予想通りの状況だったよ。最初は自分の問題を解決するために、ローカルサーバーにパッケージしてデプロイするためのbashスクリプトをたくさん作ったんだ。それをチームで共有して、みんなの問題を解決したんだよね。バグがなくなったら、スクリプトを更新してローカルから開発環境にデプロイできるようにしたんだ。それでJenkinsを導入して、同じbashスクリプトを使うように設定したら、開発環境とテスト環境へのCI/CDが完全に動くようになったんだ。そのうち、プラットフォームのサポート担当者が手動での作業に飽きて、俺たちが作ったスクリプトを使ってステージング環境と本番環境へのデプロイを自動化し始めたんだ。クライアントが俺のやり方に気づいた時には、完全に無視されたことに気づいた時には、もう大喜びしてたよ。ローカルから本番まで、繰り返し可能でエラーのない自動デプロイができてたからね。結構自慢できることだったよ。
CIのピークがJenkinsだったってのがマジで嫌だわ。JenkinsもGroovyも嫌いだけど、今まで働いたどの会社にも、6年間稼働してるJenkinsがあって、会社全体を支えてるんだよね。なんか教訓がありそうだわ。
Jenkinsがピークってマジ？どのCIプラットフォームを使ったことがあるの？TeamCityはマジでおすすめだよ。GitHub Actionsでみんなが直面してるような問題は全くないみたい。GUIでも設定できるし、XMLでも、型安全なKotlin DSLでも設定できるんだ。しかも、これらは全部連携してるから、コードで設定されてるシステムでもGUIでパッチを当てられるんだよね。TeamCityは設定をgitリポジトリに保存して、変更があったらコミットする方法も知ってるから、DSLのドキュメントを調べるほどでもない簡単な変更とか、実験にはマジで便利。
他の人がセットアップしたCIが嫌いってだけじゃないかな。数年前にTeamCityを使った仕事があったけど、マジで嫌いだったよ。でも、嫌いだった理由の多くは、セットアップの仕方が悪かったからだと思うんだ。CIは誰もやりたくないけど、みんながただ動いてほしいもの。どんなコードやプロセスでもそうだけど、良くするためにはエンジニアリングが必要なんだよね。どんなプロジェクトでも、結果が悪いからってツールを責めるのは違うと思うな。
TeamCityでクリーンなgit cloneを試してみてよ。無理だよ。”クリーンクローン”ができるって言ってるプラグインを使ってもね。CIはクリーンな状態からアプリをビルド/実行/テストできるって確信を持つべきなんだ。CIがクリアできないキャッシュされた状態をエージェントに強制するなら…TeamCityは間違ってるよ。
＞gorilla consulting
たぶん’guerilla’だけど、あなたのバージョンの方が好きだな。
Nixはマジで最高だよ。CIツールを全部she’llかPythonで書いて、CIで実行されるのと同じ環境でローカルで実行できるんだ。SOPSを追加して、シークレットも一緒に持って行けるし。
NixってGitHub Actionsと相性いいのかな？それとも、Nix自体が代替になる感じ？例えば、pushするたびにテスト実行して開発環境にデプロイするのを自動化するにはどうすればいいんだろ？
NixとかBazelみたいな隔離されたシステムは、手軽にローカルで再現できるからマジ便利。
CIプラットフォームは、ステップごとに分けて、並列実行を可視化したり、GroovyとかJSでAPI叩いて通知出したりしたがるけど、それって本末転倒じゃね？ビルドツールが管理すべき。
次世代CIは、ローカルのツールと連携して、ビルドツールがやってることを表示してほしい。テストランナーも、プロセスごとにログとか出してくれよ。
半導体業界出身だけど、Jenkinsとbashスクリプトで全部ローカルでやってた。web SaaSのスタートアップに来たら、全部サードパーティ製でビックリ。POSIXとかLinuxの知識がほぼ役に立たない。
慣れたけど、本当に良いのか疑問。抽象化されすぎて誰も全体を理解してない気がする。
これな。
ローカルrunnerベースのCI/CDにめっちゃ投資してる。最初はgogsとdrone使ってて、今はforgejoとwoodpecker CIのフォーク。
冗長化構成で、分散ハードウェアで簡単に構築できる。認証とクロスシステムのpull requestがちょっと面倒だけど、feature branchのマージとコードレビューは必要。
Goで全部作ってるから、/toolchain/build.goを用意して、bashも不要。
Github Actions CVEが決定打だった。TJ actionsがcompromisedされたのも同じ脆弱性だし。zizmorだけが脆弱性を検証してくれる。
最近はGitHub ActionsをMakefileのラッパーとして使うようにしてる。dependenciesのインストールとかbuild/Testコマンドとか全部Makefileでやってくれるから、ローカルでもテストできるし便利。
mise（https://mise.jdx.dev/）とdagger（https://github.com/dagger/dagger）も良さげじゃね？Miseはdependenciesインストールしてタスク実行できるし。
daggerはVCから資金調達してるから救世主にはならないって意見もあるけど、CIじゃなくてAIに目をつけたみたい。“something something agents”って感じ。
dagger.ioから引用すると、”agentic softwareのためのオープンなプラットフォーム。
オープンなエコシステムで強力で制御可能なagentを構築。
モジュール式の拡張可能なプラットフォームで完全な可視性とクロスランゲージ機能を使用してagenticアプリケーションをデプロイ。
Daggerを使用してCIを近代化し、AIワークフローをカスタマイズし、MCPサーバーを構築するか、信じられないほどのagentを作成します。”
やあ！DaggerのCEOだよ。CIパイプラインに加えて、DaggerがAI agentも実行できるって気づいたんだ。ユーザーが教えてくれたからね。
だから、それを活用しようとしてる。全角“something something agents”みたいな感じにならないように頑張ってるけど、まだやるべきことはあるね！エフェメラルな実行エンジン、クロスランゲージコンポーネントシステム、深い可観測性、インタラクティブなCLIが両方のワークロードに最適である理由をマーケティング用語で説明するのは難しい…でも頑張るよ！
社内では、自分たちをCI企業ではなく、CI市場で活動するオペレーティングシステム企業だと考えてた。今はAI agentっていう新しい市場に拡大してる。プラットフォームは両方実行できるから、両方サポートし続けるよ。
興味があれば、詳細はこちらで共有してるよ：https://x.com/solomonstre/status/1895671390176747682
＞全角“CIを一度で解決してくれるけど、最終的には収益化する必要があるような、VCが出資してる新しいもの（earthly, daggerとか）に縛られないように。”
まさにこのスレッドの根本にあるコメントから。
長年の試行錯誤の結果、うちのチームも同じ結論に至った。クレイジーだと思う人もいるかもしれないけど、C#のCLIアプリケーションとしてスクリプトを実行してる（メインのアプリケーションはC#のwebサーバー）。bashスクリプトはほとんどなくて、あってもエントリーポイントくらい。ビルドと実行ファイルの受け渡しはちょっと手間だけど、静的型付けとかライブラリの利用とか、CIがtypoでダウンしないメリットの方が大きい。
環境変数を引数として渡すのもおすすめ。必要なdependenciesが分かりやすくなるし、移植性も高まる。
マジでそれな。YAMLを単なる設定ファイルじゃなくて、最適化されたCIパイプラインみたいな複雑なコードに使うとかありえんわ。正気か？あんたみたいな人が、ちゃんとしたプログラミング言語を使うべきだって言ってくれるから救われるわ。Lisp使いの人たちがこの狂気を見てどう思ってるか想像もできん。
ほんとそれ。誰が考えたのか知らんけど、これは「ワンクリックビルド」の原則だよ。それができないなら問題あり。
だから、CIは全部「ワンクリック」でできるスクリプトとして書くようにしてる。こうすると、CI全体の開発・テストが楽になるし、CIの実装を切り替えるのも簡単。CIがダウンしてても、ローカルでビルドできるから安心。
ただ、環境構築もスクリプトでやるから、速度は遅くなるかもね。
＞パイプラインは開発者のマシンでもローカルで実行できるべき（少なくとも可能な限り）。 ＞常に独自のrunnerを使うこと。可能であればオンプレミスで。 独自のrunnerだとキャッシュが便利。10GB以上の「開発コンテナイメージ」を、たった10行の変更のためにダウンロードし直す必要がない。 YAMLについて説明してくれない？宣言的なパイプラインなら、まあまあ使えると思うんだけど。 YAMLはマークアップ言語としては問題ない。単純な設定ファイルとかなら全然OK。 ＞CIは「設定」じゃなくて「コーディング」。 YAMLが宣言型プログラミング言語として正しいかどうかは興味ないけど、GitHub Actionsのワークフローを繰り返すのはマジで苦痛。重要なロジックを全部スクリプトとかMakefileに閉じ込めて、ローカルで高速にテストして、GitHubには環境構築とスクリプトの実行だけやらせる。 GitHub Actionsのワークフローを試すのめっちゃめんどいよね。大事なロジックはスクリプトとかMakefileに書いとけば、ローカルで爆速で試せるし。GitHubには環境用意してもらって、スクリプトを順番に実行してもらうだけで済むじゃん？何が悪いの？ .ymlファイルには必要最低限のことだけ書いとくのが良いってことだよね。依存関係インストールとかビルド実行のスクリプト呼び出しだけとか。ランナー待つのもマジでイライラするけど。pushして待つしかないし。だからローカルでも実行できるスクリプトが良いってことね。ローカルで試せないとマジで辛い。 そのドキュメントにはそんなこと書いてないじゃん。「.ymlファイルには必要最低限のことだけ書いとけ」みたいなことなんてどこにも書いてない。ただの基本的な使い方しか書いてないし。それに、悪い例を紹介してるよね。 書いてあるよ。スクリプトにロジック書いとけってことじゃん。シェル使ってコマンド実行するのなんて普通じゃん。エラー処理は自分で書けばいいし。CIエージェントはtrue/falseしか理解しないんだから。ベストプラクティスもちゃんと書いてあるし。highlightしてるところは権限の話でしょ。 ＞However, CI is not ”configured”, it is coded. YAMLにbreakpoint置けないし、変数評価できないし、debug情報printできないし、途中からrerunできない。YAMLはhappy flowには良いけど、それ以外はマジで無理。 Daggerの話しようと思ったけど、AIのゴミになっちゃった。depot.devはrunnerがマジで速いからオススメ。 マジかよ、GitHub ActionsとDevOpsってそんなに嫌われてるんだ！ 俺は長年使ってて、ほとんど問題ないし、むしろ気に入ってるんだけど。全然知らなかった。セットアップとかテストは確かにちょっと面倒だけど、一度動けばこっちのもん。Nodeのバージョンアップ以外、4年も触ってないし。単純なニーズには合ってるのかもね。 何するかによるんじゃない？ GitHub CIはスクリプト言語とか、モノレポじゃない単一プロジェクトとか、複雑な統合テストがないとか、コンプライアンスがガチガチじゃないとか、開発者の権限がほぼ同じとか、CIが速いとか、そういう場合に合うように設計されてる気がする。それ以外だと問題が多発する。無料みたいな値段で始められるから、最初は安く見えるんだけど、結局高くつくことが多い。他のCIソリューションも大して変わらないけどね。 ＞no need for compliance enforcement stuff ＞languages with no or very very cheap ”compilation” steps (i.e. basically only scripting languages) GitHub Actionのキャッシュとビルドartifactの扱いがマジでクソ。アップロードもダウンロードも遅いし、細かいイライラが多すぎる。GitHub runnerも小さいから、リンカが重いとパフォーマンスがめっちゃ悪くなる。プロジェクトが小さければ関係ないけど。 キャッシュが遅いのはどこも同じだと思う。シングルマシンのgitlab runnerでも、ローカルキャッシュへのアップロードにめっちゃ時間がかかる。100MBのアーカイブで数十秒とか。 GitLabにはマジでイライラする。runnerはNVMe SSD積んだAlienwareデスクトップなのに、ローカルディスクからuncompressedキャッシュを読み込むのに10分もかかる。毎回、ジョブの起動に5～10分かかるんだよ。 ＞But the worst part, which maybe is where a lot of hatred comes from, is that it’s there for cheap maybe even free (if you anyway pay for GitHub) and it doesn’t need an additional contract, billing, etc. 他のCIソリューションも大差ないってのがマジな話だよね。どのCIシステムも、想定された幸せな道から外れると途端にダメになる。もうCI自体諦めるしかないんじゃないかって思うわ。 GH Actions使ってるけどさ、他のビルドシステムと同じで、得意なことだけやらせるのがコツだよ。残りはシェルスクリプトかDockerコンテナでやるべき。複雑になったら「このスクリプトを実行」ってレベルまで単純化する。スクリプトの方がYAMLよりずっと書きやすいしデバッグしやすいからね。 GH Actions使うなら、他のビルドシステムと同じで、得意なことだけやらせるのが基本だよね。残りはシェルスクリプトかDockerコンテナで。 GitHub Actionsの目的がシェルスクリプトを順番に実行することだけなら、なんで式評価とか条件分岐とか、 GitHub Actionsのいいところは、GitHub ActionsのUI/APIからパイプラインが見やすくなること（PRビルドのステータスチェックとか）。再利用性も高いし。GitHub Actionとしてパッケージされてれば、他のプロジェクトのシェルスクリプトよりずっと再利用しやすい。GitHub Actionsは完璧じゃないけど、慣れればかなり使えると思う。 ＞GitHub Actionsの目的がシェルスクリプトを順番に実行することだけなら、なんで式評価とか条件分岐とか、 みんなYAML嫌いなのは、そう言うのがクールだと思ってるからでしょ。Python嫌いと同じ。見当違いな’hate’でも。 いろいろな組織を見てきたけど、DevOpsで苦労してる人たちには、とにかくシンプルにして、サードパーティへの依存をなくすように勧めてる。GitHub Actionsのhello worldみたいな状態に戻すのが一番。文句言う人は、HNとかで読んだことを鵜呑みにして、無駄に複雑な構成にしてるんだよね。パッケージマネージャーを5回も変えてるとか、パフォーマンスのためにJS, TS, Py, Go, Rustを混ぜてるとか。データベースの設定がひどいことになってるのに、言語がボトルネックだと思ってるんだから笑える。DevOpsも同じ。新しいものに無駄金使ってる。 みんなと同じ苦労をしてるってことだよね。ただ、あなたはそれを無視してるだけ。 そうかもね。でも、特に困ってないんだよね…。いつも問題なくビルドできるし。コードをコミットしてプッシュして、45秒待つとAWSに同期されて、サイトがS3バケットを定期的にチェックして新しいアイテムをダウンロードする。モバイルアプリとかよりずっと安定してる。ウェブアプリにコードをプッシュするのは楽しみだけど、モバイルアプリのビルドパイプラインはマジで憂鬱。 マジで全然問題ないんだよねー。毎回ちゃんとコードbuildしてくれるし。まあ、みんなが言ってるのは信頼性がないってことじゃないからね。セットアップがマジでめんどいって話。一回やっちゃえば、あとはほぼ放置でOK。CIがめっちゃシンプルでいつも同じなら、こういう問題に直面しにくいのかもね。 モバイルアプリのbuild pipelineはマジで憂鬱。 問題点って言うほど深刻じゃない気がするけどなー。deprecation warningがログに出たり、GitHubからメールが来たりしたら、1行commitしてNode.jsのバージョン上げるだけじゃん。簡単じゃん。typoしてpushするまで気づかないとかもあるけど、ちゃんと考えて書くようにしたら減ったし、誰かにちゃんとレビューしてもらうようにした（ただスクロールしてLGTMするだけじゃなくて）。俺の経験だと、設定しちゃえばほぼ放置でOK。数分の設定で、何年もbuildし続ける恩恵を受けられる。 問題解決じゃなくて、問題を矮小化してるだけじゃん。そりゃどんな問題でもそうやって解決できるけど、周りのものが完璧じゃなくても、ちょっとくらいマシな方が良くない？ それって「ちょっと壊れてる」ってレベルじゃないと思うけどなー。それが普通じゃん。常に完璧に動いて、interventionとかupdateが必要ない魔法みたいな解決策なんてないと思うし。 ＞That’s just how it works.”今は”そう”だけど、ずっとそうである必要はないじゃん。もっとマシな未来を想像できるじゃん。イライラしないような。 組織の規模とか、専門性の高さによるんじゃない？今はGitHub Actions嫌いだし、GitLab CIの方が全然良いと思ってるけど、俺にとってはたまに触る程度だから深く考えてない。でも、もし自分が「100% DevOps担当」で、巨大組織のためにずっとこれ専門でやることになったらマジで嫌だわ。多分1週間で発狂する。 GitHub Actions自体は嫌いじゃないんだけど、一部の開発者がCIでエラーが出ても基本的なdebuggingをしないのが問題。ローカルで動いてCIでエラーになると、すぐ俺にメッセージ送ってくるんだもん。だから「100% DevOps」じゃなくて、他の開発者のローカル環境のdebuggingに時間を費やしてる。 一番好きなのは、エラーメッセージがめっちゃ長くて、ほとんど関係ないことばかりだけど、問題の答えがその中に書いてあるパターン。 勘違いしてたらごめん、workflow_dispatchを使えば、無駄なcommitをしなくてもactionをtriggerできるよ。 マジでそれな。actions/upload-artifactがバイナリから実行許可剥ぎ取るの、マジありえん(1)。最初にやらかして6年も放置とか、マジでここのチーム信用できんわ。CI/CDサービス選ぶ時って、安定性と正確性マジ重要じゃん？GitHubにはどっちもねーわ。自前のタスクランナーをオフィスのPCに一日で構築して、uptimeもコストもパフォーマンスも実装も全部GitHub Actionsより上とか笑える。GHA選ぶ理由マジでわからん。Hello Worldレベルなら騙せるんかな。 そりゃ、あんたのフローがシンプルで、数人しか触らないならそうかもね。世の中には、委員会で作ってメンテしてるDev-opsパイプラインの悪夢みたいなのがゴロゴロあるんだよ。マジで勘弁。 使えないコミット作るなら、‘git commit –allow-empty’がおすすめだよ。でもGitHubって、コミットなしでアクション再実行できるボタンなかったっけ？GitHub Actionsは、計算時間気にしないなら一番楽。オープンソースのリポジトリで無料版使ってるとか、会社がコスト気にしないとかならね。計算時間気にするなら、設定頑張れば節約できるけど、マジで面倒。 ちょい複雑な、ありきたりじゃないワークフローやることになるまでは、俺もそう思ってたわ。CIジョブ構築がこんなに簡単になったのはマジすごいと思うけど、ローカルで完結させてからサービスにpush、って感じじゃないのが不満。 あんたのニーズがシンプルなだけだよ。Travisが閉鎖してからGitHub actions使ってるけど、今のところ問題ないわ。50人もいて5つの言語使うような大規模プロジェクトでGitHub actionsメンテしたいとは思わんけど… ソフトウェアエンジニアはイテレーション速度が命。変化に対応できないパイプラインは、マジで金食い虫。 一番最悪なフィードバックループについて誰も触れてないのが気になる。30-60秒のフィードバックループってマジ最悪。画面に釘付けになるけど、生産性はゼロ。GHAの環境をローカルで再現しようとしたけど、無理だった。だから変更するたびに「push、GHが拾うの待つ、typoとかのミスに反応、やり直し」。スロットマシンみたいに「あと一回で当たる」って感じで、集中力と時間を奪っていく。5秒で終わるビルドに25分もかかった。GHAだと依存関係とかで3分かかる。キャッシュ追加？10時間溶けた。失敗と集中力低下のコストがデカすぎる。 マジでそれな。GitHub Actionのコンテナビルドのデバッグで、1回40分以上かかるとか…一日6、7回しかテストできずに終わる。マジでもっと良い方法あるだろ。誰か解決してくれ。 actってツールがあるよ。ローカルでアクション実行できる。完全に同じってわけじゃないけど、時間節約になるかも。 組織設定だと、既成のアクションや組織専用のアクション（ダウンロード不可）を使わされてるとほぼ役立たずだよね。アクセスできないイメージのセルフホストランナーを使わされる場合も同様。環境変数とかネットワークとかもそうだし… actはマジ最高だよ！GitHubとかGiteaのアクションをローカルで試すのにめっちゃ役立つ。 daggerってのがあるよ。CIをコードとして扱えるんだ。ローカルのIDEでパイプラインをテストできる。 GitLab使ってて、firecow/gitlab-ci-local がめっちゃ時間短縮になるって気づいた（GitHubのnektos/actみたいなもん）。GitLab/GitHubがデフォルトでこういうの提供してくれたら嬉しいんだけどな。 actはマジで良い。アクションをローカルで試すのに使ってる（Giteaのアクションをセルフホストしてて、act使ってるからGitHubのアクションと全く同じ）。 これマジでうちのフラストレーションの大きな原因だわー。フィードバックループが最悪で、どれだけ精神的なスペースを無駄にしてるかって話だよね。OPも最後に同じこと言ってる（何か動くまで終わらない”wip”コミットの世話）。 nektos/act 超おすすめ。もし複雑なことやるなら、SSHでサーバーに入って調べられる。それを手助けするアクションもたくさんある。 最近LLMを色々使ってるけど、一番重要なのは、まさにこういう中途半端な非同期タスクで集中力を維持するメカニズムとして使うことかも。数分でフィードバックが返ってくるようなタスクね。 GitLabを10年使ってた会社で働いてて、ランナーには慣れてたんだ。もっとコメントを表示（1）
マジそれ。
さらに言うと、「デバッガーがあるツール」でロジックを実装しろってこと。YAMLは最悪。シェルスクリプトも二番目に悪い。ちゃんと使える言語使えって。
なんで？セキュリティが重要な場合とか、知的財産が絡む場合はわかるけど。「snowflake runner」とか、ただのコンテナイメージの実行環境のこと言ってる？
self hostedのGitLab runnerだと、インクリメンタルビルドとほぼ同じくらい速かった。ビルドに15～20分かかるような場合（中規模のC++コードベース）、30秒くらいに短縮できた。
でも、CIは「設定」じゃなくて「コーディング」だよね。完全にツール選択ミス。YAMLは無理やり拡張されて、とんでもないキメラになっちゃった。GitLabのYAMLでアンカーとかリファレンスを使い始めたら終わり。結果がどうなるか、ローカルでどう実行するか、デバッグはどうするかって話。
YAMLを完全に避けることはできないけど、本来の使い方を守るべき。
やっと言ってくれた！YAMLが言語としてまあまあでも、みんながやろうとしてることがうまくいかない理由を説明するのに苦労してたんだよね。特に、CIみたいにコマンドを実行する必要があるもの。
＞結果がどうなるか、ローカルでどう実行するか、デバッグはどうするかって話。行かない方がいい。
GitHub actionsみたいなリモートCI runnerは、問題をさらに悪化させる。CIコードをpushして、10分待って、エラーが出て、構文エラーを修正して、pushし直すっていうサイクルがマジで時間の無駄。
設定ファイルとしてYAML使うのも苦痛。空白（タブvsスペース）問題のせいで台無し。
＞ - name: Run the scripts
＞ run: |
＞ ./my-script.sh
＞ ./my-other-script.sh
これって2つのスクリプトを実行してるんじゃなくて、シェルコマンドで2つのスクリプト呼び出してるだけでしょ。最初のスクリプトが失敗したらどうなるの？ローカルでどうすればいいの？
いや、違うでしょ。パイプラインサービスは共通のアーキテクチャパターン持ってるじゃん。pipeline runはbuild jobで構成されてて、外部イベントでtriggerされて、build jobはcontext持ってて、artifact出力できて、build jobはstageにまとめられてて、stageはdirected graphとして構成されてて、stage間の遷移はルールで決まってて。DSLsに最適じゃん。GitLab CICD見てみ？
いやいや、GitHub Actionsはコンプライアンスにめっちゃ使えるよ。attestation作れるから、artifactの出所とか完全性に関するポリシーを簡単に適用できるし。Jenkinsで同じことやるよりずっと楽だった。何が問題だったの？
それはない。Haskellでも全然使える。依存関係をキャッシュすればビルドも速くなるし。もっとコメントを表示（2）
高いrunnerにお金払っても、Azureの請求にまとめられるから、別のSAASサービスを正当化する必要がない。
問題はGH Actionsじゃなくて、ビルドシステムに余計な機能を詰め込みすぎること。AntとかMavenとかGradleとかも同じ。ビルド＆CIシステムは単純にソフトウェアをビルドするくらいでいいんだよ。条件分岐とかカスタムな副作用とか、月の満ち欠けで挙動が変わるようなのはマジ勘弁。YAML使うならYAMLジェネレーター使うといいよ。Kotlinの使ってるけど、オートコンプリートとか型チェックとかあるから便利。
＞CICD101だって言うじゃん。なんでみんなYAMLとか関係ないことで騒いでるんだろ？
パイプラインを設定して、自分でスクリプト用意して、GitHub Actionが便利なら使う。それだけじゃん。マジで自転車が倒れるミームみたい。run以外のActionがあるの？run以外のActionがあるの？
GitHub Actionsには’run’があるよ。
https://docs.github.com/en/actions/writing-workflows/workflo…
GitHub ActionsはカスタムActionもサポートしてる。カスタムActionを使えば、サードパーティのモジュールをインポートするのと同じように、ハイレベルなActionを作成、共有、再利用できる。
https://docs.github.com/en/actions/sharing-automations/creat…
カスタムGitHub Actionを使っても、steps.runは使えるよ。
そもそも式評価とか条件分岐についてのコメントが意味不明。CICDシステム使ったことあるのかな？みんな自分の無能さを棚に上げて文句ばっか言ってるようにしか見えない。
SaltStackユーザーだけど、YAMLで書くのが難しいと思ったら、カスタムモジュールとかステート書くよ。YAMLはSaltに何をしてほしいか伝えるだけにして、ロジックはPythonファイルに書く。
みんなもっとジェネラリストになるべき。
現状より良くできるはずだ！
もしよかったらFastlane[0]見てみて。
[0] https://github.com/fastlane/fastlane
＞I don’t think there’s some universally perfect solution that magically just works all the time and never needs intervention or updating.”何が問題なのか勘違いしてるみたいだけど、maintenanceが面倒なんじゃなくて、最初のdevelopmentが面倒なの。もっとコメントを表示（3）
(1) https://github.com/actions/upload-artifact/issues/38
個人的なやつだと、Google Cloud Build使ってて、マジでシンプルなフローで済んでるから満足。
https://github.com/nektos/act
もしプロセスが数分以上かかるなら、待ってる間に別のタスクに切り替えられる。でも３～１０分くらいの待ち時間ってマジ耐えられないんだよね。集中力は途切れるし、コンテキストスイッチするほど長くもないし。今は待ってる間、LLMとタスクに関係することについてダベって、集中力を保つようにしてる。
最近GitHubを使ってる会社に移ったんだけど、規模的にGitHubの方がすごいだろうと思ってた。
でも、期待外れだった。比較にならないくらいひどいし、どうしてこうなったのかマジで理解できない。もし会社を経営してて、どっちか選べって言われたら、GitHub Actionsのせいで毎回GitLabを選ぶだろうな。
