1 - 40 件 / 128件
概要 何度も調べて何度もテストしたりしたので、多用するものをまとめていきたい。 項目 push時に実行 // feature/aaaで動く。 feature/aaa/bbbでは動かない on: push: branches: - feature/* // feature/aaa, feature/aaa/bbbで動く on: push: branches: - feature/** // なにかしらのtagがpushされたときに実行、branchのpushは無視 on: push: tags: [ '**' ] branches-ignore: [ '**' ] // 指定したpathの変更だけでは実行しない on: push: branches: - main paths-ignore: - '*.md' - 'docs/**' on: workflow_dispatch: inputs
GitHub Actions入門 ── ワークフローの基本的な構造からOIDCによる外部サービス認証まで GitHubが公式に提供するGitHub Actionsは、後発ながらよく使われるワークフローエンジンとなっています。本記事では、藤吾郎(gfx)さんが、典型的なCI/CDのユースケースに即したワークフローの設定と管理について解説するとともに、注目されているGitHub OIDC(OpenID Connect)の利用についても紹介します。 GitHub Actionsは、GitHubが提供するCI/CDのためのワークフローエンジンです。ワークフローエンジンは、ビルド、テスト、デプロイといったCI/CD関連のワークフローを実行し、定期実行するワークフローを管理するなど、開発におけるソフトウェア実行の自動化を担います。 ▶ GitHub Actions - アイデアからリリースまでのワーク
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
事例集です。 きのう、GitHubの通知を見たら、個人のリポジトリに My First PR というタイトルのPRが来ているのに気づいた。PR出すところを間違えたのかな、と思って見てみたがどうも様子がおかしい。 prog という名前のバイナリファイルを置いている .github/workflows/ci.yml*1の中身をガッと書き換えている on: [pull_request] でworkflowを起動している 20並列でjobが走るようにmatrixを設定している fail-fast: false なので、どれか1つのmatrixが失敗しても他のジョブは続行される base64 encodeした文字列をdecodeしてevalしている ドメインの名前解決を行ったあと ./prog を実行するコマンドにdecodeされた PRをめちゃくちゃな回数closeしてreopenしている PRを
GitHub で職務経歴書を公開 & 継続的に改善していく環境を作ったのでその紹介です。 リポジトリはこちらです。 kawamataryo/resume なぜ職務経歴書を? 今のチームがとても好きなので転職の予定はないのですが、「安定しているときこそ職務経歴書をまとめておくべき。本当に職務経歴書が必要なときはメンタルが消耗していて書く余裕はない」という話を最近知り合いから聞き、それは確かにと思い書き初めました。どうせ書くなら何か面白いことをしたいなと GitHub に公開 & CI 環境の構築をやってみました。 機能紹介 🌐 GitHub Pages で Web ページとしての公開 Markdown + GitHub のファイルビューでも良いのですが、より見やすいほうが好ましいですよね。 GitHub の無料ホスティグ GitHub Pages を使って Web ページとして公開していま
ワークフローの概要 このGitHub Actionsワークフローは以下の主要な機能を持っています: 新しいイシューが開かれたときに自動的に起動 イシューの内容を分析し、不適切なコンテンツをチェック 既存のイシューとの重複を検出 必要に応じてラベルを付与 ワークフローの詳細解説 トリガーとパーミッション設定 name: Issue Review on: issues: types: [opened] permissions: issues: write contents: read このセクションでは、ワークフローの名前を定義し、トリガー条件とパーミッションを設定しています。 on.issues.types: [opened]: 新しいイシューが開かれたときにワークフローが起動します。 permissions: ワークフローがイシューの読み書きと、リポジトリコンテンツの読み取りを行うための権
GitHub Actions のワークフローを静的にチェックする actionlint というコマンドラインツールを最近つくっていて,概ね欲しい機能が揃って実装も安定してきたので紹介します. github.com なぜワークフローファイルの lint をすべきなのか GitHub Actions が正式リリースされてからだいぶ経ち,GitHub 上での CI は GitHub Actions が第一候補となってきているように感じます.僕も新規にリポジトリを作成して CI をセットアップする場合はほぼ GitHub Actions を使っています. ですが,GitHub Actions には下記のような問題があり,actionlint でそれらを解決・緩和したいというのが理由です. ワークフローを実装する時は,GitHub に push して CI が実行されるのを待って結果を確認するという
What is Jamstack? ここ数年でよく聞くようになったワード。 Jamstackとはウェブサイトを構築および運用するための、技術の組み合わせです。 JavaScript・API・事前にレンダリングされたMarkupの組み合わせでJamStackとのこと。 (以前はJAMStackといってたけど、最近はJamstackだったりする) Jamstackは、 「ウェブをより速く・より安全に・より簡単に拡張できるように設計されたアーキテクチャ」であり、 生産性を最大化するツールやフレームワーク、ライブラリやワークフローなどを 組み合わせて構築されるもの、とのことです。 ※(注記)jamstack.orgより 従来のCMSではアクセスがあったとき動的にページを生成しますが、 Jamstackではデプロイ以前に必要なページを生成します。 具体的には、下記。 Webサイトのフロントエンド全体(HTM
概要 GitHub Actions で GitHub ホストランナーを使用する場合、パブリックポジトリは無料ですがプライベートリポジトリは従量課金(無料枠あり)です。 ワークフローを編集する際にデバッグしていると結構な時間を消費してしまいます。 そこでデバッグ時は GitHub ホストランナーを使わずに無料で実行する方法を 3 種類紹介します。 nektos/act 言わずと知れたローカル実行ツールです。 すべてを再現することはできませんがコミットを増やさずにデバッグができます。 注意点 ubuntu-* のみサポート ソフトウェアは指定する Docker イメージ依存、デフォルトのイメージだと色々足りないので -P で指定 secrets.GITHUB_TOKEN が未定義なので Personal Access Token を発行し設定が必要 サービスコンテナ services が使えな
GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを
CI/CD Conference 2023 #CICD2023 https://event.cloudnativedays.jp/cicd2023/talks/1766
GitHub Actionsはワークフロー全体の実行時間や各ステップの詳細な可視化、変更による効果測定を行うには工夫が必要となります。この記事では、OpenTelemetryを活用してGitHub Actionsの実行結果をトレースとメトリクスの形で収集するGitHub Actions OpenTelemetryを紹介します。どのステップに時間がかかっているのか、改善施策の効果がどの程度あったのかを把握しやすくなるため、ワークフローの継続的な改善を目指す方に役立ちます。 Trace Sample (Jaeger) 1. GitHub Actionsにおける課題 1-1. ワークフローの詳細を可視化する方法が提供されていない 1-2. ワークフローの変更による影響を分析しづらい 2. GitHub Actions OpenTelemetryとは 2-1. 概要と主な機能 2-2. OpenT
数えてみたら意外と数あったのでまとめます。 release-please Google謹製のリリース自動化ツール。monorepo対応のRelease Drafterという感じですが、リリースはDraft Releaseの安定版への昇格ではなく、PRのマージによって行います。PRでリリースするという点ではgit-pr-releaseぽいですが、ブランチは main だけでリリースブランチは無い感じ。changesetsよりはとっつきやすい印象です。 github.com 例えば↓のようなワークフローを用意すれば、モジュールごとにGitHub Releaseを作成するためのPRを自動作成できます。 初期セットアップでJSONファイルを2つ作る必要があるのが若干面倒ですが、それさえ越えてしまえば考えることは少なさそうです。 # .github/workflows/release-please.
「GitHub Actions extension for VS Code」パブリックベータ公開。VSCodeからワークフローの実行と監視、管理が可能に GitHubは、Visual Studio Codeの拡張機能としてGitHub Actionsによるワークフローの実行や監視、管理を可能にする「GitHub Actions extension for VS Code」のパブリックベータ公開を発表しました。 GitHub Actions extension for VS Codeを使うことで、VSCodeの画面上からGitHubのActionを実行し、ビルドやデプロイなどの状態を監視できるようになります。 問題が発生した場合にはログの参照も可能。
GitHub上ではてなブログ運営を可能にするテンプレートリポジトリ「HatenaBlog Workflows Boilerplate」をベータ版として公開しました。 このテンプレートをご利用いただくと、組織でのブログ運営に求められるワークフロー(下書きの作成、更新、内容のレビューや公開など)をGitHub上で行うことができます。組織利用向けに整備していますが、どなたでもご利用いただくことが可能です。 導入方法や詳しい利用方法については、上記のリポジトリのREADMEをご参照下さい。 特長など 下書きの作成時に、作成した下書きのみが含まれたプルリクエストを自動で作成します*1。コンフリクトを防ぎ、ワークフロー上の管理を容易にします GitHub Actions を利用して動作するためローカルでの環境構築が不要です。GitHub組み込みのVisual Studio Code (github.d
At the time of writing, this functionality exists but has yet to be announced or documented. It works, though! EDIT: Here is the functionality on the GitHub roadmap. GitHub Actions has new functionality that can vend OpenID Connect credentials to jobs running on the platform. This is very exciting for AWS account administrators as it means that CI/CD jobs no longer need any long-term secrets to be
Rust + Docker + GitHub Actions = めちゃ遅い 以前、GitHub Actions 上の Rust ビルドを高速化する記事を書いたけど、 今回は Kubernetes 環境にスムーズに移行できるよう Docker イメージ化するという要件も加わったことで、改めて試行錯誤する必要が出てきた。 それぞれに対するビルド速度の最適化は存在しているものの、3つ (Rust, Docker, GitHub Actions) すべてを満たすとなるとコピペで終わるほど情報がまとまってないし、見つけた Tips もちょっと古かったり、これというものは見つけられなかった。 公式ドキュメントを見ると正当進化していて新しいオプションが生えていたりしたので、賞味期限は短そうだけど、自分の試行錯誤の結果を残しておこうと思う。 成果としては 12 分 22 秒かかっていた Rust アプリ
こんにちは! 先日最終話が放映された Dr.STONE 2 期が始まった頃、先が気になりすぎて漫画版を大人買いした CTO室 鹿児島オフィスチームのよしこ @yoshikouki です。これぞ社会人の嗜みだなと感慨深くなった30歳の春。 今回は私が運用・開発に携わっているホスティング事業部で Slack ワークフローと GitHub Actions を組み合わせて業務を改善しましたので紹介したいと思います。本改善は、サービスの本番環境に近いステージング環境へのデプロイ作業を Slack 上で行えるようにして、デプロイのための環境構築を不要にしたことに加えて必要なステップを 1 つだけにすることができました。 これまでステージングデプロイの問題点 環境構築についての比較 改善前 改善後 デプロイフローについての比較 改善前 改善後 どのようにして改善したのか 実際の操作画面と流れ 実装方法
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
先日2024年04月16日にタイミーさんのオフィスで開催された、AWS知見共有会というイベントで発表してきました。この会のテーマは「運用のスケーラビリティとセキュリティ」ということで、私は「コンパウンドスタートアップのためのスケーラブルでセキュアなInfrastructure as Codeパイプラインを考える」というタイトルで発表してきています。 イベントの動画もあります。 私の発表は 1:43 ぐらいからです。 この発表については資料と動画を見ていただければ!という感じで特に付け加えることもなかったのですが、イベントの開催後にGitHubから発表された新機能Push rulesがとても便利で、新たなベストプラクティスとなるインパクトがあると思ったので、この記事で紹介します。 Push rulesとは つい昨日発表された機能で、現在はpublic betaという状態です。なので、仕様変更と
こんにちは大櫛です。Travis CIがオープンソースプロジェクトで使いづらくなったり、Azure PipelinesからGitHub Actionsになった途端*1爆発的な流行が生まれたりと、CIサービスにおいてもここ数年で色々な動きがありました。 特に技術記事・ブログのトレンドや企業のリクルート向け資料を見ていると、GitHub Actionsの利用が進んでいるような印象を受けます。 今回はそんなGitHub Actionsについて、Rust projectで使う際に知っておいた方がいいことやactionを紹介していきます。 以下の情報は執筆時点(2023年02月19日)のものに基づいています。閲覧時には無効・誤ったものになっている可能性がありますので、必ず最新の情報・状態を確認するようにしてください。 actions-rs(非推奨) まずはじめに、執筆時点では使用を控えた方がいいact
GitHub Actions Workflow Best Practices こんにちは。2022年新卒入社の上田です。現在は本配属前のジョブロで ABEMA に所属しております。 この記事では GitHub Actions workflow/job 作成に関するベストプラクティスをまとめました。 workflow/job 追加時に参照できるチェックリストとしてご利用いただけるような一記事として公開しています。堅牢で安全な CI/CD pipeline を作る参考になれば幸いです。 (ジョブロ:メディア事業部における新卒研修の一環として二ヶ月間実施される本配属前のジョブローテーション研修) 自己紹介 GitHub Actions は Beta v1 の頃から利用しており、個人としても peaceiris/actions-gh-pages などをはじめとして、いくつかのサードパーティー Ac
3秒まとめ Claude Code GitHub Actionsを使うと、@claudeでレビューからPR作成まで全部やってくれる /install-github-app一発で導入完了。めちゃくちゃ簡単 GitHub上でコミュニケーション完結するので、開発フローが超スムーズ Issue → 実装計画 → PR作成まで一気通貫でサポート *この記事は8割程度がAIのサポートにより執筆されていますが、スクリーンショットや使用感はヒューマンが試し、気づいたことを書いています どんな人向けの記事? レビュー作業に時間を取られがちなエンジニア GitHub Actionsを使った自動化に興味がある方 AI活用で開発効率を上げたいチーム Claude Codeって何?と思っている方 レビューって面倒じゃないですか? レビューは得意ですか? ぼくは正直、レビューがあまり得意じゃありません😅 「このコー
こんにちは。NewsPicks SREチームの 海老澤 です。 今回はGithub Actionsで実行していたテストを高速化したので紹介したいと思います。 課題 取り組み テストの並列化 AWS CodeBuildへの移行 CodeBuildの設定 コンピューティングタイプ トリガー buildspec.yml 結果 課題 NewsPicksでは Junitのテスト等をGithub Actions から実行しているのですが、2013年のサービス開始当初から存在する、一番コードベースが大きいリポジトリのビルド・テストの実行時間に 20~30分ほどかかっていました。 テスト自体はバグを産まないためにも必要なものですが、時間がかかるため開発効率が下がってしまいます。そのためテスト高速化の取り組みを行いました。 取り組み テストの高速化をする上でやったことは大きく下の二つです テストの並列化 G
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
大分時間が経ってしまいましたが、2022年8月31日 に開催された stand.fm 主催の TECH STAND #9 GitHub イベントに参加しました。 その際に呟いたやつが今回の記事の内容です 有り難いことに直ぐにフォロー頂きました。 あまり纏まった記事が見当たらなかったので、自分用のメモとしてまとめます。 他のCIにはあったアレ GitHub Actions を利用する前は、TravisCI や CircleCI を利用していました。 移行してから随分使ってないので、記憶が定かではないのですが という機能が標準であった気がします。 この機能の名前は何と呼ぶのでしょうか?地味だけれども、ないと困るアレですw GitHub Actions のリリース直後にこちらの機能と [ci skip] が使えずに後発なサービスなのにーと不満を覚えていました。 その後にアレの機能を実装したカスタム
こんにちは、2025/02からAndroidエンジニアとして入社したid:matsudamperです。 GitHub Actionsで外部のactionを使用する時に、どのようにバージョンを指定していますか? バージョンの指定方法とメリット、デメリット よく使われるactions/checkoutのREADMEのUsageでは以下のように書かれています。これでv4のタグが使用され、最新のv4.x.xに入った改善が使用側のコードの更新なしに使用する事ができます。 - uses: actions/checkout@v4 この書き方のメリットとデメリットは以下です。 メリット v4の間は勝手に更新され、新しいバージョンに書き換える手間が無い デメリット ビルドに再現性が無くなる 不具合が混入した場合、突然動かなくなる。後でRe-Runすると直っている。 actions/checkoutでもこれが
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Puppeteer + Lighthouse + GitHub Actions を使って Web アプリのフロントエンドパフォーマンスを定期計測するプロジェクトを作ってみたら良い感じだったので紹介です。 何を作った? このように GitHub Actions 上で 認証付きの Web アプリに対して Puppeteer 介し Lighthouse を定期実行し、結果を Datadog に送信するプロジェクトを作りました。 実際にそのプロジェクトの計測値を使った Datadog のダッシュボードはこちらです。 Webperf の主要指標をページ別に時系列で表示しています。 サンプルプロジェクトはこちらにあります。 以降で実装について簡単に解説します。 Puppeteer + Lighthouse によるパフォーマンス計測 Puppeteer + Lighthouse によるパフォーマンス計測
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 ensure that GitHub
まぁよくやられている話なんだけど。 自動テスト頑張りましょうみたいな話をしても、大体そうですねで終わる。これには色々理由もあって、3分くらい考えても テスト書く時間があったらまずはプロダクションコードの実装を終わらせろや、そうじゃないとリリース遅延するだろうがみたいに怒られる 長期的はリグレッションテストが楽になるよ、アジリティが高まるよってわかっていても、特に新規開発とかで仕様が色々変わる中でテストコードのメンテが負債になる そもそもメンテナブルなテストコードを書くのが大変 みたいな話になる。 それはそれで根深い問題なんだけど、頭痛くなるし辛くなるからそういう難しい話はやめたい。人生は楽しむべきであって、頭痛くなるために生きているのではない。何もしてないのにそもそも頭痛いし。 最近、「あなたのプルリクエストでテストカバレッジがどれだけ増減したんですか」というのを無条件でコメント投稿してや
こんにちは。皆さんは自身がメンテナンスするソフトウェアが依存するパッケージの更新、いわゆるdependency updateをどのような形で行っていますか? SmartBankが提供するサービスB/43の開発では主にGitHubのDependabot version updates機能を用いて定期的なdependency updateを行っています*1。これは簡単にいえばGitHub repositoryにYAMLファイルを置いておくだけで自動的かつ定期的にversion updateのpull requestを作ってくれる便利なやつです。 便利ではあるのですが、アプリケーション規模やチーム体制によっては日々作成されるpull requestをさばくのに苦労することがあります。本記事ではそのような運用課題を解決するために導入した、GitHub Appを使った自動マージについて解説します。
スタディスト開発ブログ Advent Calendar 2021の13日目の記事です。 こんにちは、SRE Unit の wind-up-bird です。以前、 Serverless Framework を移行しているお話を書きましたが、今回は移行シリーズ第2弾ということで、 Terraform Cloud を Terraform on GitHub Actions に移行したお話をお届けしたいと思います。 # 移行前の運用スタディストではこれまで Terraform Cloud の Team & Governance プランを契約していました。移行前の Terraform による開発の流れは、以下のとおりです。 Terraform Cloud 上で Workspace を作成し、Version control workflow を利用する。Workspace には環境変数として、 AWS
こんにちは。技術部の池田です。 この記事では、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の本番環
tl;dr; 検証内容 サンプルコード masterブランチに普通にpushした時 PullRequestに対してpushした場合 pushイベントの結果 pull_requestイベントの結果 解説 2021年01月08日 追記 GITHUB_SHAが異なることで何が困るか 余談:tfnotifyでpull_requestイベントの時にもPullRequestにコメントをつけたい FAQ Q. だったらpull_requestは不要では? 今の心境 tl;dr; タイトルが全て 検証内容 サンプルコード GitHub Actionsで使える(事前定義済みの)環境変数 *1を列挙するだけのシンプルなワークフローです on: - push - pull_request jobs: show_env: runs-on: ubuntu-latest steps: - run: env | grep
Claude Code Action は Claude Code を GitHub Actions のワークフローに統合するためのアクションです。これを使用することで、GitHub 上でコードの生成やレビューを AI に依頼することができます。 Claude Code Action は Claude Code を GitHub Actions のワークフローに統合するためのアクションです。これを使用することで、GitHub 上でコードの生成やレビューを AI に依頼できます。 Claude Code Action のセットアップ Claude Code Action のセットアップは非常に簡単です。ターミナル上で Claude Code を使用してコマンドを実行するだけです。前提として Claude Code をインストールしておく必要があります。 npm install -g @anth
先日起きた tj-actions や reviewdog のセキュリティインシデントのレポートを読みました。 その内容を個人的な検証結果や感想を挟みつつかいつまんで書きたいと思います。 詳細は原文を読んでください。 なお、侵害された repository 及び tag は全て修正され、盗まれた Personal Access Token (PAT) も revoke されているはずです。 攻撃の流れ tj-actions/changed-files が侵害されるまでに複数の PAT の流出及びリポジトリの侵害が連鎖的に起こっています。 つまり tj-actions/changed-files が直接的にいきなり侵害されたというより、複数のリポジトリをいわば踏み台のようにして侵害したという感じでしょうか。 攻撃者は PAT が盗まれたりした GitHub Account とは別に複数の Gi
ACS事業部亀崎です。 GitHub Universe'24 で紹介され、でもそこまで大きく取り上げられていない機能を1つご紹介します。 それが GitHub Immutable Actoinです。 https://gh.io/immutable-actions 現時点ではPublic Previewという状態です。 Immutable Actionsとは 公開されている情報も交えてご紹介しましょう。 github.com github.com みなさんご存知のように GitHub Actionは標準ではGitHub Repositoryを使って提供します。 しかし昨今のSoftware Supply Chain Securityの動向もあり、できる限り外部からなにか不正なものが紛れ込むリスクを減らしたい、そういうニーズが広がっていると思います。 そこで利用されるのがImmutable A
Goのライブラリを提供している場合、Goの最新の安定バージョンでテストしたくなることがあるでしょう。具体的にはマイナーバージョンの直近2バージョン、今だと1.18と1.17です。GitHub Actions定義への記述は以下のようになるでしょう。 jobs: test: runs-on: ubuntu-latest strategy: matrix: go-version: ['1.17', '1.18'] steps: - uses: actions/setup-go@v3 with: go-version: ${{ matrix.go-version }} - run: go test ./... しかしこのようにベタに書いてしまうと、Goのバージョンが上がったときにチマチマ上げるのが地味にめんどくさい。なのでこれを動的に生成したい。 これは事前にGoの安定バージョン一覧を取得するjo
AI開発ツールDevinが作成したPull Requestに対して、セキュリティと品質を確保するために2人の承認を必要とする実装方法について解説します。 背景 newmoでも少し前からDevinを利用して開発を行っています。 Devinを利用するフローは、以下のような感じになります。 エンジニアがSlackやDevinのWeb UIからタスクを依頼 DevinがGitHubにPull Requestを作成 エンジニアは必要に応じてSlackやPull Request上でコメント Devinがコードを修正 問題なければ承認してマージ devin-task-flow このフローには、エンジニア一人が指示して書かれたコードをそのエンジニア自身が承認してマージできてしまうという課題があります。 自分のPCでコーディングのためのAIエージェントを使う場合には、Pull Requestはエンジニアのア
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く