2019年12月17日火曜日

ゆく 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 に対応しましたね。と言いたいところでしたが、去年の話でした。


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



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


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 はなし。。

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

年明けにこの記事を見返してみて、試せることはやってみたいと思います。
では。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2019年12月10日火曜日

[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 比較してみました。
CInproc
Circle CI36
Cirrus CI32
GitHub Actions2
Peakflow16
Travis CI2

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


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

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





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

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

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2019年12月6日金曜日

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

※ この記事は「C++ Advent Calendar 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++ にプライベートはあった

投稿者 時刻: 0 件のコメント:
ラベル: , , ,
登録: 投稿 (Atom)