ゆく CI くる CI

はじめに

この記事は「CI/CD Advent Calendar 2019 - Qiita」17日目の投稿です。

はじめに

Rocro のサービス終了が発表されました。
コードレビュー系のサービスは GitHub Actions の登場もあり厳しいのかもしれないなぁーと思った今日このごろ。。

個人的には、GitHub Actions + reviewdog でもうええやんってなってる。
（reviewdog のことは別途記事にしたい）

と、まぁ GitHub Actions が目立った年だったなと思いますが、
各サービスの一年を軽く振り返ってみたいと思います。
（いろんなサービス使ってるけど、常にニュースを追っかけてるわけじゃないのでいい機会ですね）

AppVeyor

Build macOS projects with AppVeyor | AppVeyor
AppVeyor でも Mac が使えるようになりました。
ブログでは E-mail で連絡してねと書いてありますが、現在はすべてのユーザーが使用可能になっているようです。

かつては、Windows の CI は AppVeyor 一択だったころもありましたが、
もはや、OS のバリエーションは CI サービスの優位性にならなくなってしまいましたね。
今後 AppVeyor がどうなっていくのか気になるところです。

Azure Pipelines

What’s new with Azure Pipelines | Azure DevOps Blog
Multi-stage YAML pipelines というのが使えるようになっていたみたいです。
まだ使ったことないので、そのうち使ってみたいですね。

Bitrise

Bitrise Ship just released to Open Beta | Bitrise Blog (日本語)
Ship はストアへのデプロイを Bitrise 上で行えるようになる機能のようですね。
個人開発ではモバイル開発をしてないので、あまりお世話になることはないものですが、
Bitrise はモバイル開発の強みが加速しているように見えますね。

Buddy

New feature: Multiple YAML-file support for pipeline definitions | Buddy: The DevOps Automation Platform
パイプラインを分けてかけるようになったみたいですね。
.buddy ディレクトリ配下に、.yml をおけばよいみたいです。（ルートの buddy.yml は必須）

buddy は制限きつくてあんまり使ってないのですが、いっぱい使えるようになったら分割してみたいですね。

Circle CI

Windows CI - Windows support | CircleCI
AppVeyor とは逆ですね。Circle CI でも Windows 環境が使えるようになりました。

Cirrus CI

Cirrus CI は FreeBSD に対応しましたね。と言いたいところでしたが、去年の話でした。

Excited to announce FreeBSD support on Cirrus CI! 🎉 As usual free for OSS and with per-second billing for private repositories! 🙌 https://t.co/HplxCQSPYF

— Cirrus Labs (@cirrus_labs) December 4, 2018

なんか普段から使ってると昔からこうだった気がしちゃいますが、GitHub との連携周りが強化されていたようです。

Cirrus CI now supports @GitHub's content attachments API. 🎉 Issue and PR comments with links to Cirrus CI tasks will have additional information about the tasks including logs! 😻 pic.twitter.com/mmByWPwvwq

— Cirrus Labs (@cirrus_labs) January 29, 2019

Exited to announce @GitHub Annotations support on Cirrus CI! 🎉 Enriched feedback right in the same tab! 🙌 https://t.co/A7mAXxGdNG pic.twitter.com/YaZGhSVAKk

— Cirrus Labs (@cirrus_labs) April 22, 2019

と、思ったらマニュアルタスク対応してたのか！
ちょうど欲しかったんだよね。

Cirrus CI now supports manual tasks which are very handy integrated right in the @GitHub UI! Learn more in the docs 👇 https://t.co/muRW0AFGN7 pic.twitter.com/1xEu92CaJV

— Cirrus Labs (@cirrus_labs) May 20, 2019

Codefresh

Use parallel steps in your Codefresh pipelines - Codefresh
並列ステップができるようになりました。
これは、本ブログでも紹介しましたね。「ブログズミ: [Codefresh] Parallel 実行してみた」

Pause your pipelines and resume after manual approval - Codefresh
もう一個。
Codefresh もマニュアル対応してたんですね。

Codeship

