2019年8月28日水曜日

[Travis CI] Addons apt のリトライ設定

travis-ciにtravis_retryという失敗しても何度かリトライする機能があるらしい件 - xuwei-k's blog
Common Build Problems - Travis CI

Travis CI には 'travis_retry' コマンドが用意されているので、script でのリトライ対応はできるのですが、Addon の場合でもできないのか調べました。




答え:できる
For a more resilient apt operations, add retries by BanzaiMan · Pull Request #1343 · travis-ci/travis-build

addons:
  apt:
    sources:
      - ubuntu-toolchain-r-test
      - llvm-toolchain-xenial-8
      - llvm-toolchain-xenial
    packages:
      - clang-8
      - g++-9
      - gcc-9
    config:
      retries: true
https://github.com/srz-zumix/iutest/pull/279

2019年8月23日金曜日

[GitHub Actions] 公式 Badge を付ける

旧 GitHub Actions ではバッジがなくて、以下を利用させて頂いていたのですが、
CultureHQ/github-actions-badge: A GitHub Actions README badge

最近バッジ表示できないなーと思っていて、リポジトリを覗きに行ったら
公式のバッジが取得できることを知りました!

(ドキュメントはまだないっぽい)

Markdown だとこうなります。
[![Actions Status](https://github.com/{owner}/{repo}/workflows/{workflow_name}/badge.svg)](https://github.com/{owner}/{repo}/actions)

ブログズミ: 新しい GitHub Actions に移行しました
先日の記事でバッジ早くくれ!と言ってましたが、もうありました!!
お詫びして訂正いたしますm(__)m

やったぜ!


※ブランチ指定はまだできない?検証中

2019年8月21日水曜日

新しい GitHub Actions に移行しました


GitHub Actions now supports CI/CD, free for public repositories


新しい GitHub Actions が使えるようになっていたので、
iutest のワークフローを 旧 GitHub Actions から移行しました。
migrate github actions by srz-zumix · Pull Request #274 · srz-zumix/iutest

HCL な main.workflow から YAML への変換
以前の GitHub Actions は HCL というフォーマットを採用していましたが、新しい GitHub Actions は他の CI サービスと同様に YAML での configuration になりました。
HCL だとどう書くんだろ?といちいち調べる手間が減るので地味に嬉しい変更です。
ただここで、HCL で書かれた workflow を YAML に直す手間が必要になるのですが・・・



さすが GitHub 、ちゃんと Migration tool を用意してくれていました!
Migrating GitHub Actions from HCL syntax to YAML syntax - GitHub Help

手順は至って簡単で、
ツールをダウンロード・展開したら、目的のリポジトリ下でツールを実行するだけです。
(ブランチ切り替えとかも含めて丁寧に説明されていますので、手順は上のリンクから確認してください)

手順どおりに行えば一瞬で移行が完了します。



自動変換後に調整したこと
ジョブを分けた


以前の GitHub Actions ではアクションごとにステータスがついていたのですが、新しい GitHub Actions でジョブごとにステータスがつくようでした。
変換した YAML ではアクションがすべて 1つのジョブにまとめられていたので、前と同じステータス通知になるようにジョブを分けました。
https://github.com/srz-zumix/iutest/pull/274/commits/b9cbdc04b6620c210e03c10085ec949092e94e9d


チェックアウト
ジョブを分けたら、それぞれにチェックアウトステップが必要でした。
各ジョブの steps に 「uses: actions/checkout@master」を追加しましょう。

steps:
    - uses: actions/checkout@master


通知設定の変更
新しい GitHub Actions になったからなのか、いつぞやからかメールで通知が来るようになっていたので無効化しました。
https://github.com/settings/notifications を開くと「GitHub Actions」の項目があるのでそちらで設定します。


「Web」にすると、GitHub の右上のベルマークのところに通知が飛ぶようになります。



変わったこと
新しい GitHub Actions に変わって大きく変わったのは
* YAML になったこと
* Windows / Mac OS が使えるようになったこと
でしょうか。

Windows や Mac OS でのテストは現在は他の CI サービスを使っているので、近々で試すことはないかもしれませんが、これらをサポートする CI サービスもだいぶ増えた印象です。
各 CI サービスがどの OS を使えるか、以下のリポジトリで個人的にまとめているので興味がある方はどうぞ。(PR お待ちしてます)
https://github.com/srz-zumix/ci-specs/blob/master/README.md#build-environment

最後に
2019/8/23 追記
ドキュメントにはまだ書かれてないようですが、すでにバッジをつけることはできてましたmm
ブログズミ: [GitHub Actions] 公式 Badge を付ける

早くバッジください

2019年8月13日火曜日

「PVをツイートするサービス」から「Integromat」に引っ越ししました


長らく「PVをツイートするサービス」を利用させて頂いて来ましたが、IntegromatBasic プラン($9/mon) を使っていることもあり、なるべくそっちを使おうということで引っ越ししました。



特に難しいことはなくて、Google Analytics の APP を使って欲しいメトリクスを選択して取得したら、あとはいつものとおりにツイッターに流すだけです。


詳細
PV 以外にも色んな情報が取れますが、最終的に以下のようにツイートさせるようにしました。

それぞれ以下の Metrics を取得しています。
Pageviewsga:pageviews
1 Day Active Usersga:1dayUsers
Sessionsga:sessions
Avg. Time on Pagega:avgTimeOnPage

Avg. Time on Page は秒数が入ってるので、Tool の Set Variable オペレータで、「分:秒」テキストに変換しています。


{{toString(floor(round(2.`ga:avgTimeOnPage`) / 60))}}:{{toString(round(2.`ga:avgTimeOnPage`) % 60)}}

ハマったこと
Error 400 (badRequest): Selected dimensions and metrics cannot be queried together.

Metrics によっては、Dimensions と一緒に取得しなければいけないものがあるそうです。
なので、「metrics and dimensions」を選択して、「Dimensions」には適当に Date を指定するといいと思います。

どこにあるのかわかりづらい
ハマったというか、使いづらいなぁ・・・と思ったところです。

Metrics からはいろいろな情報が取得できるのですが、Integromat の UI から目的の要素を見つけるのがクソ面倒でした。



月間PVの対応
PVをツイートするサービス」は、月初に先月の PV もツイートしていたのでそちらにも対応しました。



できたシナリオはこちら。


Google Atalytics の設定
まずは一月分のメトリクスを取得する必要があります。
期間の設定を「先月の1日0時」から「今月の1日0時」までにします。
以下のように計算しました。

先月の1日0時:
{{addMonths(parseDate(formatDate(now; "YYYY/MM"); "YYYY/MM"); -1)}}

今月の1日0時:
{{parseDate(formatDate(now; "YYYY/MM"); "YYYY/MM")}}

そして、取得するデータの数がデフォルトだと 10 になっているので、
一ヶ月分取得できるように 31 にしておきます。


月間PV数を計算
Google Analytics オペレータからは日毎の結果が入ってくるので、各日の PV 数を Aggregate で配列にして Iterator で Sum して、月間PVを算出しています。
(これもう少し簡単にかけると嬉しいな)


Notification
最後にツイートです。
PV数を桁区切りするようにフォーマットしてるくらいで、あとは普通にテキストを指定しています。

先月のブログズミのPVは {{formatNumber(12.result; 0; "."; ",")}} でした。
https://srz-zumix.blogspot.com/

最後に
Basic プラン使ってることもあって、オペレータ数とかあまり気にせず作りましたが、工夫すれば少し減らせると思います。(変数セットをツイートオペレータにベタ書きとか)
daily/monthly で実行するものなので、起動回数的にも消費リソースは少なくて済むはずなので、無料プランでも運用できるかな?と思います。

最後に、ながらくお世話になった「PVをツイートするサービス」に感謝 m(_ _)m

2019年8月6日火曜日

[Azure Pipelines] 頻繁にトリガーされるジョブの実行回数を削減する

Build pipeline triggers - Azure Pipelines | Microsoft Docs

If you have a lot of team members uploading changes often, then you might want to reduce the number of builds you're running. If you set batch to true, when a build is running, the system waits until the build is completed, then queues another build of all changes that have not yet been built.

trigger:
  batch: true

trigger に batch: true をつけると、キューイングされたジョブは1つにマージされるようです。
Azure Pipelines の場合は、実行中のジョブは完了を待ちます。
Travis CI のように実行中のジョブをキャンセルして、キューの最後を実行する auto-cancel とは挙動が異なりますので注意が必要です。