Shogo's Blog

Oct 23, 2020 - 2 minute read - Comments - github

GitHub Actions を使って簡単なボットを作る

リリース当初は git push など GitHub 上のイベントしかトリガーにできなかった GitHub Actionsですが、 workflow_dispatch イベント の登場により手動実行ができるようになりました。 社内でもこの機能を利用してワークフローの手動実行をしていたのですが、人間とは欲深いもので「毎回ワークフローを選択してポチポチするのだるい」という声があがってきました。 そういうわけで、Pull Request のコメントをトリガーにしてワークフローを実行する簡単なボットを作ってみました。 方針 workflow_dispatch と issue_comment をトリガーにしたワークフローを作ればいいだけの気もしますが、 以下のような理由からワークフローからワークフローを呼び出す形にしました。 workflow_dispatch を使った既存のワークフローがあるので、それを流用したい トリガーが複数あると、イベントの種類に応じてペイロードの形式が異なるので、地味に処理が大変 issue_comment は全部のコメントに反応するので、本当に見たいログが埋もれてしまう コメントを投稿した Pull Request のHEADでワークフローを実行して欲しい issue_comment はイベントの発生元として、デフォルトブランチのHEADが渡ってきます イベントのペイロードには、プルリクエストへのリンクが入っているだけで、HEADの情報はわからない 実装 jfurudo1 がサードパーティのアクションを使ってゴニョゴニョやっていたものの、 あんまりうまく行ってなさそうだったので、bash script でエイヤッと書き直しました。 「build」 とコメントすると、.github/workflows/build.yml のワークフローを実行するサンプルです。 name:comment hookon:issue_comment:types:[created]jobs:distribute:runs-on:ubuntu-lateststeps:- name:dispatch workflowrun:| # イベントに関する詳細情報を取ってくる PAYLOAD=$(cat "$GITHUB_EVENT_PATH") NUMBER=$(echo "$PAYLOAD" | jq -c '.issue.number') # Issue と Pull Request のコメントが混ざってくるので、Issueは無視する if [[ "$(echo "$PAYLOAD" | jq -c '.

Aug 15, 2020 - 1 minute read - Comments - aws perl lambda

AWS Lambda Perl Runtime on Amazon Linux 2 を公開しました

Amazon Linux 2 への移行が進む AWS Lambda ですが、 ついに Custom Runtime にも Amazon Linux 2 がやってきました。 AWS Lambda now supports custom runtimes on Amazon Linux 2 同時に provided.al2 の Docker Image も公開されたので、 それを利用して Amazon Linux 2 対応の Perl Runtime Layer を作成しました。 AWS::Lambda ビルド済み公開 Perl Runtime Layer リージョン毎のArn一覧はこちら Perl 5.32 arn:aws:lambda:af-south-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-east-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-northeast-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-northeast-2:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-south-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-southeast-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-southeast-2:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ca-central-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-central-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-south-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-west-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-west-2:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-west-3:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:me-south-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:sa-east-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:us-east-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:us-east-2:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:us-west-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:us-west-2:445285296882:layer:perl-5-32-runtime-al2:1 --runtime provided.

Jul 6, 2020 - 1 minute read - Comments - aws go golang

Yet Another AWS X-Ray Go SDK でログの関連付けをサポートした

