newmoではGitHub Actionsを自動テスト、Lint、デプロイなどに利用しています。 また、newmoではmonorepoで開発しているため、1つのリポジトリに複数のチーム/複数のアプリケーションが存在しています。 GitHub Actionsではpathsを使うことで、特定のファイルが変更された場合のみ特定のWorkflowが実行できます。 newmoのmonorepoのworkflowでは基本的にpathsが指定されていますが、それでも普段は触らないファイルを変更して意図せずにCIが落ちることがあります。 GitHub ActionsのCIが落ちたときに、そのCIの仕組みを作った人やチーム以外だと何をすべきかわからないことがあります。 この問題の解決するを手助けするシンプルな仕組みとして、GitHub ActionsにCIが落ちたときに何をするべきかを表示するPlayboo
はじめに GitHub Actionsを使ってCI/CD環境を構築します。 今回の目標はFirebaseにGatsbyで作った静的なWebサイトを自動的にビルド、デプロイする環境の構築です。 GitHub Actionsとは GitHubのリポジトリにCI(継続的インテグレーション)とCD(継続的デプロイメント)の機能を直接作ることができる機能。 CIについては公式ドキュメントで丁寧に解説されています。 継続的インテグレーションについて GitHub Actionsのことば では早速CI/CD環境を構築していきたいのですが、私はCI/CDツールに関するリテラシーがまだまだ低いので、GitHub Actionsで登場する概念を学びつつ進めましょう。 ワークフローとは GitHub Actionsで言うワークフローとは、任意のプロジェクトをビルドしたり、テストしたり、デプロイしたり…という様々
TLDR 開発体験が良くなると CI のコストも減る 不必要なジョブ実行を減らし、割れ窓を直すことから始めると良い Self-hosted runners ではクラウドコスト最適化の一般的なプラクティスも併用する GitHub Actions のコスト構造 GitHub-hosted runners GitHub が提供するインフラを利用する。一般的なクラウドより高めの料金設定になっている 1分単位で課金される。ジョブの実行時間が数秒間でも1分間で課金されるので注意 Public repository は無料、Private repository は従量課金になっている Organization 内で利用料金が合算されて翌月請求される。Organization Owner なら請求レポート (CSV) をダウンロードできる Self-hosted runners GitHub では課金され
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
経緯 手動でサーバーに向けてHugoで書いた記事のデプロイをするのがめんどくさい。 手元に同一の記事データやテーマファイルがないと色々厳しいため、GithubでHugoのコンテンツをまるっと管理する形にした。 調べてみるとこのようなスタイルでコンテンツを管理している人が結構多く、同時にHugoからの記事のデプロイもGithub Actionsを利用しているケースが散見されたため、自分もGithub Actionsに入門することにした。 どうやったか Github Actions側のマシンでHugoのコンテンツをビルドしたものをVPSへとrsyncで同期させている。 ビルドしたコンテンツはGithub Pagesとかにデプロイしている人は多いけど、自前のサーバーにデプロイする例がほとんどなかったので以下にWorkflowを書いておく。 Workflowサンプルコード name: Deploy
こういうのを作りました。 ジョブに紐付いたPull Requestへのリンクが表示される 行ったこと: リンクを生成するジョブを1つ生やした 綺麗な表示はStep Summary機能 (後述) の力を借りている ジョブ実行画面からPull-Reqに戻りたい GitHub Actionsのジョブ実行画面には、その実行元となったPull Requestへのリンクが存在しないため、困っていた。 よくあるシチュエーション: Pull Requestを見るとジョブがコケていた 様子を見に行くうちに履歴がどんどん深くなる -- ジョブ画面内での遷移はどんどんヒストリが積まれる Pull Requestに戻れなくなってしまう この話を同僚にしたところ共感の嵐だった。したがって隠れた需要がありそうだということが判明し、うまくやる方法を考えることにした。 結果、GitHub Action上でPull-Req
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く