New CloudBees CodeShip Beta - a Faster, Simpler, Unified Build Page - via @codeship | via @codeship

新しい UI が出てたみたいですね。
「Personal Settings」の「New build details page」を Turn On すればよさそうです。
今度試してみます。

Drone Cloud

Announcing Support for Starlark Scripting
GitHub Actions が HCL（HashiCorp Configuration Language）から YAML に変わったのは記憶に新しいですが、
Drone は YAML じゃなくて Starlark で書けるようになったみたいです。
Bazel な人にとっては嬉しいのかな？

GitHub Actions

New from Universe 2019: GitHub for mobile, GitHub Archive Program, and more - The GitHub Blog
はい。正式リリースおめでとうございます。
今後ともよろしくお願いします。

Pekaflow

前回の記事を参考にしてください。
「ブログズミ: [CI] Peakflow 始めました」

Rocro

Rocro will not be available after Jaunary 31, 2020 – Rocro News Releases
冒頭で書いたとおり、2020年1月31日にクローズとなります。
いままでお世話になりましたmm

Scrutinizer

2018年の4月以降ブログが更新されてない。大丈夫かな？

Semaphore CI

Semaphore 2.0 Welcomes Open Source Developers with Free Continuous Integration
OSS のビルド時間制限がなくなったみたいですね。
これはちょー嬉しい！あとでちゃんと確認しよ。

Shippable

こちらもブログの更新が滞ってますね。
ただ、Shippable は２月に JFrog に買収されたので、JFrog Pipeline の方に注力してるのかもしれないですね。
We’ve Acquired Shippable to Complete DevOps Pipeline Automation From Code to Production | JFrog

Shippable も継続してくれると嬉しい限りですが・・

Sider (旧SideCI)

Siderの運営会社が2019年10月末日より株式会社スリークに変わります - Sider Blog
Sleeek の機能の一端として取り込まれるみたいですね。

Shppable といい、統合が進んでますね。

Travis CI

CPU アーキテクチャが選べるようになりました。
OS の次は CPU アーキテクチャなのだろうか。
The Travis CI Blog: Multi-CPU architecture support for your builds
The Travis CI Blog: Build your open source projects on IBM Power and IBM Z CPU architecture

Wercker

こちらも特に news はなし。。

最後に

見切り発車でアドカレに登録してしまったのだが、使ってるサービスが増えるほど情報追っかけるのが辛いので、こういう機会に見直してみるのはありかも。と思いました。

年明けにこの記事を見返してみて、試せることはやってみたいと思います。
では。

[CI] Peakflow 始めました

はじめに

この記事は「CI/CD Advent Calendar 2019 - Qiita」10日目の投稿です。

おそらく、GitHub Actions など有名・話題なサービスの話が多くなるのではないか、
と予測して、とてもマイナーな CI サービスの話にしました。
そして、全くもって得るものがない内容となりましたことを報告致します。
（この時点で興味がない方はバックキー推奨）

私は趣味で CI のバッジを集めており、今回は新しい CI サービスを使ってみた。という内容です。
iutest

（GitLab CI が失敗してる・・タイミング悪し）

Peakflow 始めました

というわけで、本題。
Peakflow を始めてみました。

Pricing がわかりにくいけど、同時ビルド１本なら public/private 関わらずフリーでつかえるようです。

Sign up and Settings

Sign in しようとすると権限が求められるので許可します。


つづいて、最初のプロジェクト選択画面が出てくるので、選択します。
ここではいつもどおり iutest を選択。
(iutest は自作の C++ テスティングフレームワークです)


つぎに、peak_flow.yml を追加してと出てきます。
サンプルが ruby な感じですが、before_script と script があるのがわかったので、以下のようにしました。（ドキュメントどこでしょう・・）

before_script:
  - gcc --version || true
  - clang --version || true
script:
  - make -C test -j$((`nproc`))
  - make -C test test

追加するとビルドされます。簡単ですね。

ビルド時間が早い、が・・・

GitHub Actions や Travis CI と比べると圧倒的に早いけど。
Circle CI には負けてる。。




Peakflow では -j$((`nproc`)) でビルドしてたので、nproc 比較してみました。

