AWS Configの外部リソース(GitLab)に対するカスタムルール構築をTerraformで自動化する - Qiita
はじめに AWS Config記事第2弾。 前回は、AWS管理リソースに対するルールと修復アクションの作成を自動化したが、今回は、外部のリソースをカスタムルールで検査してみる。 前回記事 本記事に必要な前提知識は以下の通り。 AWS＋Terraformの基本的な知識 AWS Configの基本的な知識 AWS SDK for Python (Boto3)の基本的な知識 カスタムリソースの定義 まずは、検出する対象のカスタムリソースを定義する必要がある。 カスタムリソースはAWS公式の開発者ガイドを参考にしながら作成する。 なお、ドキュメント中に突如mvn packageというコマンドが登場するが、おそらく間違っていて、cfn packageが正しいと思われる。 上記ページに書いてあるcfn init後に、mycustomnamespace-testing-wordpress.jsonの代わ
Github Actionsによる継続的デリバリーの構築 - SO Technologies 開発者ブログ
CTO室所属の高橋と申します。皆からはニャンさんと呼ばれております。そして私は特に無茶振りはされていません。 さて、developブランチに変更が入ったらdev環境にリリース、mainブランチに変更が入ったら本番環境にリリースを行う仕組み、いわゆる継続的デリバリーを構築しているプロジェクトは多いことと思う。我々のチームではCircle CIで行なっていたが事情があってGithub Actionsに移行することになった。ところがGithub Actionsではdevリリースと本番リリースの手順をどう共通化すればいいのか分からず迷ってしまった。 近年のソフトウェア開発の現場ではCI/CDは当たり前になっているが、もはや当たり前すぎて逆にまとまった情報がネット上にないのかもしれない。であれば得られた知見は共有しておくべきだろう。 結論から言うとジョブの共通化には再利用可能なワークフロー用いるのが
GitHub Actionsを用いた自動テストの実行と結果集計 - Qiita
1. はじめに GitHub Actionsを用いて自動テストの実行と結果の集計を行う方法を説明します。 具体的には、ソースコードがGitHubへpushされたタイミングで、pythonで書かれたテストをpytestを使って実行し、GitHub上に下図のサマリを表示します。 今回、GitHub Actionsを初めて使ったので、学習のためにGitHub Actionsの基本についても触れています。 2. GitHub Actionsとは GitHubのCI/CDツール。 push, pull requestなどのGiHub上のアクティビティやスケジュールした時間、外部イベントをトリガーとして、ワークフローを作成できます。 特徴 Linux, macOS, Windowsすべてのコンテナに対応 Node.js, Python, Java, Rubyなど、様々な言語に対応 複数のジョブを並行し
GithubActionsでSwaggerドキュメントを自動更新して、PRへコメントをつける - Qiita
はじめに いくつかのプロジェクトにてSwaggerを利用した、API仕様書の運用をしています。 エンドポイントの追加・変更などがあった場合に、ドキュメントの更新を忘れがちなので、github上でPRを作成した際に、swaggerドキュメント生成のためのコマンドを自動実行し、差分があった場合はPR上にコメントするようなフローを作成しました。 使用言語及びライブラリは以下。 https://github.com/swaggo/gin-swagger 前提として、DockerfileやMakefile等でSwaggerドキュメントの生成ができている状態とします。 (各種ライブラリなどで設定方法・実行方法は違うと思うので、Swaggerの設定部分については割愛します。) 実行ファイル 全体の設定ファイルです。以下で一つ一つ見ていきます。 PRのオープン・プッシュのイベントでトリガーされます。 na
GitHub Actionsと仲良くなったよ | IIJ Engineers Blog
ぬるぽよりにるぽ、ヘビや宝石やイルカよりホリネズミやカニやアザラシが好きです。クジラに乗っていたらとある船の航海長に出会い意気投合しました。その後、帆船と衝突し大変な目にあいました。ペンギンとは未だにわかりあえません。 はじめまして はじめまして、うちやまです。バックエンドのアプリケーション開発を主にしています。 今回はCI/CDでGitHub Actionsに移行したことについてざっくばらんにお話しようと思います。私を含めチームメンバーはGitHub Actionsを知ってるけどそこまで使ってないし知らない状態です。GitHub Actionsに怒られイライラし、最終的に仲良くなっていった流れを書いていこうと思います。GitHub Actionsの深い技術要素というより、とりあえず移行してみて動くようになったよということを書いていくので、難しい話はしない予定です (というより、できません
GitHub Actions内でPytestを実行して失敗したテストの詳細をPR内で直接表示させよう！ - Qiita
GitHub Actions内でPytestを実行して失敗したテストの詳細をPR内で直接表示させよう！DjangopytestGitHubActions 概要 GitHub Actionsを使ってテストを実行する際に失敗したテストはログを見るかと思います テストが少なければいいですがプロジェクトが大きくなるにつれてどんどん探すのが困難になってくるので PR内で書いたテストコードに失敗したテストの実行内容が表示されたら便利かと思います 今回はとあるライブラリを使って実現する方法について解説していきます 前提 フレームワークはDjangoを使用 テストフレームワークはPytestを使用 pytest-github-actions-annotate-failures pytest-github-actions-annotate-failuresを使うと
GitHub ActionsでPull Requestのコメントを更新する - tom-256.log
概要 一つのコメントを更新する 実装例 制限事項 複数のコメントを更新する 実装例 参考 概要 GitHub Actionsでコメントを更新する方法をまとめる サードパーティアクションはなるべく使わない 一つのコメントを更新する gh pr commentの--edit-lastを使う gh --version gh version 2.49.2 (2024-05-13) https://github.com/cli/cli/releases/tag/v2.49.2 https://cli.github.com/manual/gh_pr_comment --edit-last Edit the last comment of the same author 実装例 GitHub Actionsで下記のように書けば 初回はコメントを書く すでにコメントがあったらアップデートする という処理が
リリースされていない変更が溜まるのを防ぐGitHub Action「tocenbough」 - モナドとわたしとコモナド
チームでソフトウェア開発をするとき、一度のリリースに含まれる変更が多すぎることにより、動作検証に時間がかかったり、問題が発生した時の原因特定が難しくなることがある。これを防ぐため、tocenboughというGitHub Actionを作った。読み方はもちろん「とおせんぼう」だ。 github.com 内容は至ってシンプルで、前回のlatest releaseからのマージコミットの数を計算し、その数が閾値を上回ったら落ちるというだけのスクリプトである。かなり単純なので、動作を把握するにはソースを見てもらったほうが早いかもしれない。 # GitHubから最新のリリースのタグを取得する。これがプルリクエストの数をカウントする起点となる latest=$(curl -H "Authorization: Bearer ${{ inputs.token }}" --silent \ "https://
過去のGitHub Actionsのbuild時間を取得して集計してグラフにする - xuwei-k's blog
継続的にメンテナンスするのではなくて、雑な使い捨てでいいならshellscriptとjq職人芸でいけるので頑張ってしまったけれど、継続的にやるならもっと違うもので書いた方がメンテナンスしやすいと思います。 細かい部分はいくらでも改善の余地があるとは思いますが、とりあえず動いたのでヨシ・・・!? 以前も多少似たような何か作ったけど、こういうの誰か既にもっと綺麗に作ってないんですかね。 xuwei-k.hatenablog.com GitHub Actionsのログはデフォルトでは90日保存されてるはずなので、その程度の期間をなんとなく集計したいだけならば、こうやって後から集計するだけで十分ですね。 もちろん、yamlの内部の構造がすごく変わっていると集計が難しいか実質不可能になるリスクはありますが。 もっとしっかり計測したいならば、buildした時点で専用の場所に綺麗に記録して、他のもっとリ
GitHub Actionsにおける脅威と対策まとめ
はじめに こんにちは、サイボウズ24卒の@yuasaです。 サイボウズでは開発・運用系チームに所属する予定の新卒社員が研修の一環として、2週間を1タームとして3チームの体験に行きます。新卒社員の私が生産性向上チームの体験に行った際に、チーム内でGitHub Actionsを利用する際の脅威と対策について調査を行い、ドキュメント化した上で社内への共有を行いました。本記事では、そのドキュメントの一部を公開します。 対象読者 本記事の主な対象読者としては、以下のような方を想定しています。 GitHub Actionsを組織で利用しているが、特にセキュリティ対策を実施していない方 GitHub Actionsを組織で利用しており、部分的にセキュリティ対策を実施しているが、対策が十分かどうか分からない方 本記事がGitHub Actionsのセキュリティ対策を検討する上で参考になれば幸いです。 本記
GitLab IaC Scanning機能を利用する - TECHSTEP
今回はGitLab IaC Scanning機能を検証しました。 docs.gitlab.com 背景 GitLabのIaC ScanningはIaCファイルに対する静的解析機能を提供します。IaC Scanningの内部ではKICSというIac専用の静的解析ツールを実行しており、セキュリティの脆弱性やコンプライアンス的な問題点などを指摘します。 IaC Scanningの対象のIaCツールは複数あり、以下に対応しています。なお一つのリポジトリ上に複数のIaCツールファイルを配置する場合もサポートします。 Ansible AWS CloudFormation Azure Resource Manager Dockerfile Google Deployment Manager Kubernetes OpenAPI Terraform docs.gitlab.com IaC Scanning
GitLab Triageでプロジェクトの棚卸しを自動化する
本記事は 富士通クラウドテクノロジーズ Advent Calendar 2021 の2日目の記事です。 1日目は@ktakaaki のTwilioとWindows PowerShellを使って連続で電話を掛けたいでした。Twilioはシステムから電話を掛ける際に非常に便利なサービスで、様々な場面でよく使われますが、PowerShellからでも簡単にコールできるんですね。 さて、富士通クラウドテクノロジーズ社では 全社員が利用するプロジェクト管理ツールとしてGitLabを採用 しています。各チームそれぞれがGitLabを活用しており、様々なGitLab活用ノウハウがあるのですが、今回は最近導入した GitLab Triage を紹介したいと思います。 GitLab Triageとは GitLab Triage はGitLabのプロジェクト上のIssue/Merge Request/Epicを
GitHub Actions でディレクトリ構造にもとづいて並列実行する
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 つ
Branch Deploy Action: GitHub Actions でブランチデプロイと IssueOps を試す - kakakakakku blog
The GitHub Blog の記事 Enabling branch deployments through IssueOps with GitHub Actions を読んで「branch deployments（ブランチデプロイ）」というデプロイ戦略を知った💡 プルリクエストを main ブランチにマージしてから本番環境にデプロイするのではなく，プルリクエストを直接本番環境にデプロイして，動作確認の結果問題なしと判断できてからプルリクエストを main ブランチにマージするという流れが特徴的❗️そして，デプロイに異常があってロールバックする場合は main ブランチをデプロイして復旧する💡 記事に載ってるブランチ画像（Merge Deploy Model と Branch Deploy Model）は非常にわかりやすく見てみてもらえればと〜 github.blog IssueOp
AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました | CyberAgent Developers Blog
AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました CTO統括室の黒崎(@kuro_m88)です。本日早朝に面白そうな発表を目にしました👀 AWS CodeBuild now supports managed GitHub Action runners AWS CodebuildがGitHub Actionsに対応したという内容ですが、要するにAWSがホストするGitHub Actions Runnerが出たということですね🎉 AWSがマネージしてくれることで、EC2(x64, arm)はもちろん、GPUとカスタムイメージも利用できるようです。 さらに注目したのはGitHub Actions RunnerとしてAWS Lambdaが使えるようです。Lambdaが使えると嬉しいポイントはActionsのjo
GitHub Actions Importer を使って CI/CD を GitHub Actions に移行する
Description: GitHub Actions Importer helps you plan, test, and automate your migration to GitHub Actions. Please share your feedback @ https://gh.io/ghaimporterfeedback Options: -?, -h, --help Show help and usage information Commands: update Update to the latest version of GitHub Actions Importer. version Display the current version of GitHub Actions Importer. configure Start an interactive prompt
GitLab CI/CDで特定のファイルが変更された場合にのみジョブを実行する - GeekFactory
GitLab 11.4から only:changes という記法がサポートされました．これにより，特定のファイルが変更された場合のみジョブを実行できます． https://docs.gitlab.com/ee/ci/yaml/#onlychangesexceptchanges 例えば，以下のように記述すると，ブランチをpushした時に terraform/ フォルダのファイルが変更されている場合にのみジョブが実行されます． stages: - build terraform_plan: stage: build only: changes: - terraform/**/* - .gitlab-ci.yml image: name: hashicorp/terraform:0.12.8 entrypoint: - /usr/bin/env script: - cd terraform/ -
GitHub Actions でモノレポ上の特定パスをチェックアウトスキップしたい - tech.guitarrapc.cóm
モノレポでリポジトリサイズが大きくチェックアウトが長くて困ることがあります。 今回はこういったときにどうできるのかを考えてみましょう。 tl;dr; GitHub Actions でスパースチェックアウトをする CI におけるチェックアウトの基本 git clone を高速化する定番の方法 シャロークローン スパースチェックアウト GitHub Actions でスパースチェックアウトをしたい Gactions/checkout はスパースチェックアウトに対応していない スパースチェックアウトを書いてみよう まとめ 参考 tl;dr; CIでは特定のパスしかいらないのに、ほかのパスもチェックアウトされるのを制御したい場合、スパースチェックアウトが使えます。 スパースチェックアウトを使えば、モノレポ上で、特定のパスをチェックアウトスキップしたり、特定のパスだけチェックアウトすることができる
GitLabでテストコードをレビューしやすくする - Qiita
はじめに Increments × cyma (Ateam Inc.) Advent Calendar 2020 の8日目は、株式会社エイチーム EC事業本部の@hibiheionが担当します。 業務では主に自転車ECサイトcymaのバックエンドをRailsで書いています。 この記事はGitLabでテストコードをレビューしやすくする機能の紹介です。 ここではプログラミング言語としてRuby(Rails)、テストコードとしてRSpecを使用していますが、言語を限定した機能ではないので他のプログラミング言語でも使用可能です。 背景 みなさんはテストコードの運用で課題に感じていることはありませんか？ 私がテストコードの運用で課題に感じていることのひとつにコードレビューの手間があります。 理由はテストコードのレビューではテストコードの書き方だけでなく、プロダクトコードをカバーするテストになっている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自動化と効率化のためにGitHub Actionsを使いこなそう