僕が管理しているサービスでは、ALB が発行する Trace ID を調査時の手がかりとして使えるようログに出力しています。 これのおかげで、Nginx, アプリケーション, その他AWSのマネージドサービス, etc. といった異なるコンポーネントであっても、関連するログを抽出ができ、 障害発生時の役に立っています。 しかし、肝心の抽出作業がマネージドコンソールぽちぽちなため、完全に職人芸になっているというのが現状でした。 解決のための良いツールがないかな、と目をつけたのが CloudWatch ServiceLens です。 CloudWatch メトリックとログ、AWS X-Ray からのトレースを結び付けて、直感なインターフェースで分析できるというもの。 Amazon CloudWatch ServiceLens の発表 AWS X-Ray のトレース結果を送るのは、以前開発した Yet Another AWS X-Ray SDK for Go でできます。 CloudWatch Logs への出力方法は色々ありますが、僕は自作の cloudwatch-logs-agent-lite を使っています。 材料はそろった、さあ、ServiceLens で分析だ!と行きたいところですが、 ただ単にこれらの情報を送りつけるだけでは、得られる情報は X-Ray 単体、CloudWatch Logs 単体で使ったときと大差ありません。 X-Ray のトレース結果とログの関連付けが行われていないので、結局 Trace ID を使って CloudWatch Logs を検索する必要が出てきてしまいます。 ドキュメントを見る限り、2020-07-06現在 AWS X-Ray SDK for Java だけがログ関連付け機能に対応しているようです。 JavaにできてGoにできないわけがないだろう・・・ということで移植してきました。 使い方 aws-xray-yasdk-go の v1.1.1 移行で対応しているので、そのバージョンを落としてきます。

Apr 2, 2020 - 3 minute read - Comments - github

RE: Pull Request Title Injection とその対策

@furusax が書いてくれた GitHub Action からの Slack 通知機能について以下のようにコメントしたところ、 対策案を考えてくれました。 そういえばこれって Pull Request Title Injection できないですかね? まあ、タイトル書くの社員なのでいいんですが。 対策してみました #はてなブログ Pull Request Title Injection とその対策 - なまえは まだ ないhttps://t.co/hIkMykFUr8 — ふるさっくす (@furusax) March 31, 2020 Pull Request Title Injection とその対策 なるほど、こう来ましたか。しかし、まだまだ甘いですね・・・。 2021-08-19 追記 ドッグさん が便利なツールを作ってくれました。 rhysd/actionlint actionlint v1.4 → v1.6 で実装した新機能の紹介 GitHub Actions のワークフローファイルの静的チェッカーです。 チェック項目にこの記事で紹介したような脆弱性検知も含まれているのでおすすめです! Pull Request Title Injection について まずはこの記事に出てくる「Pull Request Title Injection」についておさらいです。 以下のような Slack への通知を行う GitHub Actions があります。 github.

Mar 30, 2020 - 2 minute read - Comments - aws go golang

Yet Another AWS X-Ray Go SDK を作った

AWS X-Ray Go SDK の地雷処理をしている話 で投げたSQLのプルリクエスト も無事マージしてもらい、 その後もちょくちょくプルリクエストを投げて地雷処理をしていたんですが、我慢できずにやってしまいました・・・。 Yet Another AWS X-Ray SDK for Go そもそも AWS X-Ray ってなんだ、という方は以下のリンクから @fujiwara さんの記事へ飛べるのでどうぞ。 AWS Lambda Perl Runtime で AWS X-Ray を使えるようになりました 使い方 だいたいオフィシャルSDKと一緒です。 ただし、パッケージ分割をしたので、呼び出す関数名等はちょっと変わってます。 他にも微妙に挙動が違う箇所があります。 環境変数の設定 AWS_XRAY_DAEMON_ADDRESS, AWS_XRAY_CONTEXT_MISSING 等の環境変数の設定項目は本家と合わせました。 ただし、以下の点が本家とは異なります。 コード内の設定が優先されます。 環境変数はコード内で明示的に設定が行われなかった場合のフォールバックです。 AWS_XRAY_CONTEXT_MISSING のデフォルト値は LOG_ERROR です。 セグメントの作り方 オフィシャルSDKは seg.Close(err) のようにセグメントを閉じるときにエラーを渡します。 Go には defer という便利な機能があるので、セグメントを閉じるときもこれを使いたいところです。 だたエラーを正しく受け取るには、以下のように戻り値に名前をつけて、defer 部分を無名関数の呼び出しにする必要があります。 // オフィシャルSDKの場合 import "github.com/aws/aws-xray-sdk-go/xray" func DoSomethingWithSubsegment(ctx context.Context) (err error) { ctx, seg := xray.

