web-dev-qa-db-ja.com

GitHubアクションとJenkinsなどの他のCIツールの違いは何ですか?

GitHubは次の機能 GitHub Actions を発表しました。

自動ビルドまたはテストのためのJenkinsのようなCIツールの利点に前向きです。GitHubアクションは将来の使用を目的としています。

GitHubにリポジトリーがあり、外部CIツールを使用すると、CIプロセス全体を書き直すことなく、リポジトリーを別のGitリポジトリー・プラットフォーム(またはローカル)に移動できるという大きな利点があります。 GitHubアクションを使用すると、多かれ少なかれGitHubエコシステムに関連付けられます。

native環境ではGitHubのアクションの統合がより流暢になると思いますが、それ以外に他の利点や欠点はありますか?

16
Bennett Dams

私はGitHubアクションを2、3か月間フルタイムで使用しています。

まだ初期段階(2019年6月)ですが、これが私のリストです。

利点:

  1. GitHubアクションは、Dockerの連続実行です。推論とデバッグが非常に簡単です。 コンテナベースのTravisは可能です のビルド環境を再現しますが、より困難です。 GitHubアクションではdocker builddocker runです。
  2. ワークフローの個々のアクションはデフォルトで分離されています。たとえば、コンパイルとテストには、まったく異なるコンピューティング環境を使用できます。 Travis CI(および他の「従来の」CI)は、すべての「ステージ」(〜アクション)を同じコンピューティング環境で実行します。繰り返しになりますが、GitHubアクションの方が推論とデバッグがはるかに簡単です。
  3. main.workflow仕様(HCLのサブセットであり、実際には有向非循環グラフのみ)は オープンソース です。いずれにせよ、Dockerのラッパーはかなり薄いので、プラットフォームのロックインは間違いなく最小限です。
  4. ローカルテスト用の act など、GitHubアクションのオープンソース再実装があります。
  5. 箱から出してすぐに(ある程度制限された)認証を使用して、GitHub APIにアクセスできます。
  6. 人々が行動を共有できる活気のあるコミュニティ(市場?)がある可能性があります。たとえば、私はさまざまなエコシステムのさまざまな人々によって構築されたデプロイアクションを再利用しています。
  7. 有向非循環グラフ(DAG)とmain.workflowsのビジュアルエディターは、特にCI/CDとワークフロー全般をモデル化するための良い方法です。慣れるには少し時間がかかりますが、一般化は十分です。
  8. GitHubアクションは、CIだけでなく、他にも多くのことができます。基本的に、API全体を入力および出力として指先で操作できます。

短所:

GitHubアクション(まだ?)には、現時点(2019年6月)で驚くほど基本的な制限がある場合があります。

  1. ネイティブキャッシュはありません。 imagelayerキャッシング(それは complicated )ですが、それ以外は何もありません。アーティファクトをビルドするには、(AWS、Azureなどを介して)独自のキャッシュをロールバックする必要がありますが、これは多くの作業になる可能性があります。 (あなたは ここでハック設定 を見ることができます。
  2. 驚いたことに、forkからのプルリクエストはサポートされていません。これも少し complicated であり、セキュリティの観点から理解できますが、現在、a)フォークPR(ベース)の受信リポジトリの秘密に対してアクションを実行することはできません。フォークPRのwould-beマージ結果に対して(travisが行うことです)。フォークを含むワークフローでは、GitHubアクションがCI/CDツールとしてほとんど使用できなくなります。
  3. 単一のプラットフォーム、それはdocker内で実行できるものすべてなので、一部のLinuxディストリビューションです。これは変更される可能性は低いようですが、許容できる制限である可能性があります。他のクロスプラットフォームのCI/CDサービスを呼び出すアクションをいつでも追加できます。
  4. ドキュメントはまだかなりまばらです。ベストプラクティスや足場の邪魔にはなりません。
  5. 公開されたGitHubアクション(少なくとも市場では)の品質と幅は、依然としてかなり低く、制限されています。それがうまくいくかどうかを確認します。
  6. アクションを単体テストする優れた方法はありません。 (私は hacked 一緒に何かをしましたが、私はそれについてあまり確信がありません)。
10
maxheld

GitHubにリポジトリーがあり、外部CIツールを使用すると、CIプロセス全体を書き直すことなく、リポジトリーを別のGitリポジトリー・プラットフォーム(またはローカル)に移動できるという大きな利点があります。
GitHubアクションを使用すると、多かれ少なかれGitHubエコシステムに関連付けられます。

はい、2019年11月以降は少し少なくなります。

Joe Bourne のお知らせをご覧ください " GitHubアクションのセルフホストランナーがベータ版になりました 」.

セルフホストランナーを使用できます。つまり、

  • あなたの環境、あなたのツール
  • 任意のサイズのマシンまたは構成
  • 安全なアクセスとネットワーク
  • 大規模なワークロードのサポート

ワークフローでのセルフホストランナーの使用をサポートするために、runs-onキーの使用エクスペリエンスを拡張しました。
セルフホストランナーを登録すると、それぞれにruns-onで使用できる、セルフホストの読み取り専用ラベルが付与されます。
これが例です:

# Use Any available Self-hosted runners connected to repo
runs-on: self-hosted

" Hosting your own runners "にあるドキュメントを参照してください。

1
VonC