GitHub Actionsで実現する高度なイシュー管理: 安野たかひろ都知事選マニフェストリポジトリの自動化ワークフロー解説 - Sun wood AI labs.2
ワークフローの概要 このGitHub Actionsワークフローは以下の主要な機能を持っています： 新しいイシューが開かれたときに自動的に起動 イシューの内容を分析し、不適切なコンテンツをチェック 既存のイシューとの重複を検出 必要に応じてラベルを付与 ワークフローの詳細解説 トリガーとパーミッション設定 name: Issue Review on: issues: types: [opened] permissions: issues: write contents: read このセクションでは、ワークフローの名前を定義し、トリガー条件とパーミッションを設定しています。 on.issues.types: [opened]: 新しいイシューが開かれたときにワークフローが起動します。 permissions: ワークフローがイシューの読み書きと、リポジトリコンテンツの読み取りを行うための権
組織横断で中央管理するGitHub Actions Workflowを整備する
先日、GitHubのアップデートによりRequired workflowが使えるようになりました。 これにより、 Organization内のリポジトリに対して共通のWorkflowを設定できるようになりました。 スマートショッピングでは、さっそく組織横断でWorkflowを中央管理するリポジトリを作成し、運用を始めたので共有します。 Required workflowsを管理するリポジトリの設定 組織のプライベートリポジトリで使用する場合、 GitHub Actions でプライベートリポジトリの Action を共有できるようになったので試してみると同様のアクセス設定を行います。 Required workflowsの設定 Required workflowを使うための設定は、https://github.com/${org} を開き、 Settings > Actions > Gen
2022年に試した開発ワークフロー関係の機能やツール - Kengo's blog
数えてみたら意外と数あったのでまとめます。 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からCodeBuildに移行し、実行時間を35%削減した - Uzabase for Engineers
こんにちは。NewsPicks SREチームの 海老澤 です。 今回はGithub Actionsで実行していたテストを高速化したので紹介したいと思います。 課題 取り組み テストの並列化 AWS CodeBuildへの移行 CodeBuildの設定 コンピューティングタイプ トリガー buildspec.yml 結果 課題 NewsPicksでは Junitのテスト等をGithub Actions から実行しているのですが、2013年のサービス開始当初から存在する、一番コードベースが大きいリポジトリのビルド・テストの実行時間に 20~30分ほどかかっていました。 テスト自体はバグを産まないためにも必要なものですが、時間がかかるため開発効率が下がってしまいます。そのためテスト高速化の取り組みを行いました。 取り組み テストの高速化をする上でやったことは大きく下の二つです テストの並列化 G
Cloud RunをGithub ActionsとTerraformで管理する
. ├── backend.conf ├── main.tf ├── registry.tf ├── terraform.tfvars └── variables.tf main.tfでは、terraformのバージョン指定とサービスアカウントのroleの指定が定義されています。repo_nameは権限を与えるgithubリポジトリなので、この段階で連携するリポジトリを決めておく必要があります。 terraform { required_version = "~> 1.1.9" backend "gcs" { prefix = "terraform/state" } } locals { cloudrun_roles = [ "roles/run.developer", "roles/iam.serviceAccountUser" ] } resource "google_project_
Github Actions チートシート
概要 何度も調べて何度もテストしたりしたので、多用するものをまとめていきたい。 項目 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
microCMS + Gatsby + GitHub Actions + S3 でJamStackのチュートリアル | DevelopersIO
What is Jamstack? ここ数年でよく聞くようになったワード。 Jamstackとはウェブサイトを構築および運用するための、技術の組み合わせです。 JavaScript・API・事前にレンダリングされたMarkupの組み合わせでJamStackとのこと。 (以前はJAMStackといってたけど、最近はJamstackだったりする) Jamstackは、 「ウェブをより速く・より安全に・より簡単に拡張できるように設計されたアーキテクチャ」であり、 生産性を最大化するツールやフレームワーク、ライブラリやワークフローなどを 組み合わせて構築されるもの、とのことです。 ※jamstack.orgより 従来のCMSではアクセスがあったとき動的にページを生成しますが、 Jamstackではデプロイ以前に必要なページを生成します。 具体的には、下記。 Webサイトのフロントエンド全体(HTM
GitHub Actionsを使ったDDoSに巻き込まれた - 私が歌川です
事例集です。 きのう、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を
AWS CDKとGithub ActionsでIAMユーザーを管理してみた【CI/CD】 - Qiita
TL;DR 先日こちらの記事で書いたものの続きと言いますか、運用に導入してみたのでそのお話です。 今まではIAMユーザー作成に関してTerraformで管理をしていたのですが、新しいアカウントができたのでタイミング的にちょうどいいこともありCDKでIAMユーザーの管理をしてみようと思いました。 またデプロイに関しては、Github Actionsを利用することにしました。 AWS CDKの実装やGithub Actionsに至った理由などをお伝えしていきたいと思います。 IAM管理リソース 現在Terraformで管理されているIAM周りのリソースに関して、至ってシンプルなものです。 IAMユーザー IAMロール IAMポリシー アカウントパスワードポリシー なんの変哲も無い構成だと思います。 ちなみに既存のTerraformはこんな感じになっています。 $ tree . ├── READ
Github Actionsにて自動的にビルドする環境作成(Android編) - Qiita
概要 Github ActionsでのCI/CDの検証を行いました。 その中で他の開発プロジェクトにも定常的に適用できるようなテンプレートを作成しました。 作成したテンプレートのプロジェクトは以下になります。 github-actions-examples 今回このような環境の構築にあたっての備忘録としてここに記述しておきます。 また上記のプロジェクトは他の様々な環境において試したものであり、今回はGithub Actionsにおける Androidアプリ での自動ビルドの手法についてを中心に紹介します。 Webサイトでの自動デプロイおよびGithub Actionsでの基本的な設定についてなどはこちらの記事を参照してください。 Github Actionsにて自動的にデプロイする環境作成(Webサイト編) またUnityでの自動ビルドの方法についてはこちらを参照してください。 Githu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - infracost/actions: GitHub Action for Infracost. See cloud cost estimates for Terraform in pull requests. 💰📉 Love your cloud bill!
CI / CD Deployment of Conditional Access Policies for a Zero Trust Architecture Framework using Terraform and GitHub Actions
Required workflows - GitHub Enterprise Server 3.11 Docs