Feb 11, 2020 - 3 minute read - Comments - aws

AWS X-Ray Go SDK の地雷処理をしている話

AWS Lambda Perl Runtime で AWS X-Ray を使えるようになりました で紹介した AWSの分散アプリケーションの分析サービス AWS X-Ray。 Perl から使えるようにしたももの、自分自身は最近 Perl をあまり使っていないことに気がついた!!ので、AWSが提供しているGo実装である aws/aws-xray-sdk-goに 手を出してみることにしました。 結果、X-Rayのサービスマップやトーレスが見れるようになって便利!・・・にはなったんですが、そこまでの道のりが長かった。 「 @fujiwara さんのYAPC::Tokyo 2019での発表 から1年近く経ってるしそろそろ安定してきているでしょ!」と 軽い気持ちで始めたのが良くない。 色々と地雷(?)を踏んだので、記録として残しておきます。 依存ライブラリのcontext対応が地味に辛い X-Ray で実行をトレースするには、「今実行している関数がどこから呼ばれたのか?」という情報をうまいこと伝える必要があります。 Perlで使われているような黒魔術はGoでは使えないので、 context.Context を地道に引数に渡していくことになります。 まあ、こんなこともあろうかと、context.Context にはバッチリ対応してあるからサクッと行けるでしょ! と思ってたんですが、現実はそうは甘くなかった。 X-Rayを入れようとしたプロジェクトではWebフレームワークとしてgoadesign/goaを使っています。 GoaのHTTPハンドラーには context.Context が渡ってくるので油断していたのですが、 contextの親をたどっていくと行き着く先は context.Background() (HTTPハンドラーなので request.Context() であってほしい)。 なんとなく context.Context 対応詐欺にあった気分です。 Goaは現在 v2, v3 の開発がメインで現在使っているのは v1 です。 v1からv3へのアップグレードには大幅な書き換えが必要なこと、アップグレードしたとしても直っている保証がないこと、 最近 Goa v1 のリリースが滞りがちなこと、などなどの理由から結局フォークしてくることにしました。 shogo82148/goa-v1 AWS X-Ray Go SDK 自体の問題ではないのですが、 Contextってタイムアウトをうまく処理するための仕組みなので、実装漏れがちですよね。 皆さん実装するときやライブラリの選定には気をつけましょう。 SQLクエリを実行する関数のシグネチャーが微妙に違う これに関しては @acidlemon 先生の kamakura.

Feb 1, 2020 - 1 minute read - Comments - github

元Yahoo!ジオシティーズ利用者のかたへ、GitHub Pagesのすゝめ

