社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
GitHub Actions のデバッグをローカルで行う
概要 GitHub Actions で GitHub ホストランナーを使用する場合、パブリックポジトリは無料ですがプライベートリポジトリは従量課金（無料枠あり）です。 ワークフローを編集する際にデバッグしていると結構な時間を消費してしまいます。 そこでデバッグ時は GitHub ホストランナーを使わずに無料で実行する方法を 3 種類紹介します。 nektos/act 言わずと知れたローカル実行ツールです。 すべてを再現することはできませんがコミットを増やさずにデバッグができます。 注意点 ubuntu-* のみサポート ソフトウェアは指定する Docker イメージ依存、デフォルトのイメージだと色々足りないので -P で指定 secrets.GITHUB_TOKEN が未定義なので Personal Access Token を発行し設定が必要 サービスコンテナ services が使えな
レビュワー全員の Approve を必須にする
概要 少し前に Auto-merge 機能が使えるようになりました。 ブランチ保護のルールが満たされたときに自動的にマージしてくれます。 しかしブランチ保護のルールには「レビュー数」は指定できても「全員のレビューが通ったか」は指定できません。 レビューをリクエストされた全員の Approve をマージ条件としたい場合の設定方法です。 GitHub Actions ワークフロー name: Unanimously Approved on: pull_request: types: [ opened, reopened, synchronize, review_requested, review_request_removed ] pull_request_review: types: [ submitted, dismissed ] jobs: unanimously-approved: r
Renovate を使ってほぼ完全自動で依存パッケージをアップデートする
依存パッケージを自動アップデートすることで、プロジェクトに影響を及ぼす可能性があるケースがあります。 一時期話題になった faker.js や color.js の開発者が意図的に改ざんした事件 は記憶に新しいですね。 「自動で処理する」ということのメリットとデメリットを把握して利用しましょう。 環境 Renovate v34.156.0 GitHub Actions Runner v2.302.1 Ubuntu 22.04.2 LTS (ubuntu-latest) Renovate とは renovatebot/renovate - GitHub package.json や pom.xml、composer.json といった依存パッケージを定義しているファイルを読み取り それらのパッケージに新しいバージョンがないかどうかを確認し 新しいバージョンがあれば依存パッケージ定義ファイルを
Check! GitHub Dependabot について知る
背景 Dependabot 自体は、2019 年に GitHub に買収され、現在は GitHub がホストしています。経緯は下記をご参考ください。 Dependabot alerts Dependabot は下記の契機でリポジトリ内の依存関係の検査を行い、脆弱性のある依存関係を検出すると、 Dependabot alert を発行します。依存関係グラフ(dependency graph) がサポートするパッケージが対象です。 GitHub Advisory Database に新しい脆弱性が報告されたとき リポジトリの 依存関係グラフ(dependency graph) に変更があったとき 検出された alerts は、リポジトリの「Security」の「Dependabot alerts」から確認できるほか、admin 権限をもつユーザーに通知されます。 なお、他の権限を持たないユーザ
GitHub ActionsにおけるStep/Job/Workflow設計論
この記事について GitHub Actionsには、以下3つの実行単位が存在します。 Workflow Job Step パイプラインを組む中で出てくる複数個の処理を、1つの実行単位でまとめてしまうか、それとも分割するのかというのは悩むポイントかと思います。 一つのstepのrunフィールドにコマンドを詰め込む？それともstepを分けた方がいい？ 一つのJobの中のstepとして記述した方がいい？それとも別のJobに定義した方がいい？ 一つのWorkflowの中にJobをたくさん定義する？それともWorkflowを別にする？ この記事では、Workflow・Job・Stepそれぞれの性質を踏まえた上で、ベストな処理単位の選び方を考察します。 使用する環境・バージョン GitHub Actions: 2022/5/15時点での機能をもとに考察 読者に要求する前提知識 GitHub Actio
GitHubのプルリクエストの差分はどこと比較しているか？(git diffの".."と"..."の違い) - Qiita
GitHubのプルリクエストの差分はどこと比較しているか？(git diffの".."と"..."の違い)GitGitHub ディップ Advent Calendar 2018 の1日目です。 はじめに チーム開発をしていて、GitHubのプルリクエストでファイル差分を見たときに、 「masterと同じはずなのに差分として表示されている...なぜ？」となった経験はありませんか？ 今回は、そのような事象にぶち当たったことがあるGit/GitHub初心者向けに、 GitHubのプルリクエストの差分の仕様についてまとめてみます。 また、その説明のためにGitのdiffコマンドのダブルドットとトリプルドットの違いについても確認します。 まずは、git diffについて git diffとは？ git diffは、コミット<->コミットやインデックス<->ワークツリーなどの差分を表示するコマンドです
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
Pythonで作ったコマンドをGitHub経由でpipインストール可能にする | DevelopersIO
こんにちは、ターミナル住人の平野です。 先日Pythonで作ったコマンドを公開する際、 Pythonなんだし、やっぱりpipでインストールできるようにしたいなと思い、 そのやり方を調べたので記録しておきます。 CSV変形のお供に。テキストの一部分にだけコマンド適用するツールを作ってみた。 GitHubでの公開 pipを使うと通常はPyPIからパッケージを探そうとしますが、 探しに行く先としてGitHubを指定することもできるようです。 いくらPyPIが誰でもパッケージを登録できるリポジトリとは言え、 いきなりここに登録するのは心理的なハードル高すぎなので、 まずはGitHubでの公開だけに留めておきます。 スタート地点 スタート地点としては、sample_command.pyというファイルが一つあるだけの状態です。 このファイルは、コマンドsample_commandと実行する代わりに p
Github Actionsでのdocker buildでキャッシュを有効にする
以下を実現するGithub Actionsを作る方法を紹介する。 Dockerイメージのビルドには BuildKit を使う Github Actionsのもつキャッシュの仕組みを有効にする DockerイメージのタグにはYYYYMM-(コミットハッシュの頭7桁)のように、コミットごとにユニークになる値を使う mainブランチをビルドする際には、latestタグも付与する このBuildKitとGithub Actionsのキャッシュを組み合わせる方法は、Dockerの公式ドキュメントに、Optimizing the workflow として掲載されている。 これに自分のアレンジを加えた方法として紹介する。 まず、BuildKitを有効にするには、以下のdocker/setup-buildx-action@v1を先に組み込む。 - name: Set up Docker Buildx id
GitHub リリースページのドラフトを自動生成してくれる Release Drafter を導入する - kondoumh のブログ
リリースページに ChangeLog というかリリースノートを書くのはかなり面倒です。 Release Drafter を使うと PR 単位でいい感じに リリースページのドラフトを生成してくれます。 Release Drafter の GitHub App は簡単に導入できますが、何やら Deprecated にしようという議論があるようです。 GitHub Apps - Release Drafter · GitHub github.com GitHub Actions で release-drafter 用のワークフローを使う方が無難かなと思います。 github.com README にある通り、設定用の release-drafter.yml とワークフロー用の release-drafter.yml をそれぞれリポジトリの .github と .github/workflows
GitHubのREADMEをサクッと高品質で書けるサービス作ってみました。 - Qiita
みなさんは GitHub でオープソースソフトウェア(OSS)を開発して公開する時、README をどのように書いているでしょうか？ GitHub が自動で作ってくれる README に含まれるのはタイトルだけですし、OSS 開発初心者の場合、そもそも README に何を含めるべきかわからないという方もいらっしゃるのではないでしょうか？OSS 開発に慣れている方でも、コードを書くのはいいけれど README を書くのは面倒だと思ったことはありませんか？今回はそんな README 難民の方々向けの Web サービスを作ってみました。 LEADYOU - README Generator Web サイトへ 使い方 使い方は簡単です。トップページで GitHub の Public リポジトリの URL を入力してNext Stepボタンを押すと、README に書くべき内容ごとにフィールドが設
GitHub Actionsで使えるactionを自分で作る - Masteries
先日, papix/action-cache-s3という, GitHub Actionsのactionを作ったというエントリを書きました. papix.hatenablog.com このエントリでは, このactionを作るにあたって得た知見について, 雑に記しておきます. actionの雛形 折角なので, TypeScriptでactionを書いてみようと思った訳ですが, 何と公式からTypeScript用の雛形が提供されています. 余程の理由がなければこれを使うと良いでしょう. github.com ...今回, これを使うにあたって初めて知ったのですが, ｢Use this template｣なるボタン(機能)が存在していて, これをクリックするとそのリポジトリを雛形にして新しいリポジトリをシュッと作ることができるのですね. というわけで, ボタンを押すと... こういう感じでリポジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub CLIで始める快適GitHub生活 - Qiita