CI	nproc
Circle CI	36
Cirrus CI	32
GitHub Actions	2
Peakflow	16
Travis CI	2

・・比較してみたのはいいのですが、Circle CI は -j4 にしてたので、この比較は意味ないなと気づきました。
あと、おそらくビルドする中の１つがとても時間かかってる気がするので -j オプションの数を増やしてもあんまり意味ないことに気づきました。
（これは別途課題として解決しようと思います）


じゃあもう少し深追いしようということで、これを機に↓で各 CI サービスのスペックを調べ始めました。
https://github.com/srz-zumix/ci-specs
（まだ作業中です。）

バッジ

最後はお決まりのバッジですが・・なんか no build になっちゃうんですよね。。
URL はプロジェクトの「Badges」から取れます。

最後に

うーん。。。という感じ。
なんかドキュメントもほとんど見当たらないし、（肝心の）バッジもちゃんと表示されないので、微妙ですね。。
Circle CI の代替サービスの位置づけのようですが、Circle CI 使ったほうが良さげ・・（有償プランの場合はお値段が関係してくるとは思いますが・・）

ここまでお付き合い頂きましてありがとうございました。
また、CI サービスを使ってみたらブログに書きます。ではでは。

[C++] 本当に private なところ

※ この記事は「C++ Advent Calendar 2019」６日目の投稿です。

ビットフィールドのアドレスは取れません。ほうほう、private アクセスできない感じかな？

— ずみっくす :X (@srz_zumix) May 15, 2019

private メンバー変数の R/W テスト

まずはこちらをご覧ください。

#include "iutest.hpp"
//origin>> #include "../../include/iutest.hpp"
#include <iostream>

int main(int argc, char** argv)
{
    IUTEST_INIT(&argc, argv);
    return IUTEST_RUN_ALL_TESTS();
}

class Test
{
private:
    int A:12;
    int B:4;
    int C:4;
    int D:12;
    int E;
public:
    Test()
        : A(0x777)
        , B(0x3)
        , C(0x4)
        , D(0x400)
        , E(1)
    {}
};

IUTEST_MAKE_PEEP(int Test::*, Test, E);

IUTEST(PeepTest, MemberVariable)
{
    ::Test test;
    IUTEST_EXPECT_EQ(1, IUTEST_PEEP_GET(test, ::Test, E));
    IUTEST_PEEP_GET(test, ::Test, E) = 4;
    IUTEST_EXPECT_EQ(4, IUTEST_PEEP_GET(test, ::Test, E));
}

https://wandbox.org/permlink/GqDQ4zeCrzv1HABq

private メンバーである Test::E への書き込み・読み込みができていることがわかると思います。

private メンバー変数（ビットフィールド）の R/W テスト

続いて、上でアクセスしている private 変数を E から A に変えてみます。

IUTEST_MAKE_PEEP(int Test::*, Test, A);

IUTEST(PeepTest, MemberVariable)
{
    ::Test test;
    IUTEST_EXPECT_EQ(1, IUTEST_PEEP_GET(test, ::Test, A));
    IUTEST_PEEP_GET(test, ::Test, A) = 4;
    IUTEST_EXPECT_EQ(4, IUTEST_PEEP_GET(test, ::Test, A));
}

https://wandbox.org/permlink/NRPvHweGaDp6HAdy

今度はコンパイルエラーです。

解説

プライベートにアクセスした方法

上のコードで利用したテスティングフレームワークは iutest です。
private メンバーへのアクセスはこのフレームワークの PEEP 機能を利用しています。
PEEP は template explicit instantiation で private にアクセス可能なことを利用して、private メンバーのアドレスを取得して実現しております。
詳しくは昔書いたこちらの記事を参考にしてください。（「ブログズミ: [C++] Private な関数のテスト」）

ビットフィールドにアクセスできなかった理由

error: address of bit-field requested

上記 PEEP の方法ではアドレスを取得できる必要があるため、
アドレスが取れないビットフィールドではアクセスできないわけです。
（言語法律家によるアクセスが可能な場合はビットフィールドでもアクセスできますが・・ ： https://wandbox.org/permlink/zYC1hAYuqqixaEUn）

