July 6, 2020 You can now create workflows that are manually triggered with the new workflow_dispatch event. You will then see a ‘Run workflow’ button on the Actions tab, enabling you to easily trigger a run. You can choose which branch the workflow is run on. In addition, you can optionally specify inputs, which GitHub will present as form elements in the UI. Workflow dispatch inputs are specified
GitHub Actions Self-hosted Runner の導入と安定運用に向けた軌跡 - スタディサプリ Product Team Blog
こんにちは。SRE の @int128 です。 Quipper では GitHub Actions Self-hosted Runner を一部のジョブで導入しています。本稿ではその目的と具体例を紹介します。 背景と解決したい課題 Quipper では以下の CI サービスを用途に合わせて利用しています。 CircleCI（テストやデプロイなど） GitHub Actions（テストやデプロイなど） AWS CodeBuild（主に Terraform など AWS リソースにアクセスする場合） Google Cloud Build（主に Google Cloud のリソースにアクセスする場合） Jenkins（定期実行や手動実行に特化したジョブ） このうち GitHub Actions は以下の点が優れていると感じています。 monorepo 構成の場合にマイクロサービスごとに独立して
インフラのリリース自動化戦略とその行き着く先 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、@ueokandeです。 本番リリースってドキドキしますよね。 本日はkintone.comのリリース自動化と、その戦略についてお話します。 kintone.comのCI/CDパイプライン kintone.comのインフラ構成はモノレポで管理しており、AWSの構成や、Kubernetes上にデプロイするサービスなどが1つのレポジトリに存在します。 現在のkintone.comは、開発環境、ステージング環境、本番環境の3つがあります。 適用タイミングをずらすことによる環境間の乖離を防ぐため、各リリースはすべての環境に適用することとしました。 開発環境でしばらく寝かせたい変更は、機能フラグやカナリアによって切り替えます。 CI/CDパイプラインは以下のようになっています。 それぞれの環境に順に適用し、本番環境適用後にテストが通れば無事リリース完了です。 kintone.comのCI
はじめに Github Actionsで色々なフローの自動化に取り組んで一番大変だと感じているのは、目的とするデータをコンテキストのどこから取れるのか見つけるところです。 公式ドキュメントも正直目的の情報に辿り着きやすいとも言えず、StackOverFlow等のFAQフォーラムも類似した質問が多くありすぎて逆に絞るのが大変となる繰り返しでした。 私自身で頻繁に用いそうなものを中心に、調査の手間を省くために備忘録として書き出してみました。2020年5月26時点のデータとなります。 各コンテキストについて 利用可能なコンテキストは以下の8つです。公式ドキュメントが個人的にやや見難いため、必要なところだけを抜粋しました。 github workflowの情報にアクセスする用途 env workflow、job、stepの環境変数にアクセスする用途 job jobの情報にアクセスする用途 step
CircleCI上のRSpecによるテスト実行時間を25min -> 12minに短縮する技術 - ANDPAD Tech Blog
株式会社アンドパッドのアカウント基盤チームでテックリードをしているid:shiba_yu36です。 最近自分のサイドプロジェクトとして、生産性を向上するために、CI実行時間の短縮化を行っていました。その結果、とくに時間のかかっていたCircleCI上のRSpecによるテスト実行時間を、25min -> 12minに改善できました。そこで今回はどのような流れでCIの実行時間を改善していったかについて、具体的に書いてみたいと思います。実行時間改善の勘所について参考になれば幸いです。 改善の流れ: CircleCIでボトルネック調査し、大きいボトルネックを解消する 実行速度改善の前に: Flakyなテストを一斉に直す 速度改善1: bundle installのキャッシュがうまく効いていなかった問題を修正 -> 4minの短縮 速度改善2: developブランチ以外ではカバレッジを取らないよう
Github actions はとても便利だ。テストやビルドを自動化するのに活用している。 パブリックリポジトリだと無料で実行環境が利用できるのがありがたい。 その無料の実行環境 Github-hosted runner では重すぎる処理を実行したくて Github actions の Self-hosted runner 環境を作った話は前回のエントリで書いた。 hero.hatenablog.jp 環境構築の動機となった目的は果たしたものの、作った環境はコスト性能比的にも良い選択だったのだろうか？ と思ってちょっと調べてみた。 今回はそれについて記す。 レイヤ数の多い大きな Docker イメージのビルドをギリギリ Github-hosted runner で実行していたのだけど、マルチアーキテクチャビルドをしようとして遂に処理できなくなった。仕方がないので、Self-hosted r
出ない神本より出るクソ本 〜『読みやすい技術書を書く技術』の第1章と頒布情報〜 #技術書典 - 憂鬱な世界にネコパンチ！
『読みやすい技術書を書く技術』は、読みやすい文章を書くための「校正環境」を構築する本です。この本では、CircleCIを使って継続的に文章を校正する仕組みを整えます。技術書のような長い文章を書く人には、特に有益です。技術書典7で頒布予定なので、ぜひチェックいただければ幸いです。 techbookfest.org CIで校正チェックすることに興味はあるけど、そこまで手が回らないんだよな〜と思っている人いませんか。この本はあなたのために書きました。この本を読めば誰でも、CircleCIで最高の校正環境が構築できます。 この本を読むことで学べること 『読みやすい技術書を書く技術』では、次のようなことを習得できます。 校正ツール「prh」「RedPen」「textlint」の使い方 「CircleCI」の基礎知識と校正ツールの組み込み方 「reviewdog」による校正チェック結果のGitHubへ
ノーコードAI開発ツールNode-AIの紹介 - NTT Communications Engineers' Blog
はじめに 初めまして！イノベーションセンターでノーコードAI開発ツール「Node-AI」のプロダクトオーナーやXAI・因果分析の研究をしております、切通恵介（@kirikei）です。 Node-AIは2021年10月11日にリリースされたNTT Communicationsの内製開発サービスで、その名の通りブラウザ上からノーコードでAIモデルを開発できるサービスで、製造業のお客様を中心に異常検知やプラント運転支援などの様々な領域で活用されています。（ニュースリリースはこちらやこちらやこちら） いつもはサービスの営業的な紹介をすることが多いのですが、今回はEngineer's Blogでの執筆ということで、エンジニアの方向けの技術、プロダクトマネジメント、チームビルディング、スクラムなどの様々な観点でお伝えできればと考えています。とはいえ、Node-AIに関しては詳細に書きたいことが山ほどあ
CircleCI セキュリティアラート: CircleCI 内に保存されているシークレットのローテーションをお願いいたします[1月13日更新]
CircleCI セキュリティアラート: CircleCI 内に保存されているシークレットのローテーションをお願いいたします[1月13日更新] セキュリティアップデート 2023年1月12日 00:30 UTC（日本時間1月12日午前9時30分） 当社はAWSと提携し、このセキュリティインシデントに関連してAWSトークンが影響を受けた可能性のある、すべてのお客様に通知をいたしました。本日AWSは、影響を受けた可能性のあるトークンのリストをメールにてお客様へ配信を開始いたしました。メールの件名は、[Action Required] CircleCI Security Alert to Rotate Access Keys（ [要対応] CircleCIセキュリティアラート - アクセスキーをローテーションしてください）です。 AWSと連携したことにより、お客様はより簡単に影響を受けたキーを特
![CircleCI セキュリティアラート: CircleCI 内に保存されているシークレットのローテーションをお願いいたします[1月13日更新]](https://cdn-ak-scissors.b.st-hatena.com/image/square/eeb2a997352474451f2c83908dc207de98aee7c3/height=288;version=1;width=512/https%3A%2F%2Fcircleci.com%2Fblog%2Fmedia%2F2022-12-07-email-background.png)
Docker is happy to announce the GA of our V2 Github Action. We’ve been working with @crazy-max over the last few months along with getting feedback from the wider community on how we can improve our existing Github Action. We have now moved from our single action to a clearer division and advanced set of options that not only allow you to just build & push but also support features like multiple a
GitHub Actions のアクションのつくりかた（JavaScript 編） - 生産性向上ブログ
help.github.com この記事では、新しくなった GitHub Actions における、JavaScript アクション作成方法について解説します。 www.kaizenprogrammer.com GitHub Actions とはなんぞやという人は、先にこちらの過去記事をどうぞ。 目次 アクションについて アクションの保存場所 アクションのバージョニング 簡単な例 (Hello, World) メタデータ JavaScript アクションの使用する Node.js バージョン toolkit node_modules の管理 README.md 公式テンプレート 少し実践的な例 その他 GitHub 公式のアクション サードパーティーのアクション まとめ アクションについて 前回の記事で新しくなった GitHub Actions の使い方について簡単に解説しました。この記事
はじめに 必要に応じて検証環境の追加・削除などの管理をするのが面倒くさいので、PR作成時に検証環境を構築、PRマージ・クローズ時に検証環境を削除ができないか考えてみました。 今回の作成したGitHub Actions ワークフロー、Terraformなどはこちらのリポジトリにあります。 概要図 どのように実現したか 実現あたり、コンテナイメージのプッシュ、ECS サービスのデプロイはGitHub Actions、Terraformの実行はAWS CodeBuildで行うことにしました。 なぜTerraformの実行はCodeBuildを利用するようにしたかというと、CodeBuildはVPC内のリソース（今回の場合はAurora Serverless）にアクセスできるからです。 これによってアプリケーション、DBマイグレーション時に使用するMySQL ユーザーをTerraformで作成する
GitHub - google/wireit: Wireit upgrades your npm/pnpm/yarn scripts to make them smarter and more efficient.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
自作のライブラリのCIをCircleCIからGitHub Actionsへ移行したメモ github.com github.com 特にメリットがあるから乗り換えたとかいうわけでもないけど、GitHubだけで完結するならそれに越したことはない ファイルの場所 .github/workflows/<ワークフローの名前>.yml だが、いまのところ複数作るユースケースが見えないので main.yml とした。 実行環境 ubuntu-latest を選択した。特に理由はないけど一応MacOSやWindowsも選べるっぽい？ Software in virtual environments for GitHub Actions - GitHub Help を見るとわかるが、 めちゃくちゃ充実したプリインのソフトウェアがある。 yarn や Git、Docker、Chromeもなんの設定もなく最初
タイトルの通り。なんとなく自分のサイトを自分で運用したいと思っている。それはWebエンジニアとしてのポートフォリオ的な側面もあるし、それに加えて、自分の書いた文章を自分の管理下におきたい欲求があるのだと思う。 サブブログを、はてなブログに持っていますが(https://blog.song.mu)、これもまた、コンテンツはblogsync を使って管理しています。 このサイトはもともとVPS上のNginxから静的配信されており、 VPS上のgit bareリポジトリに直接push post-receive Hook で riji を呼び出してサイト再構築 という結構カッコいいフローを組んでいて 、これがなかなか気に入っていた。以下のような点が良かった。 国内のVPSへのgitリポジトリへのpushはかなり早い GitHubへのpushに少し引っかかりを感じるレベル とはいえコンマ数秒程度の違
CNDT 2019の登壇資料
こんにちは。MSP技術推進部の手塚（@tzone99）です。 この記事では、エンジニア向けのツールを周囲のエンジニア以外のチームにも導入し、チームを跨いだコミュニケーション上の課題を解決した事例をご紹介します。 普段エンジニアとしてプロダクトを開発する中でも、エンジニア同士のやり取りだけで業務が完結しないケースも多いかと思います。周囲のチームとやり取りする中でコミュニケーションのずれが発生した場合の対応として、今回の事例が参考になれば幸いです。 MSP技術推進部の活動について興味のある方はこちらの記事もぜひご覧ください。 techblog.zozo.com techblog.zozo.com techblog.zozo.com techblog.zozo.com 目次 目次 背景 コミュニケーション上の課題 業務要件のMarkdown/PlantUML化 運用の初期対応 自作のLinter
2020/09/13 追記 「GitHub Actions の規約違反では？」というコメントがありましたが、追記時点の規約では特別禁止されていません。 https://docs.github.com/ja/github/site-policy/github-additional-product-terms#a-actions-usage 唯一グレーラインに相当する可能性のある『サーバーレスコンピューティング』も日本語訳に残っているだけものであり、英語の原文からは既に削除されている項目のため、問題ない利用方法となります。 昔は cron といえば Heroku と Heroku Scheduler だったけれど、Heroku Scheduler が遅延するようになってから、自分用の定刻バッチを楽に動かせる手段がなくてしばらく困っていたり。 しっかりとしたプロジェクトを作成する場合なんかは F
GitHub Actions + google-github-actions/auth で GCP keyless CI/CD
GitHub Actions + google-github-actions/auth で GCP keyless CI/CD 追記 2021/10/08 v0.3.1 にすると aud 周りの設定変更が必要 ソース 追記 2021/10/07 OIDCトークン発行元のURLが変更になったようです ソース 要約： GitHub ActionsでCI/CD的なことやろうとしたとき、SecretsとかにGCPのService AccountのKeyとか置かなくてもデプロイとかできるようになったらしいのでやったらできた。 経緯 AWS federation comes to GitHub Actions という記事が出て。 GitHub ActionsのOIDC id tokenでGCPにアクセスしてみた といってGCPでもやれるか確かめた人が出て。 Use gcloud with creden
October 27, 2021 GitHub Actions now supports OpenID Connect (OIDC) for secure deployments to cloud, which uses short-lived tokens that are automatically rotated for each deployment. This enables: Seamless authentication between Cloud Providers and GitHub without the need for storing any long-lived cloud secrets in GitHub Cloud Admins can rely on the security mechanisms of their cloud provider to e
GitHub Actions を使ってリリース時のあれこれを自動化する 結論 リリース時のタグとリリースノートを自動で生成するようにした リリース時に自分がやることは 動作確認 => Merge pull request を押すだけにした なぜやるのか Release ノートを手動で作るのは面倒 手動でやることには人為的なミスの恐れがある 面倒なことを続けるとモチベーションが低下する(これ重要) 要件 リリース リリースは週に1度行う リリース前に開発した PR をリストで見ながら動作確認をしたい PR のリストがそのままリリースノートに記載されて欲しい 自動化 タグの作成は手動でやりたくない リリースのための PR を手動で作りたくない リリース時のバージョンを手動で入力したくない 自動化の必要性を感じたきっかけ 都内でシステムエンジニアをしている itizawa です。 理想のブックマ
国内最大規模の医療データベースを扱う開発本部が徹底する“守り”と“攻め”のハイブリッド環境 - JMDC TECH BLOG
JMDCのCTO 兼 開発本部長の小森谷です。 今回は、JMDC開発本部の事業内容や技術スタック、開発体制についてお伝えしていきます。特に、技術スタックに関しては、医療分野の特殊なビッグデータを扱っていることから、当社ならではのインフラや開発環境を構築しているのが特徴です。 小森谷 一生（こもりや かずなり）株式会社JMDC CTO 開発本部長 営業・SIerを経験した後、Web系エンジニアへ転向。livedoor社およびGREE社において大規模コンシューマー向けサービスの中で基盤開発から事業KPIの推進など幅広い業務とエンジニアチームのマネジメントに従事。その後、メタップス社にて執行役員としてデータ統合管理や開発組織構築を経験。2018年にJMDCに参画し、2021年より現職。 医療システムの最適化を目指して 1000万人のレセプトデータが最大の強み JMDCは「データとICTの力で、持
PLAIDでは社内のNode.jsパッケージの管理にnpm private registry [https://docs.npmjs.com/creating-and-publishing-private-packages](npmのregistryにprivateでパッケージをpublishする形式)を利用していました。 また、npm private registryを導入する以前の古いパッケー
CLI用のコマンドを作ってみようと思いたったのですが、CLI開発フレームワークoclifを試してみたらとても簡単で環境構築もすんなりできたのでびっくりしたという話。 概要 ある用途で思いたってCLIのコマンド作ろうと思った oclifというCLI用のフレームワークがあったので試してみた 簡単すぎてびっくりした 追加でPrettierとJestも対応してみました 動機 誰しもCLIのコマンドをつくりたくなることがたまにある。僕はある。 今回はGUIを作るまでもなく、コマンドでシュッと実行したい作業があったので勉強と遊びを兼ねてコマンドを作ることにしました。CLIの開発ツールはいろいろありますが、今回はやりたいことを実現するのにすでに知見としてあるものを流用したい背景aからNode.jsでやることにしまた。 Node.jsにもCLI用を作るためのライブラリがさらにいくつかありますが、今回はoc
CircleCI (Performance Plan) vs. Github Actions 結論: CircleCI を買おう 現在ユビレジでは CI は CircleCI (Performance Plan)と TravisCI を使っていて、 CircleCI: サーバーサイド(いろんな言語がある) Web フロントエンド(Rails アプリのなかで webpack が動いていたり、 create-react-app で作られたペラっとしたものがあったりいろいろある) TravisCI: iOS アプリ というような感じで使い分けている。 Performance Plan なんだから iOS のも Travis から引っ越せばいいんじゃねえの?と思わんでもないのだが、 Travis の annual 課金がまだ残ってる iOS の CI と TravisCI と CircleCI に
CircleCIで勝手に強くなる静的解析の作り方 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。Garoonチームの杉山(@oogFranz)です。 以前 #PHPerKaigi 2020 にて、「静的解析の育て方」というタイトルで発表いたしました。この発表ではレガシープロダクトにおいて静的解析が有効であることと、「育てる」という比喩表現で静的解析のルールを強くしていく戦略についてお話ししました。 発表後のAsk the Speakerでは様々な方から講演へのフィードバックをいただき、特に既存のプロダクトに静的解析の導入・運用する大変さやその改善方法に関して議論を深めることができました。議論に参加いただいた皆様大変ありがとうございました。 議論の中でルールを自動的に強くしていく方法のヒントをいただきました。そのヒントを元にCircleCIで勝手に強くなる静的解析が実現ができたので紹介したいと思います。 勝手に育つ静的解析の作り方 通常、レガシープロダクトにおいて静的解析を
Github ActionsでクロスコンパイルしてGithub Releaseにアップロードする - c-bata web
追記: GoReleaserのbabarotさんの記事があったので紹介。GoReleaser使ったほうが手軽でよさそう。 Go で書いた CLI ツールのリリースは GoReleaser と GitHub Actions で個人的には決まり | tellme.tokyo 追記: GoReleaserのプロジェクトがGithub Actionを公開したようなのでこちら使ってみるといいかもしれません。 https://github.com/goreleaser/goreleaser-action この前kube-promptのリリースでミスをしてしまいissueが立て続けに2件上がったことがあったのですが、Github Actionsが自分のリポジトリで使えるようになったのでリリースを自動化することにしました。 触ってみてわかったのですが、↓の記事を書いたときとは多くの変更がありました。wor
CI/CD パイプラインを最速で組み立てるための 4 つのポイント / Four points to assemble the CI CD pipeline fastest
CI/CD Test Night #4 の登壇資料です。 #cicd_test_night
ウェブコンテンツをホスティングする際に Firebase Hosting という大変便利なサービスがあります。 2020/10/8にGitHub ActionsとFirebase Hostingの統合が強化され、より便利に利用できるようになったのでご紹介します。 なお、公式のドキュメントは以下となります。 現時点では機械翻訳のため、言語をEnglishにして読んだほうが正確です。 GitHubプルリクエストを介してライブチャンネルとプレビューチャンネルにデプロイする できるようになったこと できるようになったことは主に以下の3つです。 GitHub ActionsでPull requestを作成時に、プレビューサイトをデプロイできる GitHub ActionsでPull requestをマージ時に、本番サイトにデプロイできる Firebase CLIツールのコマンドでGitHub Act
こちらのエントリーが素敵だなと思ったので、最近書いてるKotlinプロジェクトのベストプラクティスをまとめてみます。一部はJavaプロジェクトにおいても利用できるはずです。 zenn.dev 基本方針 参加障壁を下げる。OSSプロジェクトでもプロプライエタリ・ソフトウェアプロジェクトでも、新しい開発者が参加するコストを下げることには大きな意義がある。 環境差異を吸収する。javaにPATHが通ってさえいればOSに関係なくビルドが通るようにする。 プロジェクト固有ルールを作らない。Conventional CommitsやKeep a changelogなど、ひろく世に使われているルールを採用する。 Gradleを設定する Spotlessを使う コードのフォーマットはformatterに任せて人間は細かいことを考えない、というのが不特定多数が参加するソフトウェアプロジェクトのあるべき姿だと
こんなことがありながらも、僕もたまにあれこれやっていて、上記の件はおそらくタイムゾーンの問題が別であったのでそれに起因して起きているんじゃないか？と言ったら調べるわーって状態になりました。 さて、そんなペパボではGitHub Enterpriseでも絶賛GitHub Actionsを活用しているのですが、アプリケーションの自動テスト、デプロイをはじめ、いわゆるコンテナジョブプラットホームとしてもActionsはとても優秀なので色々活用しています。そのなかで通常のpushやscheduleだけではなく、任意のパラメーターで任意のタイミングでジョブが実行したかったものですから、作りました。 こんな感じでジョブを実行することができます。 仕組みとしてはActionsの repository_dipatch を利用しています。
「Jestではじめるテスト入門」を書きましたー #Jest本 - Mitsuyuki.Shiiba
Jestではじめるテスト入門 本日「Jestではじめるテスト入門」がついに発売されました 🎉🎉🎉 peaks.cc CircleCI時代の同僚の伊藤さん @ganezasan が「Jestの自動テスト本の執筆を手伝ってくれませんか？」と声をかけてくれて「これからテストを書きたいって人に向けたJestの入門書を書きたいんですよ！！」って熱く語ってくれて「いいなぁ」と思ったので参加しました。本を書くなんて初めてのことなので、自分なんかに書けるかなぁとドキドキしてたのですが、周りの方々の助けのおかげで、なんとか書き上げることができました。 そして、監修はなんと和田さん @t_wada です。自分が自動テストについて書いた文章を、和田さんに監修していただけるなんて、それだけでとても幸せだなぁと思っていたのですが、「むちゃくちゃ面白かったです！」って言ってもらえたので、もう出版しなくても満足し
GitHub Actionsに「強い」AWSの権限を渡したい ~作戦3 - AssumeRole with Google ID Token ~ - KAYAC engineers' blog
こんにちは。技術部の池田です。 この記事では、Github Actions上に「強い」AWSの権限を渡すために以下のことを行います。 App Runnerでお手軽にGoogle ID Token 取得するためのWeb Applicationを動かす。 Web Applicationから取得できるGoogle ID Tokenを信頼するIAM RoleにAssumeRoleする。 AssumeRoleによって得られた一時的な強い権限で、強い権限を要求する作業(Deploy, Terraform Apply)をGithub Actionsで行う。 これにより、Github Actions上にAWSのアクセスキーを置かずに、ある程度安全な方法でAWS上での強い権限を要求する操作を実行できます。 そのため、例えばGithub Repositoryに不正アクセスされてしまったとしても、AWSの本番環
Renovateを使ってフロントエンドのバージョンアップを改善した話 | PR TIMES 開発者ブログ
こんにちは、フロントエンドエンジニアの小張です。Renovateを使ってフロントエンドのパッケージやライブラリのバージョンアップを改善したことについて紹介します。 PR TIMESではReactに関するコードを、monorepoとしてprtimes-frontendという1つのリポジトリで管理しています。 このリポジトリは作成されてから2年ほどしか経っておらず、使っているライブラリも比較的新しいため、今までバージョンアップの仕組みを特に整備していませんでした。 ただフロントエンドのライブラリはバージョンアップの頻度が多く、異なるライブラリ間でバージョンの依存関係があることもあり、将来のことを考えればライブラリのバージョンを更新する仕組みを作ることはほぼ必須でした。 また、monorepoであるためライブラリのバージョンを大きくあげようとした際の対応コストも大きく、最新との差が小さいうちに細
なぜ執筆プロジェクトを立ち上げたのか？ 2020年の年末から年明けに開催された技術書典10で「はじめてのJest入門」を執筆しました。私自身はIT業界に約10年いますが、受託案件やR&Dのようなプロジェクトに参加することが多く、テストについての経験があまり得られないまま過ごしてきました。そんな中で社内のメンター＆メンティープログラムでTDD（Test-Driven Development：テスト駆動開発）について学ぶ機会があり、セッションを通して学んだことを記憶に残す意味でも、この本を書くことに至りました。しかし、前回の書籍ではTDDやテスト自体の概念についてはあまり触れず、セッションで利用したJestの基本的な機能や使い方についてフォーカスしました。 前回の技術書典10のイベントを通じて、同じような悩みや課題感を持った方多くがいることを知ることができました。JavaScriptは元々フロ
ECS用のCDパイプラインに対する考察
それでは、1パターンずつ構成を確認していきます。 1. 全部GitHub Actionsでやる GitHub Actionsでパイプライン全体を構築する場合は、以下の図のような構成になります。 ちなみに、GitHubのDeploymentsを使用することで、Slackと組み合わせてのChatOpsや、任意のコミットのデプロイを実行などいろいろと便利になります。 ですが、Deployments APIをパイプラインで利用するには、Actionsのトリガーの条件を変えたり、ECSへのデプロイの成否に応じてAPIを使ってDeploymentのステータスを更新したりする処理が必要になり、少々パイプラインが複雑化してしまいます。 なので、今回の趣旨とちょっとずれているため、各パターンには記載していません。 では、以下で処理を順に説明していきます。 Image Build 図中の Build Imag
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 以
GitHub Actionsを機能ごとに分けて管理したかった | by Asai | Finatext | Feb, 2021 | Medium
Photo by Ash from Modern Afflatus on UnsplashはじめにFinatextでエンジニアをしている浅井です。 弊社では先日「Wealth Wing」という資産運用サービスをリリースしました。 サービスの詳細を知りたい方は、こちらのnoteも合わせて読んでいただければと思います。 Springについてとスクラムの導入については既に他のメンバーが書いているので、 今回はGitHub Actionsについて書いていきます。 概要Wealth Wingの開発チームではGitHub Actionsで ktlintでのフォーマットチェック(以下lint)単体テスト(以下test)シナリオテスト(実際のエンドユーザの動きやバッチ処理の一連の流れを一つのシナリオとして盛り込んだテスト。以下scenario test)を動かしています。 これらの処理に軽く依存関係を持た
コンテナイメージビルドが遅いなら、Kaniko使うと幸せになれる（全部入りRails Dockerfileを参考に） - Qiita
コンテナイメージビルドが遅いなら、Kaniko使うと幸せになれる（全部入りRails Dockerfileを参考に） 結論 BuildKit対応してないCI/CD（サービス）使ってるならKaniko使えば早くなるよ Google Cloud Build使ってるなら迷わず使っておくべき Amazon Elastic Container Registry（ECR）でも問題なく使用できる この記事の例でいうと未キャッシュからフルキャッシュなら 288秒→132秒に短縮（約2倍） 御託はいいのでどう書くか教えて ここに書いてますので、自分の使ってるCI/CDサービスに当てはまるのを選んで参考にどうぞ https://github.com/chimame/kaniko-example 本題 長いうんちくや説明を知りたい人向けです。 この記事で記載するのはAmazon Elastic Containe
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Actions: Manual triggers with workflow_dispatch
Github Actionsの個人的ユースケース備忘録 | DevelopersIO
Github actions のコスパについて考えた - たゆたふ。
Docker V2 Github Action is Now GA | Docker
GitHub Actions + AWS CodeBuildでPRごとの検証環境を作ってみた
CircleCIからGitHub Actionsへの移行 (Node.js) - 余白
VPSを解約してFirebase Hostingにブログを移した | おそらくはそれさえも平凡な日々
CircleCI 2.0を支える2つの コンテナクラスターとSRE
GitHub+CircleCIによる業務要件の記述精度向上の取り組み - ZOZO TECH BLOG
イマドキの cron は GitHub Actions / CircleCI でやりたい
GitHub Actions: Secure cloud deployments with OpenID Connect
GitHub Actions を使ってリリース時のあれこれを自動化する
npmのprivate registryからGitHub Packages Registryに移行する
CLIツールを作るためにoclifを試してみたら簡単すぎて吃驚した | Trial and Spiral
CircleCI (Performance Plan) vs. Github Actions - Diary
Firebase公式のGitHubとHostingのインテグレーションが熱い🔥
https://presstige.io/p/Using-GitHub-Actions-with-Go-2ca9744b531f4f21bdae9976d1ccbb58
Gradle/Kotlinで開発する私的ベストプラクティス2022 - Kengo's blog
GitHub ActionsをSlack Botから起動する | ten-snapon.com
テスト未経験から中上級者へのガイドライン！「Jestではじめるテスト入門」出版プロジェクト！ - PEAKS
tfcmt で Terraform の CI/CD を改善する