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
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
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
はじめに 本番リリース用ブランチへのマージ前に、検証用ブランチにマージして動作確認するという運用ルールになっているケースは比較的多いかと思います。 しかし本番リリース用ブランチへのPR時に、本当に検証用ブランチにマージ済みかどうかレビューでチェックという運用だと見逃しが発生する可能性があるし面倒ですよね。 そんな不便を解消するために作ったアクションを紹介します。 何が出来るの？ pull_requestイベントのアクションとして実行することで、指定ブランチにマージされていなかったらコメントで指摘してくれるようになります。 使い方 masterブランチへのPR時に必ずstagingブランチにマージされていることを検証したい場合の設定例。 name: Check merged on: pull_request: branches: - master jobs: check-staging: r
はじめに GitHub Actionsのワークフローを作成しようと思ってサンプルなどを検索した際、以下のような表記が使われているのを見かけると思います。 ${{ github.event.pull_request.title }} これはプルリクエストのタイトルを取得する場合ですが、他にもワークフロー上で取得できる情報は数多くあります。GitHub上で作業を自動化しようと思ったときに、他にどんな情報が取得できるのか、欲しい情報を取得するにはどのプロパティを使うのか、などを調べる必要があります。この記事ではそれらをどのように調べれば良いのかを解説します。 ワークフローのトリガーイベント GitHub Actionsワークフローが実行される契機となるイベントは多岐にわたります。ユーザーやリポジトリに対する変更、プッシュやプルリクエストの作成など、様々なトリガーがあります。 どのようなトリガーが
要するに、staging環境とproduction環境でやることは一緒だけど環境変数だけ切り替えて利用したい ということを実現したい。 変数受け渡し周りで意外とハマったのでメモしておく。 ブランチ・デプロイ戦略 Gitlab Flow がわかりやすいのでこれベースで説明していく。 以下のデプロイフローを想定。 環境毎のブランチにpushされると、GitHub Actionsでその環境にデプロイする - developブランチにpushすると、develop環境にデプロイ - stagingブランチにpushすると、staging環境にデプロイ - productionブランチにpushすると、production環境にデプロイ ファイル構成設計 以下のような感じで置くイメージ .github/ workflows/ deploy.yaml > 共通で利用できる実際に実行するワークフローya
TL;DR GitHub Actions の if などで用いる比較は型厳密 公式のベストプラクティス等がないのでアクションごとに出力が異なる アクションを使うときはドキュメントを読む, アクションを作るときはドキュメントを書こう 概要 値を真偽値 true と比較する以下の if のうち, 条件が真と判定されるのは1つだけ: if: 'true' == true # false if: 'false' == true # false if: '1' == true # TRUE! if: '0' == true # false
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完了したら通知するやつ、macOSだと `gh run watch && osascript -e 'display notification "run is done!" with title "Terminal"'` みたいなのでデスクトップ通知出せて便利そう / “Work with GitHub Actions in your terminal with GitHub CLI - The GitHub Blog” https://t.co/WyoKK8mRUX— ohbarye (@ohbarye) 2021年4月16日 Work with GitHub Actions in your terminal with GitHub CLI - The GitHub Blogにてアナウンスされた通りGitHub公式CLIのghでworkflowの情報を取れるようになった。 記事中で紹
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
こんにちは。スタディサプリのQAチームです。 今回のBlogではスタディサプリで実施している自動化テストの一部の取り組みについて紹介させていただきます。 なお、スタディサプリQAチームの特性を活かし、本記事については日英中３言語で記載します。より多くのオーディエンスに読んで頂ければ嬉しいです。 自動化する動機 まず、なぜ自動化テストを導入するのでしょうか。 1. 新規機能が追加される度に、既存機能への影響を確認するための回帰テストをしなければなりません。 2. 繰り返し同じテストを手動実行することにより、テストコストが増加します。 3. 人間が実施すると、人為的ミスによる不具合の検出漏れが発生してしまう可能性が否定できません。 そのため、品質を担保した上でより早くリリースすることを目的とし自動化を導入しました。 現在の開発およびテストフロー QAが回帰テストの自動化テストスクリプトをGit
name: call on: workflow_call: jobs: myjob: runs-on: ubuntu-20.04 steps: - run: echo "HELLO CALL" name: main on: push: jobs: myjob: runs-on: ubuntu-20.04 steps: - run: echo "HELLO MAIN" call-workflow: needs: [myjob] uses: ./.github/workflows/call.yml 実行されたWorkflowのSummaryを見ると、次のようになっている。 このとき、呼び出されたWorkflow（call.yml）は、呼び出したWorkflow（main.yml）の一部であるかのような扱いになっている。 たとえば、呼び出された側のgithub contextは、呼び出した側の値
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
公開日 2020.6.7更新日 2020.6.8カテゴリ：Githubタグ：Github,GithubActions
ProductSecuritySafeguard your containers with new container signing capability in GitHub ActionsGitHub has partnered with the OpenSSF and Project Sigstore to add container image signing to our default “Publish Docker Container” workflow. As developers have leaned into cloud native projects for scale and maintainability, the popularity of containers has exploded. With 92% of organizations leveragin
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
こんにちは、株式会社ウイングドアの田上です。 弊社では開発業務にGitHubを使っています。 折角GitHubを使っているので、 GitHub Actionsを使ってCI（継続的インテグレーション）を実施したいなと思い、やってみました💪 今回は弊社で多いLaravel案件でも使えるように、 表題の通りGitHub Actions + LaravelでのCIを構築してみます。 GitHub Actionsとは プッシュ、Issue、リリースなどのGitHubプラットフォームのイベントをトリガーとしてワークフローを起動しましょう。コミュニティが開発・保守し、ユーザが熟知・愛用しているサービスについて、対応するアクションを組み合わせて設定できます。 引用元：Actions | GitHub はじめかた GitHubにLaravelのリモートリポジトリを作成して、Actionsをクリックします。
GitHub Actionsが不調なときにPushすると、後で回復してもワークフローが実行されなかったりする。これだと記事を投稿しても反映されなかったりして困るので、手動でも実行できるようにした。 ワークフローの定義に、workflow_dispatchイベントに対応していることを明記するだけで良い。 diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml index 67d24e3c..e431c5c6 100644 --- a/.github/workflows/publish.yml +++ b/.github/workflows/publish.yml @@ -4,6 +4,7 @@ on: push: branches: - main + workflow_dispatch: jobs:
CX事業本部@大阪の岩田です。AWSを利用した開発のCI/CDでは xxxブランチにマージされたらdev用AWSアカウントに自動デプロイする yyyブランチにマージされたらstg用AWSアカウントに自動デプロイする リリースタグが付与されたらprd用AWSアカウントに自動デプロイする のようなデプロイ戦略は良くある話だと思います。実際にはprd環境へのデプロイには別途承認アクションを挟みたいとか、そういった要件も想定されますが、一旦そういうのは無視してワークフローの構成は全環境で共通とした場合、トリガーイベントに応じて変更したいのはAWSアカウントIDのみです。この場合、環境毎にワークフローファイルを作成すると重複が多くなってしまうので、できれば1つのワークフローファイルで全環境のデプロイに対応したいところです。どうすれば単一のワークフローファイルで複数AWSアカウントへのデプロイに対応で
こんにちは、CX 事業本部 Delivery 部の若槻です。 おそらく GitHub Actions で最も使われているであろう actions/checkout アクションですが、2023 年 9 月に V4 がリリースされていました。 現在の最新バージョンは v4.1.1 となっています。 V3 からの変更点 現時点での V3 からの変更点は以下の通りです。 Update to node20 Support fetching without the --progress option Add support for partial checkout filters アクションのデフォルトランタイムとして Node.js 20 が使われるようにする変更と、コードのフェッチ中にプログレスバーを非表示にする --progress フラグ、および必要なコードのみチェックアウト可能にする par
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/
GitHub Actions is a third-party CI/CD solution popular among many Google Cloud customers and developers. When a GitHub Actions Workflow needs to read or mutate resources on Google Cloud – such as publishing a container to Artifact Registry or deploying a new service with Cloud Run – it must first authenticate. Traditionally, authenticating from GitHub Actions to Google Cloud required exporting and
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)権限が必要な場合は、ワークフローが落
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
version: 0.2 run-as: Linux-user-name env: variables: key: "value" key: "value" phases: install: run-as: Linux-user-name runtime-versions: runtime: version commands: - command - command pre_build: run-as: Linux-user-name on-failure: ABORT | CONTINUE commands: - command - command build: run-as: Linux-user-name commands: - command - command post_build: run-as: Linux-user-name commands: - command - co
はじめに ある開発プロジェクトにて CI 基盤として CircleCI を使用していましたが、様々な理由があり GitHub Actions への移行を決定しました。 移行に伴って CircleCI の設定ファイルを GitHub Actions 用に書き換える必要がありますが、GitHub Actions Importer を利用すれば概ね自動で移行できます。 本記事では、 GitHub Actions Importer では対応しきれていなかった課題や苦労を共有します。同様の状況に直面する方々の参考になれば幸いです。 主なトピックは以下の3点です👇 ジョブ間のデータ共有 並列化インスタンスからのアーティファクト収集 ジョブの途中成功終了 🔄 ジョブ間のデータ共有 ビルド生成物や中間ファイルなど、ジョブ間でデータを共有したいケースがあります。 GitHub Actions 公式の C
MoTではマイクロサービスアーキテクチャを採用しており、標準技術スタックにGitHub Actionsを採用しています。本記事では数多くのリポジトリのCI/CDパイプラインを管理していくアプローチを紹介します。 はじめに昨年10月頃にSREグループにjoinした古越です。クラウドインフラの構築、運用とアプリケーションのCI/CD構成などを担当しています。 MoTの中での開発体験向上はSREグループのミッションの一つです。CI/CDについては開発体験とアプリケーションの品質に大きく寄与する要素だと考えています。 MoTのSREグループが構築するサービスのCI/CDにはTravisCIが長く使われていました。最近になりGitHub Actionsを使う方針に切り替えており、現在は移行途中になります。移行については別記事で触れようと思いますが、移行過程でCI/CDの共通化や管理上の課題が幾つか明
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
ProductHow to start using reusable workflows with GitHub ActionsReusable workflows offer a simple and powerful way to avoid copying and pasting workflows across your repositories. From automating repetitive tasks to building continuous integration and continuous deployment pipelines, you can do a lot with GitHub Actions. But until recently, you had to copy and paste YAML files from one repository
GitHubのDependaBotによる脆弱性対策のPRは対応コストが省けるスグレモノですが、そのままMergeした場合に起こりうるトラブルまでは防げないこともあります。確認しておきたい事項をPR作成に連動させてコメントとして追加できるようにしてみました。 ライブラリの脆弱性対応はトラブルが発生する前に着手しておきたいものですが、各ライブラリの最新情報キャッチアップまでは中々手が届きません。そんな時に役に立つのがDependaBot。 ただ「このbotを導入すれば夢のように全てが片付く」というわけでもありません。実際の実務にうまく取り込む際にやっておきたい事をToDoとしてコメント追加してみました。 コメントでToDoを追加する DependaBotによるPRはあくまでもライブラリの依存状態に関する情報のみ記載されます。プロジェクトでの確認事項をTODOとして自動で追加しておくと手間が省け
今回は、GitHub Pro または GitHub Team 以上のプランで利用できる次の3機能を試してみます。これらの機能により、Environment ごとに異なるブランチを対応付けて、ブランチごとに実行させるジョブや、参照させる secrets および variables を制御することができます。 Deployment branches Environment secrets Environment variables 試してみた GitHub Team のアカウントで試していきます。 Environment の作成 リポジトリの Settings > Environments より Environments のメニューを開きます。（必要なプランでない場合はメニューは表示されません） New environment をクリックします。 Environment の名前を指定し、Con
AWS と GitHub Actions の OIDC 接続で Pull Request の Merge のみをトリガーとする際の権限リソースを AWS CDK で作成する こんにちは、CX 事業本部 Delivery 部の若槻です。 GitHub Actions 上で AWS に接続したい場合は、OIDC（Open ID Connect）による AssumeRole が推奨されています。 OIDC ではアクセスキーを使う必要がないため、安全に AWS の一時クレデンシャルを取得することができます。 今回は、AWS と GitHub Actions の OIDC 連携で Pull Request の Merge をアクショントリガーとして AWS CDK によるデプロイを行いたい際の権限リソースを、 AWS CDK で作成しつつ、必要最低限のポリシーについて確認をしてみました。 OIDC
はじめに こんにちは、LINE上で動くおくすり連絡帳 Pocket Musubi というサービスを開発している種岡です。 ある日チーム内メンバーから CI実行時間がとても長くなり困っている というアラートが発せられました。 実際に確認しに行くと、開発初期の頃は5分ぐらいだったテストが、いつの間にか 20分 以上にもなっていました。 待ち時間は、DX体験を損なうだけでなく、本来できたはずである付加価値を生む開発時間を奪う側面も持ち合わせており、即刻対処すべき案件と捉えテストを早くするタスクに取り掛かりました。 結果、当サービス比ではありますが、3倍ほど早くすることができました。 そこで備忘録がてらこちらにまとめてみることにしました。 やったこと 全体の概要図は以下のようになります。 不要なステップの削除 サービスコンテナの利用 マトリクスを使ったテストの並列化 actions/cacheの利
Pluto を使うと Kubernetes マニフェストの apiVersion に対して deprecated（非推奨）と removed（削除）を検出できる．警告自体は Deprecated API Migration Guide | Kubernetes を見れば確認できるし，kubectl apply コマンドを実行したときにも表示されるけど，Pluto は実行前に確認できて便利！パイプラインに組み込むのも良し！ github.com セットアップ Pluto CLI は macOS なら Homebrew を使えば簡単にセットアップできる．今回は現時点で最新となる Pluto v5.10.2 を前提とする． $ brew install FairwindsOps/tap/pluto $ pluto version Version:5.10.2 Commit:0070fa70364
GitHub Actions ワークフローで Configuration variables (構成変数) がサポートされました。 GitHub Actions - Support for configuration variables in workflows | GitHub Changelog 従来もワークフローファイルに env キーワードで環境変数を宣言することはできましたが、ハードコーディングだしワークフローファイル内でしか利用できません[1]。API Key などの機密情報はシークレットとして外部から設定できます。シークレットはいったん設定してしまうと値を見ることはできないし[2]、あくまで機密情報用なので変数として使うには適していません。ということで、外部から設定可能な環境変数は GitHub Action 登場当初から「なぜないんだろう？」と思っていた機能です。
事前準備の状況事前準備編でリモートリポジトリにlib,testのディレクトリ そしてFizzBuzzのコードとテストコードを準備しました。 現在のリポジトリは下図のようになっています。 【GitHub】ワークフローファイルを作成するGItHubActionsではリポジトリー毎に設定されたAction定義に沿ってワークフローが動き、jobを実行していきます。 基本的にはjobは並列実行です。 Action設定を行うにはリポジトリのActionsタブを開きます。 ワークフローファイルが存在していない場合は、リポジトリのコードなどから設定ファイルを表示してくれるようです。 今回使うリポジトリにはRubyのファイルがあるので、Rubyが出ていました。 まずはこの設定ファイルを元に設定してみます。 Set up this workflow を押してファイルを作成します。 設定ファイルがリポジトリ内に
はじめに この記事では、github actionsでdockerのbuildをキャッシュする方法を４つ調べたので、その比較を書いていきたいと思います。 結論だけ知りたい方は、こちら ベースコード 今回の比較で使うベースのサンプルコードです。 dockerのビルドにはbuild-push-actionを使い、push先にはgithub container registry(ghcr)を利用します。 Dockerfile FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build WORKDIR /myApp COPY ./myApp/myApp ./ RUN dotnet restore RUN dotnet publish -c Release -o /app --no-restore FROM mcr.microsoft.com/dotnet/aspn
qiita に記事があまりなかったので掲載しました。 github action の概念は知っているものの、コードかけない、めんどくさい、怖いと言う方が中にはいらっしゃるのではと思います。ここではそんな人達向けに記事を書きました。あくまできっかけづくりです。 サンプルコードがあった方がわかりやすいと思うので、ここではサンプルコードと合わせて解説します。 相当手抜きで解説しますが、ご了承願います。 Github Actionとは 一応一言で言うと github が提供する CICD のサービスです。 制約について公式ドキュメントだったり、色々な人の記事を読んでいただければと思います。 格納先 基本的に GitHub Actions は全て .github/workflow の配下におきます。yml 形式です。 つまり、my_repostiory というレポジトリがあったら、my_reposi
へいしゃでは、ソースコードのフォーマッターに Ormolu を利用しています。 インデント時のスペース数すらカスタマイズ不可なので好き嫌いが分かれるところですが、プロジェクト全体のコードを統一しておくとコードレビューの際にも有用なので入れています。 ちなみにスペース幅を4にしたくてフォークされた fourmolu というフォーマッターもあります。現在ではスペース数以外の設定もできるみたいです。 どちらも hls から利用可能なので、興味がある人は試してみると良いと思います。 また、ormolu のフォーマット結果で末尾カンマが気に入らない場合は google/ormolu の gfork ブランチを使ってみると良いかもしれません (フォーマット結果)。fourmolu も Add option for leading commas (and expand test suite) #17 で
この記事は Sansan Advent Calendar 2023 の13日目の記事です。および【R&D DevOps通信】の連載記事のひとつです。 こんにちは、研究開発部 Architectグループの藤岡です。 今回は部で運用しているCI/CDに関する取り組みについてお話しします。共通化のノウハウや、どういった種類のCI/CDを導入してコード品質を担保しているかといった話をしたいと思います。 そのまま使える実装例もあるので、是非参考にしてみてください。 目次 目次 CI/CD共通化 reviewdog による Pull Request へのコメント 導入しているCI/CD PythonのCI その他のCI CD 実装例 reusable workflows composite action reusable workflows を利用する例 release-drafter によるリリース
TL;DR; 公式Dockerイメージがないので、まずはdocker runしたコンテナ上にSelf-Hosted Runnerをインストールし、稼働させるところまでやってみました。 まとめ ~ Dockerfileを書くにあたって抑えたいポイント GitHubさんへのお願い まえおき GitHub Actions v2がGAになる直前に、Self-Hosted Runnerという新機能が追加されました。 これはCIのコントロールプレーンをSaaSに管理してもらい、ワーカーのみを自社ネットワーク内にデプロイできるという機能です。 例えばCIから利用する強い権限につながるクレデンシャル類を他社サービスに渡したくないが、かといって自社でCIをセルフホストするのも避けたい・・・という場合に必要になる機能です。 これまで、運用の手間をできるだけ減らしつつ、他社サービスにクレデンシャル類を直接渡した
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