まとめ

C++ にプライベートはあった

[Coverity][TravisCI] 設定の備忘録

TravisCI で Coverity Scan を使っているのですが、他のリポジトリでも使おうと思ったときに設定どうだっけ？と調べ直したので備忘録として残しておく。

さいしょに

Coverity Scan 側でプロジェクト作成したりとかは省きます。
そして、セットアップ方法も公式のドキュメントがあるので、そちらを見れば ok
https://scan.coverity.com/travis_ci

ただ、travis コマンドの使い方どうだっけなーとなるのでそこだけメモします。

COVERITY_SCAN_TOKEN を .travis.yml の env にセットする

トークンをセットします。そのまんま書いても動きますが、そんなことをしてはいけません。
セキュア変数にします。

travis コマンドのインストール

https://github.com/travis-ci/travis.rb#installation
こちらの手順に従ってインストールしましょう

トークンの設定

https://docs.travis-ci.com/user/environment-variables/#defining-encrypted-variables-in-travisyml
セキュア変数の作り方はこちらを参考にしてください。

travis encrypt COVERITY_SCAN_TOKEN= --add env.global

これで env global に COVERITY_SCAN_TOKEN 環境変数が追加されます。

今回は以上です。
では。

[AzurePipelines] ビルドの保存設定を変更する

master ブランチの更新がしばらくないとビルド履歴が消えてしまって、バッジが「never built」になってしまうのに対応しました。

履歴の保存設定を変更する

「Project Settings」を開き、「Pipelines」の「Settings」を開きます。


開くと「Retention policy」があるのでそちらで履歴をどの程度残すか設定できます。
iutest では更新が長く滞ることがあるので２ヶ月は保存するようにしました。


今回は以上です。
では。

iutest v1.17.0 をリリースしました

C++ テスティングフレームワーク iutest v1.17.0 をリリースしました。
Github: https://github.com/srz-zumix/iutest/releases
OSDN: https://osdn.net/projects/iutest/releases/71920

変更点は以下の通りです。

* New

* ::std::string_view 対応

* ::std::filesystem 対応

* FreeBSD 対応

* ALMOST_EQ アサーション を追加

* --iutest_locale_ctype オプションを追加

* Improved

* setlocale(LC_CTYPE, IUTEST_FLAG(locale_ctype)) をテスト実行開始時に行うように修正

* Visual Studio 2019 対応

* Changes

* 大きな配列/コンテナ/オブジェクトの pinter を修正

* iutest_main で setlocale していたものを廃止

* junit xml 出力で出力するテストが 0 だった場合にファイル書き出ししないように修正

* CSV パラメータ生成でファイルオープン失敗した場合の警告レベルを FATAL から WARNING に変更

* CSV パラメータ生成で要素がなかった場合に WARNING 出力

* deprecated: IUTEST_USE_OWN_LIST

* Bug fixes

* いくつかの不具合を修正

一応、v1.17 になって C++17 に対応した。という体でリリースしてます。
ホントはいろいろ足らない気がしてますが、ひとまず filesystem と string_view の対応はできると思います。
実際に使用してみたら、全然使い物にならない・・ってこともあるかもしれないので、issue 報告お待ちしております。

では。

[Google Docs] スプレッドシートが編集できなくなったときの対処

気づいたら入力しても更新されない状態になってしまってました。（確定すると戻る感じ）
「スプレッドシート 編集できない」で WEB 検索すると、以下の対応方法がでてきますがそれでは直らなかったので、メモ。

* 編集権限の問題（権限の確認・アカウントの確認）
* ブラウザの問題（バージョン・ソフトを変える）
* 制限（セル数）

症状

（キャプチャ残しておけばよかったな）

* セルへの入力や結合、行・列削除など一切の編集ができない
* ブラウザを変えると問題なし
* 同じブラウザでもブラウザのログインアカウントを変えると問題なし

対応方法

ローカルのアカウントに紐付いた情報がおかしいと推測して、サイトデータを削除しました。

