はてなブックマーク

Prologue こんにちは、@dz_ こと、岩永かづみです。 GitHubリポジトリのBranch protection rulesは、指定したブランチを保護するためのルールを設定できる機能です。 たとえば、以下のような条件を設けられます。 force pushを禁止する ブランチの削除を禁止する 直接のマージを禁止し、プルリクエストを必須にする プルリクエストをマージする際に、承認（approval）を必須にする、など ここでは、それぞれの機能を簡単に確認できるようにまとめます。 Branch protection rulesの一覧 Branch protection rulesは、個人アカウント配下のリポジトリと、Organization配下のリポジトリで一部の項目が異なります。表にまとめました。 Protect matching branches パターンに一致するブランチを保護す

Prologue こんにちは、@dz_ こと、岩永かづみです。 最近、GitHub Actions の "Reusable workflow" 再利用可能なワークフローについて質問されることが多いので、ポイントをまとめてみます。 どういうときに再利用可能なワークフローを使えばいいのか？という疑問に、私なりのベストプラクティを後半に記載したので悩まれている方はご参考ください💡 GitHub Actions でワークフローから呼び出せるワークフローを作成できる まずは、「ワークフローの再利用」についておさらいです。 どういうことかというと、他のワークフローから呼び出すことができるワークフローを作成することができます。 ドキュメントでは、呼ばれる側のワークフローは「再利用可能なワークフロー」（reusable workflow）、呼ぶ側のワークフローは「スターター ワークフロー」（starte

GitHub Actions ワークフローで、Azure/login アクションでログインする さいごに、GitHub Actions ワークフローで Azure にログインする処理を記述します。 Azure へのログインは azure/login アクションを利用できます。下記のように、client-id, tenant-id, subscription-id を指定します。詳細については、下記をご参考ください。 Azure/login: Connect to Azure jobs: login: runs-on: ubuntu-latest # この例では、エンティティ型で environment を指定したので、 # environment の名前がサブジェクト識別子に指定した文字列と一致する必要がある environment: name: staging permissions:

Prologue こんにちは、@dz_ こと、岩永かづみです。 この記事は、Qiita x Code Polaris共催！女性ITエンジニアが作るアドベントカレンダー Advent Calendar 2022 の25日目の投稿です🎄🎁 さて、日々エンジニアをたしなんでいる皆さまは、GitHub がなくてはならない存在になってますよね。「GitHub がダウンしているので仕事は終わり」なんてツイートも見かけます。 直接利用していなくても、利用しているフレームワークやライブラリが GitHub でホストされていたり、利用しているソフトウェアの配布に GitHub が利用されているようなケースもあるでしょう。 そんな GitHub は今や単なる開発のための「Git のリポジトリ」だけに留まらず、コラボレーションのための機能が日に日に拡充されています。機能は多岐にわたり、リリースの速度は目を見

Prologue こんにちは、@dz_ こと、岩永かづみです。 GitHub Codespaces がいよいよ一般公開されました！推しの機能がやっと皆さんに利用してもらえるようになり、感無量です😊 これまで、GitHub Codespaces は GitHub Teams または Enterprise Cloud で先行利用が開始されていましたが、使い勝手がわからないと組織ではなかなか導入しにくい部分もあったかと思います。一般公開されたこれからは、その便利さに多くの人が納得し活用が進むことでしょう💡 私がどれくらい GitHub Codespaces を推しているかについては、こちらの記事をご参照ください✨ なお、上記の記事はベータリリース時点のものなので、本記事では一般公開された現時点の違いや注目点についてご紹介していきます！ 所属していないリポジトリでも起動できるようになった！ こ

背景 Dependabot 自体は、2019 年に GitHub に買収され、現在は GitHub がホストしています。経緯は下記をご参考ください。 Dependabot alerts Dependabot は下記の契機でリポジトリ内の依存関係の検査を行い、脆弱性のある依存関係を検出すると、 Dependabot alert を発行します。依存関係グラフ(dependency graph) がサポートするパッケージが対象です。 GitHub Advisory Database に新しい脆弱性が報告されたとき リポジトリの 依存関係グラフ(dependency graph) に変更があったとき 検出された alerts は、リポジトリの「Security」の「Dependabot alerts」から確認できるほか、admin 権限をもつユーザーに通知されます。 なお、他の権限を持たないユーザ

