『GitHub CI/CD実践ガイド』でGitHub ActionsとCI/CDを体系的に学ぼう - 憂鬱な世界にネコパンチ！
『GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用』という書籍を最近出版したので紹介します。本書ではGitHub Actionsの実装と、CI/CDの設計・運用を体系的に学べます。一粒で二度美味しい書籍です。筆者個人としては「実践Terraform」以来、4年半ぶりの商業出版になります。 gihyo.jp どんな本？ GitHub利用者にとって、もっとも導入が容易なCI/CD向けのソリューションはGitHub Actionsです。GitHub Actionsの活用事例は多く、検索すればたくさん情報が出てきます。ただ断片的な情報には事欠かない反面、体系的に学習する方法は意外とありません。CI/CD自体がソフトウェア開発の主役になることもまずないため、なんとなく運用している人が大半でしょう。そこで執筆したのが『GitHub CI/
はじめに こんにちは、サイボウズ24卒の@yuasaです。 サイボウズでは開発・運用系チームに所属する予定の新卒社員が研修の一環として、2週間を1タームとして3チームの体験に行きます。新卒社員の私が生産性向上チームの体験に行った際に、チーム内でGitHub Actionsを利用する際の脅威と対策について調査を行い、ドキュメント化した上で社内への共有を行いました。本記事では、そのドキュメントの一部を公開します。 対象読者 本記事の主な対象読者としては、以下のような方を想定しています。 GitHub Actionsを組織で利用しているが、特にセキュリティ対策を実施していない方 GitHub Actionsを組織で利用しており、部分的にセキュリティ対策を実施しているが、対策が十分かどうか分からない方 本記事がGitHub Actionsのセキュリティ対策を検討する上で参考になれば幸いです。 本記
この本の概要 本書はCI/CDの設計や運用について，GitHubを使ってハンズオン形式で学ぶ書籍です。GitHub Actionsの基本構文からスタートし，テスト・静的解析・リリース・コンテナデプロイなどを実際に自動化していきます。あわせてDependabot・OpenID Connect・継続的なセキュリティ改善・GitHub Appsのような，実運用に欠かせないプラクティスも多数習得します。 実装しながら設計や運用の考え方を学ぶことで，品質の高いソフトウェアをすばやく届けるスキルが身につきます。GitHubを利用しているなら，ぜひ手元に置いておきたい一冊です。 こんな方におすすめ GitHubは使っているけれど，プルリクエストぐらいしか利用していない CI/CDというキーワードは知っているけれど，自分で設計したことはない GitHub Actionsには触れているけれど，正直雰囲気で運
どうも GitHub Actions 上で Docker ビルドを行うと時間がかかるなぁと感じていました。 かなり軽量の Go の Web アプリケーションを Docker イメージにしてプッシュするプロセスなのですが、全体で 3 分ほどかかっています。 今回はその速度改善を行ったので、得た知見を記事にしたいと思います。 最終的に、ケース次第では以下のような結果を出すことができました。 ※ケース = go のソースコードのほんの一部を変更してワークフローを実行する。 go.mod など依存関係に変化はない。 go build: 60秒 → 1秒 docker/build-push-action ステップ: 2分30秒 → 30秒 ワークフロー: 3分 → 1分 前提 go build は Dockerfile のステップで行っており、イメージとして以下のような内容になっています。 FROM
GitHub Actions に Arm64 ランナーが来たので Docker のマルチプラットフォームイメージをビルドしてみる
GitHub Actions に Arm64 ランナーが来たので Docker のマルチプラットフォームイメージをビルドしてみる 2024/06/03 に GitHub Actions に Arm64 ランナーが追加されました。 現在はパブリックベータで、Team と Enterprise Cloud プランでのみ利用可能です。料金は x64 の同性能のランナーより 37% 安く、電力効率が高いため二酸化炭素排出量削減にもつながるとのことです。 この記事では、新しく追加された Arm64 ランナーを使って Docker のマルチプラットフォームイメージをビルドしてみます。 マルチプラットフォームイメージとは？ マルチプラットフォームイメージとは、複数の異なる CPU アーキテクチャ（場合によっては異なる OS）のイメージを 1 つのイメージとして扱えるようにまとめたものです。マルチプラット
ラブグラフのエンジニア＆CTOをしております横江( @yokoe24 )です！ ラブグラフでは昨年、エンジニアインターンが４名も増えました！🎉 おかげでチームの開発力が上がったのですが、こんな問題も！ プルリク溜まっていく問題 どこの会社でもあるあるだと思うのですが、 開発チームの人数が増えてくると、開発力が上がりプルリクエストがいっぱい作られ、 今度はレビューが間に合わない問題が起こっていきます。 前までは、 「自分のプルリクエストがレビューされるまで、開発チームのチャンネルにリマインドし続けよう！」という方針でなんとかなっていたのですが、 インターンは常に勤務してるわけではないので各々がリマインドし続けるというのは限界があり、 インターンの作ったプルリクエストが放置されやすくなる問題が発生していきました😰 ミニマムな解決法 ミニマムな解決法としては、 プルリクに 「レビュー依頼中」
Arm64 on GitHub Actions: Powering faster, more efficient build systems
GitHub is ecstatic to unveil ArmⓇ-based Linux and Windows runners for GitHub Actions are now in Public Beta. This new addition to our suite of hosted runners provides power, performance and sustainability improvements for all your GitHub Actions jobs. Developers can now take advantage of Arm-based hardware hosted by GitHub to build and deploy their release assets anywhere Arm architecture is used.
過去のGitHub Actionsのbuild時間を取得して集計してグラフにする - xuwei-k's blog
継続的にメンテナンスするのではなくて、雑な使い捨てでいいならshellscriptとjq職人芸でいけるので頑張ってしまったけれど、継続的にやるならもっと違うもので書いた方がメンテナンスしやすいと思います。 細かい部分はいくらでも改善の余地があるとは思いますが、とりあえず動いたのでヨシ・・・!? 以前も多少似たような何か作ったけど、こういうの誰か既にもっと綺麗に作ってないんですかね。 xuwei-k.hatenablog.com GitHub Actionsのログはデフォルトでは90日保存されてるはずなので、その程度の期間をなんとなく集計したいだけならば、こうやって後から集計するだけで十分ですね。 もちろん、yamlの内部の構造がすごく変わっていると集計が難しいか実質不可能になるリスクはありますが。 もっとしっかり計測したいならば、buildした時点で専用の場所に綺麗に記録して、他のもっとリ
GitHub Actions Meetup Tokyo #3 (2024/5/16)
Using Dhall To Manage GitHub Actions Workflows
In my previous post, I talked about how we use Github Actions to automate our workflows. As promised, I will show how we use Dhall to manage our GitHub Actions files. Don’t Repeat Yourself “Don’t Repeat Yourself” (DRY) is a programming principle that reduces repetition in code. As we created more actions in a growing number of repositories, we noticed that there were a lot of repeating steps, jobs
Author Larissa Fortuna GitHub Actionsは、開発者が市場で最新かつ最も持続可能なプロセッサーでビルドを開始できるように、Armが構築したイメージ付きのArmホステッドランナーをパブリックベータ版で提供開始しました。 GitHubは、GitHub Actions用のArmⓇベースのLinuxとWindowsランナーを発表しました。この新しいランナーは、GitHub Actionsのすべてのジョブのパワー、パフォーマンス、持続可能性を向上させます。開発者はGitHubがホストするArmベースのハードウェアを活用し、Armアーキテクチャが使用されているあらゆる場所でリリースアセットをビルド、デプロイできるようになりました。そして何より、これらのランナーの価格は、弊社のx64 LinuxおよびWindowsランナーよりも37%安価です。 顧客は、Armアーキテクチ
ACS事業部 亀崎です。突然ですが、みなさんGitHub Actions活用していますか？ そんな中でGitHub Actionsでワークフローを実行する際、ループ処理を実行したいと思うことはないでしょうか？ commandsというフォルダにcommand1.sh ～ command9.sh の9個のファイルがあり、これらの内容の処理をワークフロー内で実行したいといったケースを想定します。 今回はこのパターンを例にループ処理を実行してみたいと思います。 基本的なやり方 ファーストステップ まずぱっと思いつくのは次のようなやり方です。 name: simple-echo-loop on: workflow_dispatch: jobs: job: name: setup target modules runs-on: ubuntu-latest steps: - uses: actions/
VimのYAMLのシンタックスハイライトを改善してGitHub Actionsのワークフローファイルでハイライトが壊れにくくしました - プログラムモグモグ
GitHub ActionsのワークフローにはYAMLファイルを使いますが、Vimのシンタックスハイライトがうまく効かなくて困ることがよくありました。 Actionsでは複数行にわたる文字列に複雑なシェルスクリプトを書くことが多いのですが、 その中の一部がYAMLのフロースカラースタイルの文字列として認識されてしまい、ハイライトが壊れることがあるのです。 jobs: test: runs-on: ubuntu-latest steps: - run: | echo "Hello world!" | cut -f1 -d" " echo "This line is broken!" - env: test: ${{ inputs.* | join(' ') }} run: | echo 'This line is broken!' はてなブログも全く同じ問題があることから、中ではVimのシン
GitHub Actions ですべてのCIの完了をチェックして PR を Auto-Merge する
◆ モチベーション ◆ 方法 ◆ 補足 ◆ YAML の解説 ∘ GitHub Actions を動作させる条件 ∘ 全体的な動き ◆ さいごに ◆ 参考 モチベーションGitHub と なんらかの CI を組み合わせて、マージ前にテストを通すことがよくあると思います。 ただ「CI が通るのを待ってマージするのはめんどくさいです！！！！」 ひたすらCIが通るのを待ってる人GitHub には マージ条件がすべてクリアされていれば勝手にマージしてくれる Auto-Merge という機能があります。（楽ちん） しかしこれには 落とし穴 がありました。 リポジトリの構成にもよりますが、ドキュメントやコードなど様々なファイルがリポジトリに存在していると思います。 ファイルによってチェック観点が様々なため、ファイルによって走らせる CI を変更するのが一般的でしょう。 とある Pull Request
コスト削減も実現！ AWS CodeBuildとGitHubを連携し、GitHub Actionsセルフホステッドランナーを利用しよう
本連載では、AWSに関して、なかなか時間がとれず最新のアップデートを追えていない方や、これからAWSを利用したいと考えている方に向けて、AWSから発表される数多あるサービスアップデートのうち、NTTデータのITスペシャリスト達がこれだけは押さえておくべきと厳選した内容を定期的に紹介します。本記事では、GitHubとAWS CodeBuildの機能連携に関するアップデートについて紹介します。 はじめに 代表的なCI/CDサービスとしてGitHub Actionsを利用されている方も多いのではないでしょうか。 本記事では、下記3点に沿ってGitHubとAWS CodeBuild（以下、CodeBuild）の機能連携に関するアップデートを紹介したいと思います。 アップデートの概要について GitHubとCodeBuildの連携 GitHub Actions RunnerをLambdaで検証 AW
自動化と効率化のためにGitHub Actionsを使いこなそう (2024/06/19 20:00〜)
お知らせ 【重要なお知らせ】iOSアプリの運用および提供を2024年6月3日(月)を以て終了いたします。詳細は お知らせをご覧ください。 お知らせ connpassではさらなる価値のあるデータを提供するため、イベントサーチAPIの提供方法の見直しを決定しました。2024年5月23日(木)より 「企業・法人」「コミュニティ及び個人」向けの2プランを提供開始いたします。ご利用にあたっては利用申請及び審査がございます。詳細はヘルプページをご確認ください。
Author Larissa Fortuna GitHub Actionsは、開発者が市場で最新かつ最も持続可能なプロセッサーでビルドを開始できるように、Armが構築したイメージ付きのArmホステッドランナーをパブリックベータ版で提供開始しました。 GitHubは、GitHub Actions用のArmⓇベースのLinuxとWindowsランナーを発表しました。この新しいランナーは、GitHub Actionsのすべてのジョブのパワー、パフォーマンス、持続可能性を向上させます。開発者はGitHubがホストするArmベースのハードウェアを活用し、Armアーキテクチャが使用されているあらゆる場所でリリースアセットをビルド、デプロイできるようになりました。そして何より、これらのランナーの価格は、弊社のx64 LinuxおよびWindowsランナーよりも37%安価です。 顧客は、Armアーキテクチ
この記事は、Lancers（ランサーズ） Advent Calendar 2023 の2日目の記事です。 モチベーション GitHub ActionsのMySQLサービスに設定を反映したいケースがありました。 本稿ではその時に発見したソリューションをTipsとして紹介します。 tl;dr GitHub ActionsではMySQLの起動オプションを指定できない docker cpでcnfファイルを送り込んでMySQLを再起動するのは嫌だ shogo82148/actions-setup-mysqlを使えば良い感じに設定を反映できるのでお勧め GitHub ActionsではMySQLの起動オプションを指定できない CircleCIでは下記のようにMySQLコンテナの起動オプションを指定することで設定を反映できます。 docker: - image: cimg/mysql:8.0.27 en
個人的に時々更新している次の Docker イメージがある。 qiita.com そのサイズ、約 10GB。 もちろんビルドにも時間がかかる。 これまで Github workflow でビルドし、 Github Container Registory (ghcr) に push して公開していた。 もともとビルドに１時間以上かかっていたが、x86_64 に加えて Arm64 向けにもビルドしようとしてできなくなった。Github workflow はデフォルトでは６時間でタイムアウトし、強制終了となる。その６時間の内に終わらなくなってしまったのだ。 Public なリポジトリだと無料なので少々時間がかかってもまあいいかと長過ぎるビルド時間を改善せず放置していたのだがビルドできないのは困る。 AWS CodeBuild に乗り換えようかなとも思ったのだけど、以前から気になっていた Gith
高コスパで電力効率のよい Arm ベースの GitHub Actions Runner を使っていく | 豆蔵デベロッパーサイト
はじめに # Arm ベースの Actions Runner がパブリックベータになりました。Arm ベースの Linux / Windows ランナーが提供されます。 Actions: Arm-based linux and windows runners are now in public beta GitHub のブログでは、Arm テクノロジーがデータセンターの電力消費を削減することが記載されています。Windows ランナーについては、GitHub と Arm が提携して Windows VM イメージを提供しているようです[1]。 Arm64 on GitHub Actions: Powering faster, more efficient build systems 我々ユーザーにとっての魅力は x64のランナーに比べ37%も安いその価格です。価格表は以下にあります。 Pe
github actions で OIDCでAWSを認証しようとしたらエラーがNot authorized to perform - Qiita
{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWSアカウント}:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringLike": { "token.actions.githubusercontent.com:sub": "repo:${githubリポジトリ}:*" } } } ] }
Reusable workflows / Composite action を用いて GitHub Actions の処理を再利用する
その他、Reusable workflows の詳細な仕様については公式ドキュメントを参照ください https://docs.github.com/ja/actions/using-workflows/reusing-workflows 記述例 ここでは、GitHub Actions の Lint ツールである actionlint を実行する Reusable wofkflows をサンプルとして掲載します。 on: workflow_call: inputs: os: default: ubuntu-latest required: false type: string jobs: actionlint: runs-on: ${{ inputs.os }} steps: - uses: actions/checkout@v4 - name: Run actionlint shell:
概要 この記事では、GitHub Actions におけるワークフロートリガーイベントのひとつである pull_request のアクティビティ（ワークフローの発火条件）について説明します。 対象読者 GitHub で Pull Request に対する操作を条件に GitHub Actions を動かしたい人 17種類のアクティビティ pull_request に用意されているアクティビティは下記17種類です。 アクティビティ 概要
はじめに この記事は、GitHub Actionsを新規導入する際に、事前にチーム内で確認・共有しておくべき基本的な事項をまとめたものです。筆者の経験や周囲のチームでのユースケースを元にしていますが、基本的にはどのようなチームでも参考になる内容になっているつもりです。 なお、この記事ではCI/CDの基本、ワークフローの書き方やHowto/Tipsといった具体的な利用方法については扱っていません。これらについては他にも多くの有用な記事が存在しますので、そちらをご覧ください。 また、この記事はGitHub Teamsでの利用を想定した内容で記述しています。（Enterpriseなどの）他のプランでは仕様が異なる場合があるのでご注意ください。 記事の内容は正確さを心がけていますが、ご自身でも内容の確認をお願いいたします。 料金 GitHub Actionsはpublic repositoryでの
これによって、ワークフローの記述が簡潔になり、environmentがprodの時はワークフロー実行時にレビュー担当者の承認を必要とする設定などができるようになります。 アップデート以前 入力タイプのアップデート以前は、環境ごとに共通のワークフローを使用する場合、Stringのinputでenvironmentを指定していたので、typoしたり、存在しないenvironment名を指定してしまう可能性がありました。 アップデート後 今回のアップデートで、workflow_dispatchのinputsをtype: environmentとすると、すでに設定されているenvironment名が自動でプルダウン表示されるようになりました。 これによって、存在しないenvironmentを指定してしまうことが無くなります。 environmentの登録 今回はdevとprodを登録。secret
Artifact Attestations で GitHub Actions ワークフローの成果物の出所情報を検証可能にする | 豆蔵デベロッパーサイト
はじめに # GitHub の Artifact Attestations を使用すると GitHub Actions ワークフローでビルド成果物に署名して成果物の出所情報を検証可能にできます。 Artifact Attestations は現在パブリックベータです。 Introducing Artifact Attestations–now in public beta Artifact Attestations はソフトウェア成果物の署名と検証を行うための OSS である Sigstore により実現されています。この機能のため、GitHub はルート証明機関(CA)になっています。 InformationSigstore を使ってコンテナイメージや Go Modules などの成果物に署名を行う GitHub Actions ワークフローの構成に関しては以下の記事で扱っています。 ソ
GitHub Actionsでジョブ間で値を共有する方法
はじめに GitHubActionsのワークフローにて、ジョブにて取得した値を後続のジョブに渡したい要件があったので、ジョブ間で値を共有する方法を調査したメモです。 ジョブとは？ ジョブ ジョブは、同じランナーで実行される一連のステップです。 デフォルトでは、複数のジョブを含むワークフローは、それらのジョブを並行して実行します。 ランナー ランナーは、GitHub Actionsランナーアプリケーションがインストールされているサーバーです。 GitHub がホストするランナーを使用することも、自分でランナーをホストすることもできます。 ランナーは、使用可能なジョブをリッスンし、一度に 1 つのジョブを実行し、進行状況、ログ、および結果を GitHub に返します。 ジョブ間で値を共有するということはサーバー間で情報の受け渡しをするということ。 コンテキストとは？ GitHub Action
百番煎じだけど、チームの Github Actions 活用方法とデプロイの流れを紹介してみる - BBSakura Networks Blog
はじめに この記事は BBSakura Networks Advent Calendar 2023 の 21 日目の記事です。 adventar.org こんにちは、BBSakura Networks のシステム管理部に所属している蟹江（@kanix2929）です。普段は BBIX から委託されているシステムなどの開発・運用がメインで、ネットワークエンジニア / オペレーターを手助けするためのシステム構築・自動化に尽力しています。 最近、複数人で同時並行的に 1 つのコードを触る場合が増えてきたことから、あらためてチーム内で開発プロセス（GitHub の運用方法など）についてまとめたので紹介してみます。 はじめに 環境について 開発の流れとルール ざっと絵にするとこんな感じ 流れを言語化すると もろもろの採用理由 おわりに [参考] build-image.yml ちなみに release
How can I disable a github action? - GitHub Actions - GitHub Support Community より。 一時的に特定の GitHub Actions を無効にする方法を2つ紹介します。 ※もちろん .yml を消せばよいのですが、消したくない場合の方法です。 全てのブランチを無視する 全てのブランチを無視するので、Actions が実行されることはありません。 ディレクトリ名を変える もうひとつは .github/workflows/my_action.yml を .github/disabled-workflows/my_action.yml にリネームする方法です。 GitHub Actions は .github/workflows 以下の yml しか見ませんので、disabled-workflows 以下は実行されませ
やったこと Dataformのリリースフローの変更 変更後: mainブランチにpushした際に「コンパイル結果の作成」と「リリース構成の更新」を実行するようにした 変更前: リリース構成のスケジュール設定に従い、コード変更の有無に関わらず定時実行でコンパイル結果の作成を行っていた ワークフローのyaml gcloud cliにdataform関連がないのでcurlでdataform.googleapis.comを叩く name: Dataform Create Compilation and Update Release Config on: push: branches: main env: WORKLOAD_IDENTITY_PROVIDER: "projects/hogehoge/locations/global/workloadIdentityPools/hogehoge-poo
GitHub Actionsにarm64 runnerが来たので自社サービス環境をarm64に対応させてみた
お久しぶりです。スターフェスティバル株式会社エンジニアのsoriです。 6/3にGitHubからArm64環境のGitHub Actions Runnerが発表されました！ まだこのRunnerはPublic betaであり、Team/Enterprise planでしか使えませんが、Silicon Macの普及やAWSでもGravitonインスタンスが使われるようになり、コストにもパフォーマンスにも寄与する良い感じの流れになってきましたね。 そんな流れが来たので自社のサービスの動作環境をarm64に対応させてみました。 ちなみに、既存の環境はGitHub Actionsでdocker buildでイメージをビルドし、AWS ECRのリポジトリにアップロードし、Amazon ECS Fargateな環境にタスク定義をレンダリングさせて動作させるといった状況です。 社内向けにメモをしたためた
GitHub Actions では、指定したフォルダ (ファイル) の差分の有無によって workflow を実行するかどうかを制御することできますが[1]、差分がない場合にワークフロー全体をスキップする代わりに一部だけスキップできれば便利な状況があり、git diff の結果に応じて分岐するフローを作りました。 最終形 name: CI on: pull_request jobs: ci: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - run: git fetch origin ${{ github.base_ref }} --depth=1 - id: diff run: echo "::set-output name=changed::$(git diff --name-only origin/${{ gith
やりたいこと Next.jsで作成したwebサイト（SSG）を、さくらのレンタルサーバーにデプロイする作業を自動化する。 自動デプロイのタイミングは 手動でボタンを押す mainブランチへのマージ（厳密にはmainにpushされたとき） 環境 yarn 4.1.1 Next.js 14.1.0 App Routerを利用 Static Exportsを使い、静的サイトを生成 手順の流れ Next.jsのSSG設定を行う GitHub Actionsのymlを作成する レンタルサーバーにFTP接続するためのSecretsを設定する レンタルサーバー側のIPアドレス制限を解除する ①まずはNext.js側の設定 Static Exportsの機能を利用するためには、next.config.jsの修正が必要。 next.config.jsを以下のように修正する。 /** * @type {imp
GitHub Actionsでメタデータファイル(action.yml)を作成してワークフローを共通化しよう！ - Qiita
メタデータファイル GitHub Actionsではメタデータファイルというファイルに共通の処理を記載することができます その際はaction.ymlファイルを作成し、記載します Node.js用のメタデータファイルを作成しよう！ Node.jsのインストール Cacheの作成 npm ci の実行までをaction.ymlに記載します 今回は今後別の処理を共通化したい時を想定してaction.ymlを .github/actions/set-up-node/内に格納します name: 'Setup Node.js' description: 'Setup Node.js by using cache and npm' inputs: working-directory: description: 'working-directory of package-lock.json' requi
Terraform Cloudでstateを管理してgithub actionsでAWSを管理するCI/CDを組む - Qiita
概要 従来はstateファイルをAWS S3 やGCP GCSで管理していたがTerraform Cloudで管理するメリットが大きい 従来のバケットでのstate管理 AWSにあるリソースを管理するためにAWS S3を使う釈然としない感じになってる Terraform Cloudでのstate管理 S3で管理していたところがTerraform Cloudになるだけだが メリットとしては Stateファイル管理用のリソースを用意する必要がない Stateファイルの変更履歴をGUIで簡単に確認できる Stateファイルの細かいアクセス制御をシンプルに実現できる plan や apply時に自動でstateロックしてくれる デフォルトでバージョン管理機能がついてる Freeプランで500 Resourcesまで無料 これだけメリットがあるから使わない手はない 実装手順 Terraform Cl
アーカイブ2024/05 (1) 2024/04 (7) 2024/03 (4) 2024/01 (3) 2023/12 (1) 2023/11 (3) 2023/10 (1) 2023/09 (1) 2023/08 (2) 2023/05 (4) 2023/04 (4) 2023/03 (4) 2023/02 (2) 2023/01 (1) 2022/12 (1) 2022/11 (4) 2022/10 (3) 2022/09 (2) 2022/08 (4) 2022/07 (5) 2022/06 (4) 2022/05 (9) 2022/04 (8) 2022/03 (10) 2022/02 (21) 2022/01 (8) 2021/12 (11) 2021/11 (1) 2021/10 (4) 2021/09 (2) 2021/08 (1) 2021/07 (2) 2021/06
Leaner 開発チームの黒曜(@kokuyouwind)です。 今年 5 月に開催される RubyKaigi 2024 で CfP が採択されました！ 昨年の RubyKaigi 2023 LT では「RBS meets LLMs - 大規模言語モデルを用いた型推論を試してみた」というタイトルで登壇しましたが、この発表で Future Work として挙げた「ツール化と各種 LLM, プロンプトでの精度検証の話」をする予定です。 以上近況でした。記事は Ruby と全く関係のない GitHub Actions の話です。 TL;DR GitHub Actions の matrix 指定には ${{ fromJSON(needs.setup.outputs.matrix) }} のように動的な値を指定できる。 先行する job で ls 結果を出力しておくことで、ディレクトリごとに 1 つ
概要 複数以上のワークフローで同じ環境変数を使用することがあるかと思います 新しいワークフローを作成するたびに同じ環境変数をハードコーディングするのは手間なので 今回はワークフロー間で環境変数を共有する方法について解説します 前提 今回はDjangoとPytestを使ったテストの自動実行とpdocでのドキュメントを自動生成するワークフローを例に作成します メタデータ構文を使用します テストの自動実行、pdocを使ったドキュメント生成のワークフローを作成する方法については解説しません ディレクトリ構成 tree ・ ├── .github | ├── action | | ├── set-up-env | | | └── action.yml | | └── set-up-poetry | | └── action.yml | └── workflows | ├── docs.yml | └
はじめに この記事の Android 版を書いていきたいと思う。 iOS より手順は少ない気がするけれど、Gradle と仲良くないので手こずった。なのでそのあたりはコピペでなんとか動いたという感じになっている。Gradle に関する知見をお持ちの方がいたら補足してほしい。 この記事でやっていること Flutter アプリを Android App Bundle で書き出す gradle-play-publisher を使って Google Play Console にアップロード さっそく main.yml を載せておく。前回と同様このリポジトリで作業をした。 name: CI on: # main branch に push があったらこの workflow がはしる push: branches: [ main ] jobs: # --------------------------
Google Cloud の Workload Identity 連携でGitHub Actionsから認証する | Marginalia
いまさらだが、秘密鍵を共有する方法ではなく、GitHub Actions のOIDCトークンを使った方法を使ってGCPの認証を有効にしてみたので、その作業メモ。 基本的には Google Cloud Blog に書いてあるとおりのことをやっただけだが、ほとんどのドキュメントが gcloud コマンドを使った設定手順しか説明していないので、あえてWebコンソール上で同等の操作を読み解いて作業した。 GCP: Workload Identity プロバイダの作成下の図でいうところの Cloud Provider を準備する。GCPではこの部分が IDプロバイダ と、それのコンテナになる Workload Identity プール という2つのリソースからなる。 手順は4つある。 Workload Identity プールを作成する プールに IDプロバイダ を追加する IDプロバイダ と Gi
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Actionsにおける脅威と対策まとめ
GitHub CI/CD実践ガイド ――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用
GitHub Actions 上での Go の Docker ビルドを高速化する
レビュー待ちプルリクを減らす GitHub Actions
GitHub Actionsの痒いところを埋めるサードパーティーランナー
GitHub ActionsでArm64が利用可能に：より高速で効率的なビルドシステムを提供
GitHub Actions workflowでループ処理を実行 - APC 技術ブログ
GitHub ActionsでArm64が利用可能に：より高速で効率的なビルドシステムを提供
GitHub ActionsでMySQLを使う時のTips
Github Actions の Self-hosted Runner をやってみた - たゆたふ。
GitHub Actionsにおけるpull_requestイベントのアクティビティの種類 - Qiita
GitHub Actionsを導入する際に確認しておくこと
GitHub Actionsで手動でワークフローを実行する際のenvironmentパラメータを使ってみる
.yml ファイルは消したくないけど、一時的に GitHub Actions を無効にする方法
Github ActionsでDataformのコンパイルとリリース構成の更新を実行する
GitHub Actions で差分有無に応じた細かい制御を行う
【Next.js】さくらのレンタルサーバーへのデプロイを自動化する（GitHub Actions）
Github ActionsからGCPのWorkload Identityを使ってサービスアカウントの権限であれこれしようとすると`Permission 'iam.serviceAccounts.getAccessToken' denied on resource (or it may not exist).`になる | ごみばこいん
GitHub Actions でディレクトリ構造にもとづいて並列実行する
GitHub Actionsのワークフロー間で環境変数を共有するには - Qiita
【Flutter】GitHub Actions で Android 向けに自動デプロイする