GitHub Dependabotが自動作成してくれるPRの中で、パッチバージョンの更新だけAutoMergeする 吉川@広島です。 先日、 GitHubにDependabotを導入して依存ライブラリを自動アップデートする | DevelopersIO という記事を書きました。さらに掲題のことを実現するにはどうすれば良いのかなーと思っていたところ、ちょうどはてなブックマークで下のドキュメントが浮上していて解決できましたので、その方法を紹介したいと思います。 [B! github] Automating Dependabot with GitHub Actions - GitHub Docs Automating Dependabot with GitHub Actions - GitHub Docs TL;DR GitHub DependabotでPRを自動作成する GitHub Acti
先月、とある GitHub リポジトリで使っている Dependabot が送ってくる Pull request の CI が軒並み落ちるようになり、状況を見てみるとどうやらリポジトリの Secrets がうまく Workflow のジョブに渡せていない事が原因の様でした。 公式ブログによると 2021 年 3 月 1 日以降、 Dependabot が特定のいくつかのトリガーにより開始した Workflow (※) では Secrets が読み込めなくなり、また GITHUB_TOKEN についても書き込み権限が剥奪され、リポジトリへの書き込み操作ができなくなってしまった様です。 具体的には、 Dependabot からの Pull request は書き込み権限を有さないユーザーからの物と同様 (Fork 経由と同様) になっている様で、元々このポリシーについては去年の記事 Keepi
Dependabot及びGitHub Actionsについて Dependabotは、依存関係を最新に保つためのPull Requestを作成します。GitHub Actionsを使って、それらのPull Requestが作成されたときに自動化されたタスクを実行できます。 たとえば、追加の成果物のフェッチ、ラベルの追加、テストの実行、あるいはPull Requestの変更ができます。 イベントへの応答 Dependabot は、pull request とコメントで GitHub Actions ワークフローをトリガーできます。ただし、特定のイベントは異なる方法で処理されます。 pull_request、pull_request_review、pull_request_review_comment、push、create、deployment、および deployment_status イ
最近GitHub Actionを触っていて、タイトル通りon: pull_requestとon: pull_requestの実行コンテキスト等の違いによって、 大分ハマったので、それぞれの違いとかを調べてみたのでMEMOしておきます。 https://github.com/features/actions on: pull_requestとon: pull_request_targetの違い 基本的には実行コンテキストと与えられる権限が違うようです。 on: pull_request イベントはbaseのリポジトリに送信され、作成されたPR上でのworkflowの設定が利用される For pull requests from a forked repository to the base repository, GitHub sends the pull_request, issue_co
Dependabot のPull Request(以下PR)が作られた際に開始したGithub Actionsワークフローが Secrets を参照できずに失敗していたので原因を調べてみました。 2021/3/1から適用になった以下のUpdateが影響していて、 Dependabot から実行される Github Actionsワークフローは読み取りだけが可能な GITHUB_TOKEN のみ使うことができ、いかなる Secrets も使えなくなるという変更が原因でした。 github.blog なので、例えばpushイベントトリガーで実行されるワークフローの中で Secrets として追加しておいたPersonal access tokensを使って、取得したカバレッジのサマリをコメントで追加したり、自動でラベルを追加するといった書き込み(write)権限が必要な場合は、ワークフローが落
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
はじめに このガイドでは、Rubyアプリケーションのビルドとテストを行う継続的インテグレーション(CI)ワークフローの作成方法を紹介します。 CIテストにパスしたなら、コードをデプロイしたりgemを公開したりすることになるでしょう。 前提条件 Ruby、YAML、ワークフローの設定オプションと、ワークフローファイルの作成方法についての基本的な知識を持っておくことをおすすめします。 詳細については、次を参照してください。 GitHub Actions について 20 分で Ruby Ruby スターター ワークフローの使用 すぐに開始するには、リポジトリの .github/workflows ディレクトリにスターター ワークフローを追加します。 GitHub では、ほとんどの Ruby プロジェクトで使用できる Ruby 用のスターター ワークフローが提供されています。 このガイドの以降のセ
下記の記事を読んで GitHub Actions の setup-go や setup-node で指定されるバージョンを go.mod や .node-version から取ってくる - stefafafan の fa は3つです blog.stenyan.jp これは便利だ!と手元のsetup-xxxを上記記事での指定方法にしようとしたらRubyはちょっと事情が違っていた Rubyの場合はruby/setup-rubyを使用しているが、他の言語のように.xxx-version-fileでの指定ではなく ruby-versionで指定するようになっていた(v1.115.3時点) 次のように指定することで.ruby-versionもしくは.tool-versionのバージョンを読み取ってくれる .ruby-version,.tool-versionの順に探し存在するファイルからバージョン情
その昔、初めてのサーバーレスアプリケーション開発というブログを書きました。 このシリーズを通して出来上がるものは、AWSのコードシリーズを用いてAWSリソースをデプロイするためのパイプラインです。 時は流れ、2020年。同じような仕組みを作るのであればCDKとGithub Actions使いたいという思いに駆られたので、こんな感じのパイプラインを作成してみました。 今回作成したコードは以下のリポジトリにあげています。 cdk-github-actions 目次 CDKとGithub Actions 今回構築するアプリケーションの全体構成はこちら。 CDKで「クライアントからリクエストを受けて文字列を返却する」簡単なアプリケーションを作成します。 AWSにデプロイされるまでの流れは以下のようになります。 ローカルでCDKを使ったアプリケーションを作成 featureブランチを作成しmaste
GitHub Actions入門 ── ワークフローの基本的な構造からOIDCによる外部サービス認証まで GitHubが公式に提供するGitHub Actionsは、後発ながらよく使われるワークフローエンジンとなっています。本記事では、藤吾郎(gfx)さんが、典型的なCI/CDのユースケースに即したワークフローの設定と管理について解説するとともに、注目されているGitHub OIDC(OpenID Connect)の利用についても紹介します。 GitHub Actionsは、GitHubが提供するCI/CDのためのワークフローエンジンです。ワークフローエンジンは、ビルド、テスト、デプロイといったCI/CD関連のワークフローを実行し、定期実行するワークフローを管理するなど、開発におけるソフトウェア実行の自動化を担います。 ▶ GitHub Actions - アイデアからリリースまでのワーク
この記事について 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
ProductSupercharging GitHub Actions with Job SummariesYou can now output and group custom Markdown content on the Actions run summary page. The same familiar functionality that powers pull requests, issues, and README files has come to GitHub Actions! We’re thrilled to announce GitHub Actions Job Summaries, which allow for custom Markdown content on the run summary generated by each job. Custom Ma
概要 何度も調べて何度もテストしたりしたので、多用するものをまとめていきたい。 項目 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でAWSの永続的なクレデンシャルを渡すことなくIAM Roleが利用できるようになったようです アクセスキー、撲滅してますか? ナカヤマです。 目黒方面より、以下のような福音が聞こえてきました。 何がどのくらい最高かと言いますと! GitHub Actions に AWS クレデンシャルを直接渡さずに IAM ロールが使えるようになることがまず最高で! クレデンシャル直渡しを回避するためだけの Self-hosted runner が必要なくなるところも最高です!!✨✨✨ https://t.co/IUQmfzkIB0 — Tori Hara (@toricls) September 15, 2021 元ネタはこちら。 Ok I blogged about it. That's how excited I am. 1. Deploy this CFN templ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く