Check! GitHub auto-merge は "プルリクエストのブロックが解消されたとき" に自動でマージさせる機能 Prologue こんにちは、 @dz_ こと、大平かづみです。 GitHub には "auto-merge" という、プルリクエストの条件が満たされれば自動的にマージしてくれる機能があります。GitHub のリポジトリの設定にある Allow auto-merge を有効にすると、利用を許可することができます。 GitHub リポジトリ設定の Allow auto-merge 設定の項目 といっても、どんな条件の場合に利用できるのか？ 設定から利用を許可してもよくわからなかったので、本腰を入れて実際に確認してみました🤓 auto-merge の利用シーン auto-merge は、前述のようにリポジトリの設定で Allow auto-merge を有効にするだけ

Prologue こんにちは、 @dz_ こと、大平かづみです。 この記事は、 Code Polaris アドベントカレンダー 25日目の記事です🎉 先日の 第34回 Tokyo Jazug Night (Online) の LT でお話しした GitHub Codespaces (Visual Studio Code Dev container) による環境構築をもう少し詳しく説明します🤓 LT が気になる方は資料と YouTube アーカイブをお楽しみください♪ YouTubeのvideoIDが不正です GitHub Codespaces とは GitHub Codespaces が、GitHub が Visual Studio Code の環境をホストして提供してくれるサービスです。 実態は Visual Studio Code の Remote-Container の仕組みがベ

Prologue こんにちは、 @dz_ こと、大平かづみです。 今回はこのブログ記事 "5 automations every developer should be running" が気になったので、ちゃんと読むついでに要約してみました。（ブログ駆動） なお、英語の能力は高くないので、誤訳などありましたらご連絡いただけたらうれしいです🙇🏻‍♀️ 要約: "5 automations every developer should be running" TL;DR: セキュリティ脆弱性との闘いや動かないボタン、遅いサイト、リリースノートを手書きすることを避けたいエンジニアの君に捧ぐ テストを書くことや改善のための自動化を行うことは大事ではあるが、実際のところもっとコードを書いた方が楽しい！ さいわいなことに、GitHub Actions ではたくさんのコミュニティで作られたテストや

Prologue こんにちは、 @dz_ こと、大平かづみです。 何かと気になる、監査ログ。 GitHub で扱える監査ログの種類、閲覧と検索方法、外部連携などをまとめました。 GitHub の監査ログ 概要 Organization において、監査ログ（audit log）を閲覧、検索、エクスポートすることができる Enterprise (Cloud, Server) でのみ利用可能な機能もある ユーザーアカウントには、 audit log はなく、security log がある 参考: セキュリティログをレビューする - GitHub Docs Organization での監査 Organization の管理者は、Organization のメンバーによる操作（アクション）を閲覧、検索、エクスポートすることができます。 監視ログの保存期限は、過去 90 日以内 アクセスできるのは

フロントエンド + API のシンプル構成 フロントエンドとバックエンド（API）の実装を分ければ分業しやすい API での実装は、ビジネスロジックに専念しやすい フルスタックのフレームワークを使わず軽量な実装も選択できる インタラクティブな UI は API と相性が良い コストを抑えやすい スケールしやすい UIの刷新やクライアントのバリエーションを展開しやすい いつのころからか、この構成以外に考えられなくなりました😳 FaaSの充実と、フロントエンドのフレームワークの充実。これらの２点により、柔軟でスケールしやすい フロントエンド + API の構成が普及してきているように思います。 コストを抑えやすい フロントエンドとして扱う静的サイトのホスティングは、動的サイトのそれに比べて安価に済ませやすいです。 静的サイトのホスティングサービスは、 Netlify や Vercel などの

Prologue GitHub アクションで、「ワークフローが終わったら/リクエストされたら、実行する」というトリガをご紹介します。 私の例では、このようなニーズに対して対応することができました。 first-workflow.yml: pull_request や push: [main] などのトリガでテストを行うワークフロー実行 second-workflow.yml: main ブランチへ push されたときにだけ、デプロイするための別のワークフローを実行 指定したワークフローを契機に実行されるトリガ workflow_run on.workflow_run は、ワークフローがリクエストされた、または実行完了した契機で呼び出されるトリガです。 workflow_run | Events that trigger workflows - GitHub Docs イベントタイプは c

Prologue GitHub アクションをちょっとずつ試しています。今回は GitHub Script をご紹介します。 GitHub Actions で標準で用意されている Functions は最低限過ぎてできることが少ないので、ちょっとした文字列の加工なんかは JavaScript が使えると便利です。 そこで利用できるのが GitHub Script です。 GitHub Script GitHub Script は、スクリプト処理として JavasScript を利用できます。 スクリプトの中では、下記が利用できます。 github インスタンス: 認証済みの octokit/core.js クライアントで、REST API のエンドポイントの利用と、pagination プラグインを利用できる contextオブジェクト: github.event などを含むコンテキスト c