「サイトの設定」→「Cookie とサイトデータ」→「すべての Cookie とサイトデータを表示」




「docs.google」で絞り込みして削除。

[Chrome] タブのポップアップ（バルーン）表示を消す方法

Chrome を更新したら、以下のようにタブにちょっと目立つ感じの表示がされるようになった。
慣れもあるだろうけど、なんか見づらいので消したのですが、設定どこだっけ？ってアカウントごとに調べ直していたので、自分用にメモ。

設定

chrome://flags/#tab-hover-cards


ここを「Disabled」にして Chrome を再起動すれば設定完了です。



今回は以上です。
こういうのでアクセス稼ぐんだろうなーという学び。

[Shippable] CentOS free plan に変更した

Pricing | Shippable


Ubuntu/CentOS は Free Plan があるので、両方使えるかな？と思ったがそうではなかった。
という話。


プランの変更は 「Settings」 の 「Billing」 にあります。
ここで SKU を追加できるのですが、SKU を２つにすると請求額が $0 じゃなくなります。



SKU が１つ、かつ「Enable unlimited private repo builds」のチェックを外すと $0 になります。
（Size は L 、キャッシュもなし）



つまり、フリーで使う場合は OS は１つしか選べないようです。

残念。。
というわけで、Ubuntu から CentOS に変更しました。

今回は以上です。

Windows Docker toolbox (VirtualBox) で USB 接続を使う

OpenSTF を使ってみようと思って、Windows + Docker toolbox 環境でやってみようとしたところ、すんなりいかなかったのでメモ。

USB コントローラーを有効にする（VirtualBox）

まずは、

docker-machine stop default

で VM を停止します。



USB を認識させるために VirtualBox Manager の設定から「USBコントローラーを有効」にチェックをいれ、コントローラーを選択します。


設定はこれで以上の場合もありますが、Docker toolbox を起動した際に以下のようなエラーになった場合は追加のインストールが必要です。

Starting "default"...
(default) Check network to re-create if needed...
(default) Windows might ask for the permission to configure a dhcp server. Sometimes, such confirmation window is minimized in the taskbar.
Unable to start the VM: C:\Program Files\Oracle\VirtualBox\VBoxManage.exe startvm default --type headless failed:
VBoxManage.exe: error: Implementation of the USB 3.0 controller not found!
VBoxManage.exe: error: Because the USB 3.0 controller state is part of the saved VM state, the VM cannot be started. To fix this problem, either install the 'Oracle VM VirtualBox Extension Pack' or disable USB 3.0 support in the VM settings (VERR_NOT_FOUND)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component ConsoleWrap, interface IConsole

Details: 00:00:01.074731 Power up failed (vrc=VERR_NOT_FOUND, rc=E_FAIL (0X80004005))
Looks like something went wrong in step ´Checking status on default´... Press any key to continue...

VirtualBox Extension Pack をインストールする

VirtualBox のサイトから Extension Pack をダウンロードしてインストールするだけで良いのですが、現在使用している VirtualBox の Version と同じバージョンの Extension Pack をインストールする必要があるので注意してください。


自分の環境では 5.2.8 だったので、「Download_Old_Builds – Oracle VM VirtualBox」から 5.2.8 の Extension Pack をダウンロードしました。



ダウンロードしたら、あとはインストールするだけです。
（バージョンが違うとインストールに失敗します）



これで、Docker toolbox で USB を使う準備が整いました。
今回は以上です。それでは。

Docker toolbox QuickStart ショートカットを起動したときに history にゴミが溜まるのを抑制する

Docker toolbox の QuickStart でシェルを立ち上げると、ものすごい量の history が溜まって邪魔だったので対策しました。

設定でできること

HISTCONTROL

HISTCONTROL 環境変数をセットしておくと、空白から始まるコマンドや重複するコマンドを履歴に残さないようにできます。

• ignoredups
  直前と同じコマンドの場合は保存しない
  

  command	history
  ls ls	ls
  ls ls -a ls	ls ls -a ls