TL;DR 今GitHubにアップロードした内容は1000年残る! デッドラインは 2020年2月3日(月) 午前7時(日本時間) Yahoo!ジオシティーズのデータがダウンロードできるのは2020年3月31日まで つまりYahoo!ジオシティーズから移行するなら、今! GitHubが一番! Yahoo!ジオシティーズは終了しました Yahoo!ジオシティーズ 公開停止からはや10ヶ月。 ちょっと古いリンクをたどると「Yahoo!ジオシティーズは終了しました」というページを目にすることが多くなりました。 Yahoo!ジオシティーズは終了しました 2019年3月31日をもちましてYahoo!ジオシティーズのサービス提供を終了いたしました。長らくご愛顧いただき誠にありがとうございました。 ホームページをお持ちのお客様につきましては、2020年3月31日までFTPによるファイルダウンロードのみご利用可能となっております。ホームページやドメインの移行方法などはサービス終了のお知らせをご確認ください。 https://info-geocities.yahoo.co.jp/ それ見てこんなツイートをしたのですが、なぜ GitHub への移行がいいのか知らない人が多いようなのでちょっと説明しますね。 みんな!FTP経由ならまだジオシティーズからホームページのダウンロードはできる!!今のうちにGitHubへ上げてその黒歴史を1000年後まで残すんだ!!! — Ichinose Shogo (@shogo82148) January 31, 2020 GitHub Arctic Code Vault なぜ今 GitHub なのかというと、 GitHub Universe 2019 で GitHub Archive Programというプログラムが発表されたからです。 今から1,000年後にソフトウェアはどのようになっているのか、また人類はどうなっているのか、推測することしかできません。しかし、今日の時点で最も重要なビルディングブロックを、確実に明日に残せるようにすることは可能です。私たちの世界は、オープンソースソフトウェアで動いています。この文明の隠れた基盤であり、全人類の共有財産です。GitHub Archive Programの使命は、次世代のためにオープンソースソフトウェアを保護することです。 GitHubは、スタンフォード大学図書館、Long Now Foundation、 Internet Archive、Software Heritage Foundation、Piql、Microsoft Research、オックスフォード大学ボドリアン図書館などの機関や団体と連携し、世界のオープンソースコードを保護していきます。この貴重な知識を保護する方法として、あらゆるデータ形式でさまざまな場所に、継続的に複数のコピーを保存していきます。保存場所には、GitHub Arctic Code Vaultと呼ばれる、少なくとも1,000年は存続する非常に長期的なアーカイブも含まれます。 https://github.blog/jp/2019-11-14-universe-day-one/ このプログラムで最長の保存場所である GitHub Arctic Code Vault は、北極圏に広がる永久凍土の深さ250mに建設されたアーカイブ施設「Arctic World Archive」。

Dec 6, 2019 - 1 minute read - Comments - go github

CloudFormationのテンプレートのLinter actions-cfn-lint のご紹介

この記事はフラーAdvent Calendar 2019の6日目の記事です。 5日目は@shogo82148 さんで「GitHub Goveralls Action を公開しました」でした。 さて、最近 GitHub Actions を作るのにハマっているので、今日も GitHub Actions の紹介です。 GitHub Action for CloudFormation Linter with reviewdog shogo82148/actions-cfn-lint Amazon CloudFormation Infrastructure as Code の盛り上がりも一段落し、今では当たり前のように使っている人も多いと思います。 フラー共創スタジオはAWSがメインなので、CloudFormationをメインに使っています。 色々とクセは強いですが、少なくともtfstateが行方不明になったりはしないので、まあまあ仲良くやっています。 CloudFormation Linter テンプレートを書いている上で地味にややこしいのが、プロパティーの名前や型の統一感が微妙にない、ということです。 例を挙げると、AWS::ApplicationAutoScaling::ScalableTarget の MaxCapacity は整数型です。 これはまあ、納得できますね。 ところが AWS::AutoScaling::AutoScalingGroup の MaxSize は 文字列型 なんです。説明文には「Auto Scaling グループの Amazon EC2 インスタンスの最大数」とあるのに! オートスケールという似たような機能を持っていて、どちらもスケーリンググループの最大数を表しているの、名前も違えば型が全く違う。 この手のミスは aws cli に付属している テンプレートの validation 機能では見つけられす、実際に反映してみるしかありません。 すぐに失敗してくれればいいんですが、失敗するまでにも十数分かかったりしてかなり面倒です。 そこでおすすめなのが CloudFormation Linter。 この手の名前のミスや型のミスを指摘してくれるコマンドラインツールです。 各種エディタ用の拡張もあり、VSCodeでも使える ので、ぼくはいつもこれを使っています。

Dec 5, 2019 - 1 minute read - Comments - go github

GitHub Goveralls Action を公開しました

