@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.event.pull_request.title はプルリクエストを送った本人が自由に設定できるので、 ここにうまいこと細工をすれば Slack への投稿内容を自由に改変できてしまうのでは？という問いかけでした。

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.BeginSubsegment(ctx, "service-name") defer func() { seg.

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.

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」。 2020年2月2日 時点でのアクティブな公開リポジトリ※のスナップショットが、QRコードとしてエンコードされフィルムに印刷されたのち、この場所に保管されます。 Arctic World Archive は地政学的に地球上でもっとも安定した場所であり、1000年の長期保存にも耐えるとのこと。

この記事はフラー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でも使える ので、ぼくはいつもこれを使っています。 CloudFormation Linter については Classmethod さんの紹介記事もどうぞ。

この記事はフラー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@v1 with: github-token: ${{ secrets.GITHUB_TOKEN }} path-to-profile: profile.cov 簡単ですね。 マトリックスビルド され、後発なだけあって GitHub Actions では他のCIの便利な機能を簡単に使えます。 その中でも最も便利(偏見)なのがマトリックスビルドです。 例えば以下のように設定するだけで、Linux, macOS, Windows で同じテストを実行できます。 strategy: fail-fast: false matrix: os: - ubuntu-latest - macos-latest - windows-latest runs-on: ${{ matrix.

GitHub Actions の公式レポジトリには Perl のセットアップアクションが無いぞ！ ということで三連休+αで書きました。 actions-setup-perl on GitHub Marketplace 使い方 Marketplaceの設定例は間違えているので以下を参照。(これ書いていて気がついた) 必要な Perl のバージョンを渡すだけです。簡単！ steps: - uses: actions/checkout@master - uses: shogo82148/actions-setup-perl@v1 with: perl-version: '5.30' - run: cpanm --installdeps . - run: prove -lv t Ubuntu, 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 perl uses: shogo82148/actions-setup-perl@v1 with: perl-version: ${{ matrix.

AWS Lambda 上で Perl を動かす AWS::Lambda で、 AWSの分散アプリケーションの分析サービスである AWS X-Ray をサポートしました！ AWS X-Ray って何？ Perl からどう使うの？ という人は @fujiwara さんの記事とYAPC::Tokyo 2019での発表スライドをどうぞ。 第56回　AWS X-Rayによる分散トレーシング―マイクロサービスのボトルネック，障害箇所の特定（1） 第56回　AWS X-Rayによる分散トレーシング―マイクロサービスのボトルネック，障害箇所の特定（2） 第56回　AWS X-Rayによる分散トレーシング―マイクロサービスのボトルネック，障害箇所の特定（3） 使ってみる Perl Runtime だけでなくX-Ray SDK 側でも対応が必要だったので、プルリクエストを送って取り込んでもらいました。 このプルリクエストがマージされた最新の AWS::XRay を Perl Runtime Layer にプリインストールしたので、あなたのアプリケーションですぐに使えます。 例えばこんな感じのコードを書いて、 use utf8; use warnings; use strict; use AWS::XRay qw/ capture /; sub handle { my ($payload, $context) = @_; capture "myApp" => sub { capture "hogehoge" => sub { sleep 1; }; capture "fugafura" => sub { my $segment = shift; $segment->{metadata} = $payload; }; }; return +{"hello" => "lambda"}; } 1; Layer に X-Rayに対応した最新の Perl Runtime arn:aws:lambda:ap-northeast-1:445285296882:layer:perl-5-30-runtime:3 を追加、 マネージドコンソールの「Debugging and error handling」セクションにある「Enable AWS X-Ray」を有効化し、実行してみます。

日本語の Go コミュニティだと go-bindata (なんか乗っ取り騒動とか色々あってメンテナンスされてない), go-assets (最近メンテナンス滞りがち) が有名(要出典)なやつです。 これらのライブラリに関してたくさん日本語記事が書かれて、今もたくさん検索に引っかかるのですが、残念ながら最近はメンテナンスが滞っています。 最近は statik の名前もよく見るようになりました。 その他は Resource Embedding - Awesome Go からどうぞ。 で、まあ、今回も完全に車輪の再発明なんですが、他の実装には色々と思うところがあり書いてみました。 shogo82148/assets-life USAGE なにはともあれ、まずは go get してきます。 $ go get github.com/shogo82148/assets-life assets-life というコマンドがインストールされるので、 バイナリに組み込みたいディレクトリと出力先を指定します。 $ assets-life /path/to/your/project/public public 出力先のディレクトリは Go のパッケージとしてインポートできるようになってます。 Root という変数のなかにファイルが埋め込まれており、http.FileSystem インターフェースを介してアクセスできます。 import ( "net/http" "example.com/your/project/public" ) func main() { http.Handle("/", http.FileServer(public.Root)) http.ListenAndServe(":8080", nil) } 特長 コードの再生成にコマンドのインストールが不要 これが一番の特長です。 バイナリにファイルを埋め込む都合上、静的ファイルを修正した場合にコードの再生成が必要です。 assets-life は go:generate ディレクティブを埋め込んだコードを出力するので、コードの再生成は go generate でできます。 # /path/to/your/project/public に修正を加える # コードの再生を行う $ go generate example.

完全に車輪の再発明なんですが、他の実装には色々と思うところがあり書いてみました。 shogo82148/go-retry MOTIVATION カッコいいインターフェースが欲しい インターフェースは lestrrat さんのこの資料を参考にしています。 GoらしいAPIを求める旅路 (Go Conference 2018 Spring) from lestrrat 「これ、Loop Condition だ」のあたりで、なるほど！と思ってインターフェースを真似てみました。 このインターフェースに沿って、lestrratさん自身が実装した lestrrat-go/backoff があります。 しかし、個人的にちょっと実装が複雑だなと感じたので、もうちょっとシンプルに書けないかとやってみました。 Context サポート 先行実装たちは Context がGoに取り込まれる前からあるので、 Contextに対応したインターフェースが後付だったり、 そもそもContextに対応していなかったりします。 Context未対応の Go 1.5 はすでにサポート対象外なので、もう Context が存在しない実行環境は考えなくてよいはずです。 SYNOPSIS Loop Condition Interface 使い方は lestrrat-go/backoff と大体一緒。 指数的バックオフに必要な各種パラメーターをポリシーとして与え、リトライのためのループを回します。 // 指数的バックオフの各種パラメーターをポリシーとして定義 var policy = retry.Policy{ // 初回待ち時間 MinDelay: 100 * time.Millisecond, // 最大待ち時間 MaxDelay: time.Second, // 最大試行回数 MaxCount: 10, } func DoSomethingWithRetry(ctx context.Context) (Result, error) { retrier := policy.