はてなブックマーク

GitHub Actions に関して、どこに env が書けるんですか？とか、if ってどうやって使うんですか？とか色々と質問を受けることがあります。 そういった、if と env に関してフォーカスして、こちらの記事で紹介させていただきます。 env まず、env に関してです。 env が使える場所 env の対象範囲は、step 単位です。 env が指定されていると、環境変数として、step 毎に展開されます。 steps: - name: "Say Hello, world!" run: echo "$HELLO, world!" env: HELLO: Hello echo_job: runs-on: ubuntu-latest env: HELLO: Hello steps: - name: "Say Hello, world!" run: echo "$HELLO, wo

最近では多くの開発において、モノレポが採用されているかと思います。 その時、GitHub Actions はトップレベルでしか用意できないため、フロントエンドしか更新していなくてもバックエンドのテストが走ってしまいますが、あまり意味がありません。 むしろ、Organization の quota をなるべく消費したくないはずです。 そこで、関係無い変更が行われたときに、その CI を無視するように設定する方法について、こちらの記事で紹介させていただきます。 paths-filter を使用する paths-filter を使用すると、特定のファイル変更に対して、GitHub Actions の if で使用するための output が提供されます。 こちらをモノレポで使っていくには、以下のように設定していきます。 .github/filters.yml を用意します。 こちらは、YAML

GitHub Teams を活用すると、それぞれのレポジトリに対する権限を一元管理でき、非常に便利です。 しかし、今まで関わってきた会社の中には GitHub Teams が使用されていても、ただのラベル付けのようにしか使用されておらず、権限管理には使用されていないところもありました。 そこで今回は、GitHub Teams を会社として運用するにはどうすれば良いのか、に関して紹介させていただきます。 Organization でのロールに関して まず、Organization でのロールは 2 種類存在します。 Owner と Member のみで、Owner はその Organization に対して何でもできる権限で、Member は、後述する Member privileges や Teams によってできることが変化します。 基本的には、インハウスのエンジニアリーダー数人が Ow

GitHub で共同開発をしている場合、GitHub Actions を使用して継続的なデプロイを行っていることが多いかと思います。 例えば Git タグを使用して、そのタグ作成をフックに自動で Production へデプロイといった運用が考えられます。 ただ、そういった運用は、運用自体が簡単ではあっても、セキュリティに難があります。 業務委託等の社外エンジニアが開発に参加している場合、そのレポジトリに対して Write 以上の権限が必要になります。 すると、Git タグを作成する権限もあるわけで、そうなると、社外メンバーが Production デプロイを勝手に行えてしまいます。 そういったことを防ぐために、Production デプロイ自体に承認機能を付けることができます。 それを、GitHub Actions と GitHub Environments という機能を組み合わせること

GitHub には Code Owners という機能があります。 この機能は、CODEOWNERS ファイルを .github/ ディレクトリ内に置いておくことで、特定のディレクトリやファイルを編集した PR を作成した時に、自動でその編集箇所の Owner に対してレビューリクエストを送信するための機能です。 例えば、以下のようにモノレポ構成時に、frontend と backend それぞれに対して詳しいチームリーダーがいたとすると、それぞれの変更箇所に応じて PR 作成者がレビュアーを探すことなくレビューリクエストを送信できます。 こういった機能は、不特定多数が Contribute する環境である、OSS で役立てられているんじゃないかなと思います。 この程度であれば、そもそもスクラムチームをそこまで大きくしないため、誰にレビューリクエストを出せば良いという情報はキチンと共有され

はじめに スタートアップ等において新しいプロダクトを始める時は、負債が無い代わりに何もありません。 そういった時に、ソフトウェアの品質を担保するための CI のセットアップが、初期から重要になってきます。 GitHub を使用している場合は、GitHub Actions を使用されることが殆どだと思うので、そちらを前提に進めていきたいと思います。 1. rhysd/actionlint 様々なエンジニアが action を追加したり、編集したりするようになった時、全員が正しい書き方で書いていくことは難しいです。 また、それを 1 人の GitHub Actions Expert がレビューしていくのは大変で、属人化してしまっているので、避ける方が望ましいです。 以下をコピペすれば、使用できます。 name: Actionlint on: push: branches: [ main ] p

この記事は、以下のサービスに契約していることを前提にしています。 GitHub Enterprise Cloud Google Workspace 会社単位で GitHub Organization を運用する場合は、権限管理等を含めたセキュリティが非常に重要です。Github Free の Organization でも基本的な権限管理であれば揃っていますが、SAML 等の高度なセキュリティ設定は含まれていません。 そういった Free で可能なメンバーの権限管理に関しては、別の記事にて紹介します。こちらの記事では、Free や Enterprise にて利用可能で、重要な 3 つのセキュリティ設定に関して紹介します。 Two-factor authentication を強制化する (free) Two-factor authentication を組織として強制化していない場合、個人

GitHub での複数人開発において、プルリクエスト毎にレビュー用の環境があれば、コードのみレビューに加えて目視でのレビューが行えます。特に、フロントエンドコードであれば、コード上では確認しきるのが難しい部分も多く、目視でのレビューは非常に大切です。そして、その環境がプルリクエスト毎に別れていれば、レビュー範囲をレビュアーが手動で切り替える、レビューするタイミングで毎回デプロイを切り替える等の作業が必要なくなります。 Firebase Hosting を使用している場合、GitHub Actions と連携することで、Preview Channel を使用して GitHub のプルリクエスト上にプレビューに対するリンクのコメント発行まで行ってくれます。そのため、レビュアーはそのコメントされたリンクをクリックするだけで、その PR 内の変更点のみを含んだ環境を閲覧・レビューできます。 Fir