はてなブックマーク

lock 機構を実現するための GitHub Action を作ったので紹介します。 背景 lock 機構によって複数のプロセスが同時に実行されるのを防ぐことが出来ます。 例えば GitHub Flow で Pull Request (以下 PR) をマージしたらデプロイを実行する場合に、デプロイ直前に lock を取り完了後に unlock することで、デプロイ中に他の PR がマージされてデプロイが複数同時に実行されるようなことを防ぐことが出来ます。 また、 Terraform で State の分割作業を行う際に、作業前に lock を取り完了後に unlock することで作業中に terraform plan, apply が実行されるのを防ぐことが出来ます。 今回は GitHub Actions で簡単に lock 機構を実現するための Action を開発しました。 特徴 今回

昨日自分の OSS の issue や pull request (以下 PR) を 1 つの GitHub Project に自動で集約して管理するようにしたお話を紹介しました。 昨日導入したばかりですが、今のところかなり良い感じに機能しています。 これを個人の OSS 開発だけに閉じるのはもったいなく、業務でも活用できるはずだと思いました。 今回の記事はその続きで、個人の OSS ではなく業務における開発組織の issue や PR を自動で GitHub Project に追加するようにするお話を紹介します。 やることは前回の記事とほぼ同じですが、皆さんが業務で活用するのをイメージしやすいように具体例を交えながらお話したいと思います。 最初は前回の記事に追記しようかと思いましたが、せっかく追記しても前回の記事のタイトル的に OSS を開発していない人には読んでもらえない可能性がある気

2024-07-24 追記: 本記事の続きで、開発組織でのソフトウェア開発の Issue や PR を自動で適切な GitHub Project に割り当てていく方法についても書きました。 https://zenn.dev/shunsuke_suzuki/articles/manage-enterprise-issue-pr-by-project タイトルの通り、自分が管理する全 OSS の Issue や Pull Request (以下 PR) を 1 つの GitHub Project に集約した話を紹介します。 自分は様々な OSS をメンテしており、様々なリポジトリで作られる GitHub Issues や PR を日々ハンドリングする必要があります。 しかしこれだけリポジトリの数が増えると一つ一つリポジトリを巡回してハンドリングしていくのは困難です。 ユーザーによって issu

GitHub Actions の timeout-minutes に関する lint rule 及び一括で timeout-minutes を設定するツールを作ったので紹介します。 timeout-minutes とは timeout-minutes は GitHub Actions の job 及び step (workflow は対応していないはず) の設定項目の一つで、 job 及び step のタイムアウトです。 timeout-minutes で設定した時間以内に job 及び step が完了しない場合に強制的に終了し失敗扱いになります。 デフォルトは 360 分です。 ただし、 reusable workflow を使っている job は timeout-minutes をサポートしていません。 なぜ timeout-minutes を設定すべきなのか デフォルトの 6 時間

Octo STS は GitHub Access Token をよりセキュアに発行する Security Token Service です。 GitHub App と GitHub Action が公開されています。 CI などの自動化で用いる GitHub Access Token の管理を改善することが出来ます。 Octo STS はまだ非常に若いプロジェクトなため実用には時期尚早かもしれませんが、今後の発展が楽しみなプロジェクトです。 公式ドキュメントがまだ整備されておらず、日本語情報も皆無なため、この本を執筆しました。 この本では Octo STS とは何か、なぜ Octo STS が必要なのか、現状 Octo STS にどういった課題があるのか、どうやって使うのか、どのような仕組みで動いているのか、などについて紹介します。

先日 DeNA 主催の CI/CD Test Night #7 というイベントで登壇しました。 自分は普段あまり登壇とかはせずに主に OSS の開発やブログの執筆という形でアウトプットをすることが多いのですが、自分がメンテしている OSS などでいつもお世話になっている @ponkio_o さんからお声がけいただき、登壇することとなりました。 貴重な機会をいただきありがとうございました。 本記事では自分の発表について紹介したいと思います。 自分は主に CI/CD のセキュリティ的なプラクティスや関連するツールの紹介をしました。 一つのことを掘り下げるというより、色々なトピックについて話をしました。 自分の発表の多くは自分が過去に書いたブログ記事に基づいています。 ブログ記事ではより詳しく解説していたりするので、是非そちらも参照してください。 Pull Request の CI の結果を P

危険な Terraform Provider の実行を防いで Security を担保するためのコマンドラインツールを作ったので紹介します。 # Only google provider and azurerm provider are allowed $ cat .tfprovidercheck.yaml providers: - name: registry.terraform.io/hashicorp/google version: ">= 4.0.0" - name: registry.terraform.io/hashicorp/azurerm # tfprovidercheck fails because aws provider is disallowed $ terraform version -json | tfprovidercheck FATA[0000] tfpro

本記事では GitHub Actions で pull_request event の代わりに pull_request_target を用い、 workflow の改竄を防いでより安全に CI を実行する方法について紹介します。 まずは前置きとして背景や解決したいセキュリティ的な課題について説明した後、 pull_request_target を用いた安全な CI の実行について紹介します。 本記事では OSS 開発とは違い業務で private repository を用いて複数人で開発を行うことを前提にします。 長いので要約 GitHub Actions で Workflow の改竄を防ぎたい GitHub の branch protection rule や codeowner, OIDC だけでは不十分なケースもある pull_request event の代わりに pull_r

tfaction という、 GitHub Actions で Terraform Workflow を構築するための Action を開発しています。 今回 tfaction が Terraform の Drift Detection をサポートしたので紹介します。 詳細に関しては公式ドキュメントを参照してください。 Drift Detection とは ここでいう Drift とは、 IaC においてコードによるインフラの定義と実際のインフラの状態が乖離していることを指し、 Drift Detection とはその Drift を検出することを指しています。 Terraform に限らず、 IaC において Drift Detection は重要なトピックです。 Drift が常態化しているとコードの信頼性がなくなります。 なにか変更を加える際にその変更と関係な差分が検出され、その変更が