• ignorespace
  空白から始まるコマンドは保存しない
  

  command	history
  ls ls	ls
  ls ls -a ls	ls ls -a ls

• ignoreboth
  ignoredups + ignorespace
  
• erasedups
  重複するコマンドは最新のものだけが保存される
  （履歴にある重複コマンドは削除される）
  

自分は以下のようにしました。

export HISTCONTROL=ignoreboth

HISTIGNORE

HISTIGNORE に履歴に残したくないコマンドを列挙できます。
コマンドとコマンドの区切り文字は ':' です。

自分は以下のようにしました。

export HISTIGNORE=history:echo:'#*'

設定だけでは限界がある・・

上記の設定をしても、すこしだけ残ってほしくない履歴が減るくらいです。
自分でコマンド打つときにも便利な設定なので、しておいて損はないですが、当初の目的はこれだけでは達成できません。

というわけで、次に続きます。

start.sh を書き換える

できれば外部から非侵入的に解決したかったのですが、自分の知識ではここまでが限界でした。
Docker Toolbox のインストールディレクトリ「C:\Program Files\Docker Toolbox」に start.sh があります。
ショートカットはこちらの .sh を呼び出しており、こちらを少し書き換えることで対策しました。

ファイルの先頭で set +o history をして履歴を無効にします。
※ここで set コマンドの前に１つスペースを上げていることに注意。最初の設定で空白で始まるコマンドを履歴に残さないようにしたので

set +o history

#!/bin/bash
 set +o history

そして、ファイルの末尾あたりで set -o history で履歴を有効にします。
bash の呼び出しあたりは先頭空白を入れて、HISTCONTROL による抑制が効くようにしました。