この記事はフラーAdvent Calendar 2019の5日目の記事です。 4日目はふるふる先生の「GoでJSONを良い感じに使おうと思ってハマった話」でした。 さて、首を長くして待っていた GitHub Actions がついにGAになりましたね。 (日本語版ヘルプだとまだbetaになってますが) さっそくActionを自作してちょっと前に公開してたんですが、この機会に紹介しようと思います。 actions-goveralls - Actions GitHub Marketplace shogo82148/actions-goveralls 使い方 coveralls.io はコードカバレッジの可視化サービスです。 実は公式でGitHub Actionsを提供しており、Coveralls GitHub Action を使うと 「JavaScriptのプロジェクトであれば」簡単にカバレッジを送信することができます。 しかし、Goが出力するカバレッジはJavaScriptと形式が違うので、そのままは使えません。 他のCIではmattn/goverallsにお世話になっていたので、 これを GitHub Actions として簡単に使えるようにしました。 最小限の設定はこれだけです。 # ここらへんにテストとかの設定ば別途描く# coveralls.io に送信- uses:shogo82148/actions-goveralls@v1with:github-token:${{ secrets.GITHUB_TOKEN }}path-to-profile:profile.cov簡単ですね。 マトリックスビルド され、後発なだけあって GitHub Actions では他のCIの便利な機能を簡単に使えます。 その中でも最も便利(偏見)なのがマトリックスビルドです。 例えば以下のように設定するだけで、Linux, macOS, Windows で同じテストを実行できます。 strategy:fail-fast:falsematrix:os:- ubuntu-latest- macos-latest- windows-latestruns-on:${{ matrix.os }}・・・と、ここまではいいんですが、カバレッジをとって coveralls に送ると残念なことになります。 (例:https://coveralls.io/builds/27037772) どれかがLinuxでどれかがmacOSで残った最後がWindowsの実行結果なのですが、 ジョブの名前が一緒なので区別が付きません。 parallel build webhook coveralls にはこの問題を解決してくれるparallel build webhookというものがあります。 travis-ci だと coveralls側がいい感じにフックを挟んで処理してくれるんですが、GitHub Actions では自前でやらないといけません。 全部自前でやるのは面倒なので、actions-goveralls には補助する機能をいれてあります。

Sep 18, 2019 - 2 minute read - Comments - perl github

Setup Perl GitHub Action を公開しました

GitHub Actions の公式レポジトリには Perl のセットアップアクションが無いぞ! ということで三連休+αで書きました。 actions-setup-perl on GitHub Marketplace 使い方 Marketplaceの設定例は間違えているので以下を参照。(これ書いていて気がついた) 必要な Perl のバージョンを渡すだけです。簡単! steps:- uses:actions/checkout@master- uses:shogo82148/actions-setup-perl@v1with:perl-version:'5.30'- run:cpanm --installdeps .- run:prove -lv tUbuntu, macOS, Windows 各種OSにも対応しています。 jobs:build:runs-on:${{ matrix.os }}strategy:matrix:os:['ubuntu-18.04','macOS-10.14','windows-2019']perl:['5.30','5.28']name:Perl ${{ matrix.perl }} on ${{ matrix.os }}steps:- uses:actions/checkout@v1- name:Setup perluses:shogo82148/actions-setup-perl@v1with:perl-version:${{ matrix.perl }}- run:perl -V- run:cpanm --installdeps .- run:prove -lv t動作サンプル https://github.com/shogo82148/p5-Acme-OkMacopy/blob/master/.github/workflows/test.yml https://github.com/shogo82148/p5-Acme-OkMacopy/commit/15bf2162a26a1ea8bfe748ddc980164f049a1c67/checks ok macopy をこんな形で使うことになろうとは、あの当時は思っていなかった・・・ 裏方の話 Actionでインストールされるperlについて GitHub Actions の Runner にはキャッシュ領域が用意されていて、こういうバイナリはそこに入れるのがお作法のようです。 perlは付属するCPANモジュールのパスがバイナリに組み込まれているので、パスを変更したい場合は再ビルドが必要です。 そういうわけで、perl 5.8.5 から perl 5.