本記事は Renovate の Pull Request を安全に自動マージするためのガイドです。 以下のドキュメントが元になっています。 この記事は一度書いたら後はメンテしませんが元のドキュメントはメンテしていくので、元のドキュメントも参照してください。 Renovate の導入は非常に簡単ですが、単に GitHub App をインストールしただけではその真価は発揮されません。 この記事では安全かつ自動で Renovate の Pull Request をマージし dependencies を常に最新に保つためのテクニックを紹介します。 この記事では CI に GitHub Actions を使うことを前提とします。また、 Renovate とは直接関係ない内容も含みます。 1. 概要 ある dependency を update する場合、その update に関連した test が

GitHub Actions の Workflow や Workflow 用のスクリプトの変更を防いでセキュリティを改善するための OSS を開発しているので紹介します。 背景 GitHub Actions は非常に便利ですが、 Workflow を書き換えて任意のコマンドを実行できるという、セキュリティ的なリスクがあります。 例えば GitHub Actions で Terraform を実行して AWS や GCP の IaC を実現している場合、 Workflow を書き換えて terraform destroy を実行して インフラを破壊するといったことが考えられます。 GitHub App が使われている場合、 Workflow を書き換えて GitHub App で悪意のある Pull Request を approve したり、はたまた GitHub App で Pull R

tfaction という、 GitHub Actions で良い感じの Terraform Workflow を構築するための Action を開発しています。 今回は tfaction の導入ガイドのようなものを書こうかと思います。 AWS Account が必要です。 執筆時点で tfaction の最新バージョンは v0.4.5 です。 2022-02-07 追記 Getting Started を作成しました。 README に従っていけば tfaction の workflow を動かして terraform を実行するのを体験できると思います。 IAM OpenID Connect provider の作成 IAM OpenID Connect provider を作成します。 data "tls_certificate" "github" { url = "https://t

tfaction という、 GitHub Actions で良い感じの Terraform Workflow を構築するための Action を開発しているので紹介します。 まだ開発中という感じで未成熟(個人の AWS, GCP アカウントを使って検証しているくらい)ですが、既にそれなりに動くはずです。 tfaction とは GitHub Actions で良い感じの Terraform Workflow を構築するための Action です。 単一の Action ではなく、複数の Action で構成されています。 ここで言う Terraform Workflow とは、 terraform plan や apply を実行する一連の流れのことを指しています。 この Workflow に求める要件は組織・チームによっても異なるでしょう。 そもそも apply の自動実行は危険だから手

e.g. github-comment で Envoy Proxy の設定の validation に失敗したら通知 github-comment というツールを使って GitHub の Pull Request (以下 PR) にコメントをして CI の結果を分かりやすくする方法について紹介します。 執筆時点で最新バージョンは v4.1.0 です。 github-comment とは github-comment は GitHub の commit, issue, PR にコメントをしたり、コメントを非表示にする CLI ツールです。 YAML の設定ファイルにコメントのテンプレートなどを記述し、それを元にコメントします。 シェルスクリプトとコメントのテンプレートを分離できるので、メンテナンス性が高いです。 3 つのサブコマンドがあります。 post: コメントをする exec: 指定し

Terraform の CI/CD を改善する tfcmt というツールを紹介します。 ちなみに HashiTalks JP 2021 でも紹介しています。 執筆時点で最新バージョンは以下のとおりです。 tfcmt: v3.0.0 github-comment: v4.0.1 tfnotify: v0.7.0 tfcmt は terraform plan, apply の結果を GitHub の Pull Request (以下 PR) にコメントとして通知する CLI ツールです。 態々 CI のログを見にいかなくても PR のページで結果を確認でき、 なおかつ素のログに比べて非常に分かりやすいのが特徴です。 tfnotify の Fork ですが、互換性はありません。 自分にとって不要な機能(主に GitHub 以外への通知)を削る代わりに、様々な改善を入れています。 GitHub 以

2022-10-07 追記 aqua v1.15.0 からは aqua g の -s option でバージョンを選択できるようになりました。 CLI ツールを YAML でバージョン管理できるツール aqua を開発しています。 aqua で CLI ツールを YAML でバージョン管理 も参照してください。 似たようなユースケースで使われる有名なツールとして asdf があります。 そこで、 aqua と asdf の違いについて書きたいと思います。 ちなみに aqua と asdf のバージョンは以下のとおりです。 asdf: v0.9.0 aqua: v0.8.2 aqua-registry: v0.11.0 ただし、自分は asdf にはあまり詳しくありません。 最近 aqua と比較するためにちょっと触っているくらいです。 また、自分は aqua の開発者であるため、どうしても

CLI ツールを YAML でバージョン管理できるツール aqua を開発しています。 先日(2021-11-27)、公式サイトを公開しました。 詳細は公式サイトをご参照ください。 この記事にコマンドやその実行結果、設定ファイルのサンプルなどを書いてもメンテが難しいため、 ここでは時間が経っても変わりにくい内容を書こうかと思います。 この記事の執筆時点で最新バージョンは v0.8.0 (Standard Registry は v0.10.13) です。 aqua は CLI ツールをインストールする CLI ツールです。 Go で書かれたシングルバイナリなので、簡単にインストールできます。 CLI ツールのインストールでいうと、 Homebrew などでインストールすることが多いかと思いますが、 aqua はインストールする CLI とそのバージョンを YAML で宣言的に定義するのが特徴