set -o history

 if [ $# -eq 0 ]; then
   echo "Start interactive shell"
   exec "$BASH" --login -i
 else
   echo "Start shell with command"
   exec "$BASH" -c "$*"
 fi

最後に

これで設定は以上です。
きれいになりました。

GitHub Actions で [ci skip] できるようにしました

[ci skip] とは

多くの CI サービスで採用されている、コミットメッセージでビルドスキップができるコマンドです。
ドキュメントのみの更新とかでわざわざビルドしなくてもいい場合に便利な機能です。

GitHub Actions における ci skip

GitHub Actions は Azure Pipelines から派生しているので
「***NO_CI***」が使sえるかな？と思っていましたが、それはない模様。

* Build pipeline triggers - Azure Pipelines | Microsoft Docs
* GitHub Actions ***NO_CI*** alternative - Stack Overflow

Azure Pipelines ベースなので、一般的な 「[ci skip]」 も使えません。
つまり、GitHub Actions では現状 CI をコミットコメントからスキップすることができません。


・・・とはいえ、スキップしたい！ということで今ある機能でなんとかできないかやってみました。

Workaround

steps.if でなんとかしてみた

steps.if は条件付きでステップを実行するかしないかを制御する機能です。
これがあったので、以下のようにすることで、「ステップ」のスキップは実現できていました。

steps:
    - name: Check condition
      if: "! contains(github.event.head_commit.message, '[ci skip]')"

上記の方法で、最新コミットのコミットメッセージに「[ci skip]」が含まれていたら、そのステップをスキップすることができます。
ただ、これはあくまでステップのスキップなので、他サービスの [ci skip] とはだいぶ異なります。。

job.if がキターー

GitHub Actions - new workflow syntax features - The GitHub Blog
job 単位での制御がしたい！と思っていたら来ました！！

jobs:
  build:
    runs-on: ubuntu-latest
    if: "! contains(github.event.head_commit.message, '[ci skip]')"

steps.if のときと書き方は同じで、job のところに書けるようになりました。
これで job のスキップができるようになりました。

受け入れジョブを作ってそこを起点にする

さらに他 CI サービスでの挙動に近づけるために、依存関係を作成します。
[ci skip] をチェックするジョブを起点にジョブをぶら下げることで、スキップしたジョブの後続もスキップするようにします。

jobs:
  prepare:
    runs-on: ubuntu-latest
    if: "! contains(github.event.head_commit.message, '[ci skip]')"
    steps:
      - run: echo "${{ github.event.head_commit.message }}"

  build:
    runs-on: ubuntu-latest
    needs: prepare

prepare ジョブがスキップすると build ジョブもスキップします。
これで完成です。

スキップ結果

スキップすると以下のように表示されます。


checks にはのらないようです。（CI サービスによっては出たりする）

まとめ

ci-skip/WORKAROUND.md at master · srz-zumix/ci-skip
いろいろ説明を省きましたが、こちらで今回の方法をまとめいます。

今回のポイントは github context の使い方かな、と思います。
公式ドキュメントの github context では省かれていますが、ドキュメントの表以外にも取得可能な情報がたくさんあります。
今回は 'github.event.head_commit.message' でコミットメッセージを取得しました。

↑のまとめに github context から取得できる値の例と、ダンプ方法も書いてあるので参考にしてください。

最後に

私が使っている CI サービスでの [ci skip] 機能に関して、まとめているリポジトリがありますので
他のサービスでの [ci skip] を確認する場合、よろしければこちらも参考にしてください。

https://github.com/srz-zumix/ci-skip


では。

[Sider] goodcheck.yml not found を直して頂いた

結論

.gitattributes の export-ignore 指定がされているファイル・ディレクトリは、検証対象になっていなかった。
この挙動を修正していただき、export-ignore されているものも検証されるようになった。

経緯

iutest で Sider を使わせていただいていたのですが、
実はだいぶ昔に goodcheck 使おうと思って有効にしたものの、ずーーーっと警告が出ていました。。
対応しないとなーと思いつつ、後回しにしてきたのですが、
つい最近、Slack 通知が以下のように変わったのがきっかけでした。


ご覧のように新しい通知はシンプルになっていいとは思うのですが、以前の通知にあった「Warnings」が消えてしまいました。
この表示が消えたらたぶん一生そのままなんだろうなーと思い、重い腰を上げました。



で、yml いじったりしてみたのですが、
にっちもさっちもいかなかったので、右下から質問して解決に至るわけです。

最後に

• 日本語で話せるの楽（いろんなサービスでチャットっぽくサポート受けられるのが定番になってるけど、日本語の安心感）
• 挙動が変わったので注意（export-ignore 使ってることってほとんどないかもしれないが）
• 同じところでハマって諦めた人に、どどけ～
• サポートありがとうございましたmm

[Codefresh] PR comment に特定の文字列があったらトリガーする

Codefresh の Free Plan では1ヶ月のビルド数制限があるため、すべてのブランチや PR に対してテストを実行しないようにしています。
が、たまにこの PR でも Codefresh のテスト回したいなーというケースがあったので、PR の comment に反応してテストが実行されるようにしてみました。

(※ Codefresh の Free Plan はちょっとよくわかってないことがあるので、ビルド数制限なにそれ？な場合もあるかも。詳細：「ブログズミ: [Codefresh] Free Plan の内容がよくわからない・・」)

設定の仕方

まず、プロジェクトのパイプライン設定を開きます。
右側に「TRIGGERS」のタブがあるのでそれを開きます。


「ADD TRIGGER」を2回押します。


「GIT」を選択して、次へ。


「TRIGGER BY」は「Pull request comment added」のみを選択。


「PR COMMENT(REGEX EXPRESSION)」に特定の文字列を識別する正規表現を入力します。
今回は「run codefresh」がコメントに含まれていたら、TRIGGER されるようにしてみました。

設定は以上です。

キックしてみる

PR に「run codefresh」とコメントすると、ビルドが始まります。（CI 失敗してるのは気にしないでください）
テストリポジトリはいつもの iutest です。

まとめ

フリープランで CI を使わせていただていると、ビルド制限で困ることが多いです。
ブランチフィルターなどで実行数を減らすことができますが、逆に、フィルターアウトされるブランチでもテストを実行したいケースがでてきます。

そのようなケースに備えて、コメントトリガーに対応しておくと CI Life がより快適になります。
今回は Codefresh で行いましたが、他の（コメントトリガーできる）CI でも随時対応していきたいと思います。

では。