ラベル 備忘録 の投稿を表示しています。 すべての投稿を表示
ラベル 備忘録 の投稿を表示しています。 すべての投稿を表示

2021年4月21日水曜日

docker build ログを今まで通りに表示する

 docker build したときの出力がなんかいい感じにまとめられてコンパクトになりましたね。


でも、RUN した出力を知りたいんじゃ！ってこともあります。
そんなときは docker build --progress=plain で OK




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

2021年3月11日木曜日

wandbox-builder のテスト環境構築

 最近 Wandbox のコンパイラー環境を作成する wandbox-builder に PR 投げまくっており、その際のテスト環境構築で詰まったところを備忘録としてメモしておく。
なお、本流にマージしても問題ないだろうと思う部分は PR を出しています。

kennel.json の修正

https://github.com/srz-zumix/wandbox-builder/pull/1/files#diff-39e78c9920d894556bc58bc9693d6357a2737275ce6c2ac89198d8caed4e3c64
Wandbox の更新に追従が必要です。
.session.key と db ファイルはテスト環境のものを参照するようにし、それらのファイルは追加・作成するように変更しています。

ip 制限処理への対応

https://github.com/srz-zumix/wandbox-builder/pull/1/files#diff-8339ab6ea29831802ca594668bddeb7e22d576a0cee4bb6a5492cb104492c98f
Wandbox で ip 制限がかかるようになったのですが、テスト環境からテストスクリプトを実行した際に「 [warning] [kennel.cpp:409] X-Real-IP is empty」となり、失敗していました。
ヘッダに「X-Real-IP」を追加して回避しました。
（これが正攻法なのかはわからないです）

setuid の失敗への対応

こちらは筆者の実行環境が macOS なのが関係してるかもしれません。
マウントしたパスへの setuid が以下のように失敗するようなので、cattleshed の設定で uids オプションを削除するようにしました。
「cmake-head: {u'status': u'1', u'compiler_error': u'setuid: Operation not permitted\n', u'compiler_message': u'setuid: Operation not permitted\n'}」

https://github.com/srz-zumix/wandbox-builder/pull/2/files

以上、Wandbox に言語やコンパイラバージョンを追加したい場合の参考になれば幸いです。

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

2020年12月1日火曜日

[C++] Concepts で外部ライブラリの template よりも優先されるオーバーロード関数を書く

※この記事は C++ Advent Calendar 2020 一日目の記事です。

はじめに

 C++20 で Concepts が導入されました。
コンセプト - cpprefjp C++日本語リファレンス

コンセプトはテンプレートパラメータを制約する機能で、「コンセプトによって関数オーバーロードやテンプレート特殊化」ができます。
今までテンプレート関数のオーバーロードを書く場合は SFINAE などのテクニックを使って書いていたと思いますが、コンセプトで書きやすくなりました。
これも大きな変化の１つですが、コンセプト関数が通常の関数よりも優先して lookup されるのも便利になった点の１つです。
コンセプトによるオーバーロードの場合、コンセプト関数が通常の関数よりも優先して lookup され、要件を満たすコンセプト関数がなかったら他の候補を探しに行きます。SFINAE では優先順位がつけられないケースでもコンセプトなら可能になりました。

どういうこと？
SFINAE では解決できなかった優先順位問題とコンセプトを使った実装の例

↑こちらは、std::cout << できない型の場合は "unknown" を出力するようにしようとしている様子です。

donot-change.h には std::cout するだけの template 関数 print があります。
こちらは変更ができない想定です。（外部ライブラリとか）

SFINAE.cpp では頑張って、 std::cout ができない場合で特殊化しオーバーロードしようとしてます。他の書き方を書いたりもしましたが、どうしても ambiguous になってしまって条件を満たすことができませんでした。

一方 Concepts.cpp は printable ではないコンセプト制約でオーバーロードするだけで実現できています。
すごく簡単ですね。

ちなみに
ちなみに donot-change.h を変更可能とした場合は、以下のように書くことができます。
namespace printer_internal
{
template<typename Elem, typename Traits, typename T>
::std::basic_ostream<Elem, Traits>& operator << (::std::basic_ostream<Elem, Traits>& os, const T&)
{
    return os << "unknown";
}
}

// 解決順序
// foo::operator <<
// ::operator <<
// ::printer_internal::operator <<
template<typename T>
void print(const T& val)
{
    using namespace ::printer_internal;
    ::std::cout << val << ::std::endl;
}
これは ADL の解決順序を利用して実現しています。
[Wandbox]三へ( へ՞ਊ ՞)へ ﾊｯﾊｯ https://wandbox.org/permlink/rlQoH37cvYTI23qo 
使い所は？
例でも示したとおり、オーバーロードしたい対象の関数を変更できるのであれば、そちらで解決する方法を模索するのが良いと思います。
ただ、外部ライブラリなど変更することができない場合、非侵入的に解決する方法として覚えておくと役に立つ日が来るかもしれません。

実例
そもそも私がなんで外部ライブラリの挙動をオーバーロードで変更したいと思ったのかというと、以下の理由でした。

* Google Test はアサーションが失敗すると、そのときの値を出力します
* std::cout できない場合はバイト列を出力します
* できない場合の対応は「ちなみに」の ADL を利用した方法で実現されています
* 古い Google Test ではこの機能がない
* 自作テスティングフレームワーク iutest は Google Test と互換性がある
* iutest は Google Test の拡張機能としての一面もある
* 古い Google Test と iutest の組み合わせでも不明な型を printable にしたい
* Google Test 側のコードは書き換えられない
* どうしよう

実際にコンセプトで対応してる部分はこちらになります。
最後に
教えていただいた いなむのみたま(@mitama_rs) 先生ありがとうございました。
ちなみにそのツイートにもぶら下がってますが、C++20 未満のコンパイラでこの問題を解決する方法も募集しておりますmm


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

2020年11月2日月曜日

Docker login しているか確かめる方法

前置き

 ダウンロードレート制限 | Docker ドキュメント

いよいよ DockerHub の Download Rate Limit が始まりましたね。
この制限は徐々に導入していくとありますが、さてどんな状況でしょうか？
（この記事は 11/1 に書いています）

特に懸念されていたのは CI サービスでの制限です。
DockerHub にログインしていない場合は IP に対して制限がかかるため、利用者の多いサービスではあっという間に上限越えて、制限がかかってしまうことが予想されました。
これに対し、すでに（期限付きではありますが）制限を受けないようにする交渉が完了しているサービスもあります。

DockerHub による2020/11からのコンテナイメージ Pull 回数制限のCircleCIへの影響 - Build Environment - CircleCI Discuss

ある程度猶予があるかもしれないですが…
何れにせよ、今後 DockerHub からイメージを pull して CI を回す場合は、事前に DockerHub へのログインをするようにパイプラインを更新しておくのが良さそうです。

それらへの対応方法についても、記事冒頭のドキュメントからリンクが貼られていたり、各 CI サービスから案内が出ていると思います。

筆者が開発している C++ テスティングフレームワークの iutest はめちゃくちゃたくさん CI サービスを使っているので（Docker 関係ないものもあるので全部ではないが）絶賛対応中です。

対応方法はログインするだけなんですが、各サービスやり方が異なるのでここでは対応方法は省略します。
一応、状況はこちらの issue で確認できます。
https://github.com/srz-zumix/iutest/issues/519

Docker login しているか確かめる方法

で、ようやく本題。
このログイン対応をしていて思ったのは、「設定したけど本当にログインした状態で pull できているのかをどう確認したらわからなくて不安」でした。

docker のコマンドに「それ」を確認するものがあればよかったのですが、なさそうだったので以下の方法で確認しました。

「echo a | docker login」

ログイン済みなら以下のように成功となります。

$ echo a | docker login
　Authenticating with existing credentials...
　Login Succeeded
$ echo $?
　0
ログインしてない場合は以下のように失敗になります。
$ echo a | docker login
　Error: Cannot perform an interactive login from a non TTY device
$ echo $?
　1
最後に
この方法をパイプラインに組み込んでみてないので、うまく CI 上で確認できるか未確認ですが、もっと簡単に確認できると嬉しいなと思います。もっと良い方アレば教えて下さい。
てか、直球なコマンドが欲しい。。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2020年10月12日月曜日

OpenSTF を Windows の Docker 上で動かす

CEDEC での講演もあって OpenSTF を使い始めた人も多いようなのでメモ。



講演でもお話ありましたが、 OpenSTF は DeviceFarmer に変わったそうですね。 （DeviceFarm と似てて検索とかしづらそう） 

OpenSTF のセットアップについては以下の記事が参考になります。


筆者もネットの情報を参考に立ち上げました。

OpenSTF 便利
OpenSTF はリモート操作のためのツールの印象が強いですが、開発者がローカルで実機確認するときにも便利です。
なぜなら、わざわざ端末を操作して社内システムにログインするためのユーザーID/パスワードの入力が必要なかったり、スクリーンショットも簡単に PC 側で取れちゃうからです。

Docker の勉強がてらローカル環境に立ててみることをオススメします。

docker-compose.yml と起動手順
使っている docker-compose.yml がこちら。コメントに手順も書いてます。


メモ
Windows でボリュームマウント
Windows だとホストマシンでマウントできる場所が限られてたりして面倒くさかったので、ホストマシンに DB の永続化をするのではなく、docker volume create したボリュームに永続化するようにしてます。（今はなんか Docker Desktop がいい感じにマウントできるようにする？って聞いてくれるので面倒くささ減ったみたいだけど）
端末が認識しない場合
adb サーバーが起動してないかも。
adb start-server をしてみてください。

端末を返却した際にインストールしたアプリをアンイストールしないようにする
デフォルト設定だと、OpenSTF で端末操作して返却するとその間の変更がクリーンナップされます。これはこれで便利なのですが、個人環境で利用する場合は不便にもなります。
クリーンナップしなくない場合は stf の起動オプションに  --no-cleanup を追加しましょう。
使ってみて困っていること・知りたいこと
たまに操作できない状態になる
USBの抜き差しで復旧したりするが、リモートワークな昨今、物理的な挿抜は難しい。
adb kill-server / start-server で復旧したりもする。
リモートで電源の通電操作が可能な機材（リブーター）が存在するので、それを使って AC 給電な USB-HUB の電源切断で、USB 挿抜をエミュレートできないかと思っている。（未検証）

ポートフォワーディング機能の使い方
端末上で実行しているアプリと特定ポートでお話できるかな？と思っているのだが、うまくいってない。機能を勘違いしているのかもしれないし、使い方・設定の問題かもしれない。

最後に
利用者が増えて知見が増えていくと嬉しいですね。
Airtest も便利なんでそっちも情報増えると嬉しい。（Android 10 になって minitouch 使えなくてツラミ）
以上。

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

2020年6月15日月曜日

[Visual Studio] .natvis/.natstepfilter をプロジェクトに追加してウォッチ・ステップインしやすくする

つい先日同僚からの情報で初めて知ったのですが、.natvis はプロジェクトに追加することでプロジェクト固有の Visualizer を設定できるようです。

.natvis って？という方は、過去に記事を書いているのでそちらを参照してください。

今まで Visual Studio 共有な形でインストールしていたので、プロジェクトごとに調整できるのは嬉しいですね！
また、.natvis は .pdb にも埋め込まれるようなので、起動した実行ファイルにアタッチしてデバッグ開始した場合でも、.pdb から .natvis を読み込んで適用されるようです。
（.pdb への埋め込みは設定で解除できます。詳細は最初のリンクへ）

iutest.natvis の例
.natvis がどのようなものか簡単に iutest が用意している .natvis で見てみたいと思います。（iutest は自作の C++ テスティングフレームワークです）

.natvis ファイルは以下。
  
<?xml version="1.0" encoding="utf-8"?>
<autovisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
  <type name="iutest::Test">
    <displaystring>{{ name={test_info_-&gt;m_testname}}}</displaystring>
    <expand>
      <item name="TestName">test_info_-&gt;m_testname</item>
      <item name="TestCaseName">test_info_-&gt;m_testcase-&gt;m_test_case-&gt;m_testcase_name</item>
      <item name="Results">test_info_-&gt;m_test_result</item>
    </expand>
  </type>
</autovisualizer>

これを読み込んでテストでブレークすると以下のように表示されます。


未加工ビューを開くと .natvis 適用していない素の状態を確認できます。


このように iutest では、this から不要なものを取り除いて見やすくした値が確認できるようにしています。

CMake に .natvis を追加する
普通に .natvis を追加すれば ok 。
iutest では、MSVC の場合には add_executable に .natvis を追加しています。

function(iutest_add_executable name)
if (MSVC)
  add_executable(${name} ${ARGN} ${IUTEST_ROOT_DIR}/tools/VisualStudio/Visualizers/iutest.natvis)
else()
  add_executable(${name} ${ARGN})
endif()
endfunction()
.natstepfilter はどうなのか？
Visual Studio の Visualizer にはステップフィルターもあります。
（Visualizer なのかな？って気がしてるが Visualizers ディレクトリに配置するのでそう呼んでる）
ステップフィルターについてはこちらも参考にしてください。

結論から書くと「まだできません」。要望が上がってはいます。

↑のブログでも書きましたが、GetInstance とかプロジェクト固有でステップインしたくないものって結構あると思うんですよね。
.natvis はグローバルにインストールされていても無害なことが多いと思いますが、ステップフィルターは条件をしっかり書かないと、他のプロジェクトのデバッグを阻害することになりかねないですからね。。
今後対応されることを期待します。

それでももう少し楽にできないか
現時点では、公式ドキュメントにかかれているとおりに、Visualizers フォルダにコピーして使うことになります。

チームメンバーに .natstepfilter を 「%USERPROFILE%\My Documents\<Visual Studio のバージョン>\Visualizers」 フォルダーにコピーして使ってというのも手間なんで、カスタムビルドルールで勝手にインストールされるようにしてみました。

.natstepfilter ファイルをプロジェクトに追加したら、ファイルのプロパティを開いて、項目を「カスタムビルドツール」にしビルドから除外を「いいえ」にします。
カスタムビルドツールの設定は、コマンドラインに「xcopy /I /Y "%(FullPath)" "$(VisualStudioDir)\Visualizers\"」を設定、出力ファイルを「$(VisualStudioDir)\Visualizers\%(Filename)%(Extension)」に設定します。

この状態でビルドをすると、.natstepfilter ファイルが Visualizers フォルダにコピーされ、デバッグ実行時にはコピーされた .natstepfilter がロードされます。
おまけ

std::string を s8 （UTF-8）表示する .natvis






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

2020年4月13日月曜日

[Git] submodule を非 submodule なリポジトリとしてコピペする

リモートワークされてる方が多いと思いますが、
ネットワーク絡みで困ることも多いのではないでしょうか。
めちゃくちゃでかいリポジトリの clone が全然終わらなくて・・ということが筆者もあります。
先日もとあるリポジトリを clone しようとして困ったことに。

そんなときは、clone じゃなく、既に clone 済みのワークスペースを cp して使うことがあります。
ただ、今回は submodule だったので諦めようと思ったのですが・・

submodule は .git フォルダは .git ファイルがある。

親の .git/modules には .git フォルダらしきものがある。


これはイケるのでは？と思ったので試してみた。
（※画像は個人開発のリポジトリです）

やってみた

まずは、submodule のディレクトリをコピー。.git ファイルは消す。
続いて、.git/modules から submodule 名のディレクトリを .git としてコピー。
コピーした .git ディレクトリ内の config ファイルを開くと worktree の設定があるので消す。


結果

これでうまくいきました。
まぁ、これを使うことってそうそうない気もしますが備忘録として。

今回は以上。
ではでは。


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

2020年3月31日火曜日

[CircleCI] CLI を Windows で使う

昨今の CI サービスは CLI ツールが用意されていることが多いです。
ジョブを実行したり、コンフィルのバリデーションをしたりでます。
だいたいは、ジョブを本番に push するまえにテストするために使うことを考えて作られていると思います。

CircleCI も例にもれず CLI コマンドがあります。
CircleCI のローカル CLI の使用 - CircleCI

インストール方法はこちらに記載されています。
ぱっと見 Mac/Linux のみで Windows 版はないようにも見えますが、ちゃんと存在しました。
「手動でのダウンロード」に「GitHub リリース」へのリンクがあり、そちらから Windows 版もダウンロードできます。


ダウンロードしたら任意のパスに展開し、パスを通せば普通に使えます。

例）バリデーションエラーの様子

修正前
workflows:
  default-test:
    jobs:
      - parallel1:
        i: 0
      - parallel2:
        i: 4

修正後
workflows:
  default-test:
    jobs:
      - parallel1:
          i: 0
      - parallel2:
          i: 4

↑の違いわかりますでしょうか？
i の位置に注目してください。


CircleCI の YAML はなんか他のサービスと比べてインデントが厳しい印象・・
こちらのエラーもインデントがずれていただけでした。これ気づくの難しい・・


正解は i のインデントレベルが 1 段違うだけでした。

最後に
コンフィグをいじる際に何度も本番環境でトライアンドエラーを繰り返すとクレジットを消費してしまってもったいないので、これからはローカルでバリデーションしてから push するようにしたいと思います。

今回は以上です。
では。
投稿者 時刻: 0 件のコメント:
ラベル: , , , ,

2020年3月3日火曜日

[技術書典] PDF から必要なページを切り出す

自分用備忘録。

見本ように表紙や目次を提出することがある。
その際に出来上がった PDF から必要なページだけ取り出したいと思ったときに毎回検索して調べているので、メモです。

「Chrome で PDF を開いて必要なページを指定して印刷する」

以上。


【宣伝】

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

2020年1月28日火曜日

Visual Studio のプロジェクト設定は共通部分を前に書こう

Visual Studio で複数の構成を扱っている場合がほとんどだと思います。
Debug/Release、Win32/x64 などなど。
MD/MT とかもありますね。dll/static lib とかもあるか。

それぞれ、インクルードパスだったり、プリプロセッサ定義だったりを書くと思いますが、私からのお願いです。

「各構成で共通な設定を先頭に書いてください」
「専用の設定を末尾に書いてください」

なぜか
Visual Studio で設定を編集する場合に、個々の構成に対して編集ができますが、
すべて・もしくは任意の複数構成で編集することもできるからです。
複数構成の編集をする場合、以下のように共通部分がそれぞれ表示されます。
差分があると「＜別のオプション＞」のように表示されます。

例：
Platformプリプロセッサの定義
Win32WIN32;_DEBUG;_LIB;
x64WIN64;WIN32;_DEBUG;_LIB;

Win32

x64

すべてのプラットフォーム


わかりますよね？
差分が先頭にあると、すべて「＜別のオプション＞」になってしまうのです。


共通部分を先頭に書く
共通部分を先頭にまとめておけば、複数構成で編集・閲覧するときに圧倒的に楽です！！
先程の例を修正してみましょう。

Platformプリプロセッサの定義
Win32WIN32;_DEBUG;_LIB;
x64WIN32;_DEBUG;_LIB;WIN64;

Win32 はそのまま、x64 の WIN64 を末尾に移動しました。

Win32

x64

すべてのプラットフォーム


いかがでしょうか？
差分を末尾に移動するだけで、こんなにも見やすくなりました。


もちろん、この状態で編集しても差分部分が壊れることはありません。


こちらは Visual Studio 2015 で試したものです。最新のバージョンでも同様です。
以上、私からのお願いでした。


P.S.
技術書典の進捗報告予定でしたが、カッとなって書いた。
技術書典の方は、執筆しつつも、今週はサークルカットを準備するのにほとんど時間を使ってました・・

では、また来週。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2020年1月15日水曜日

[技術書典8] Re:VIEW Starter で執筆を開始しました

こんにちは。連休・連休で作業時間があるにも関わらず、進捗乏しいずみっくすです。


ともあれ、本のとてもとても大雑把な目次はできたので、本にするための作業を始めようと思います。
タイトルの通り Re:VIEW Starter を使って執筆をすることにしました。



なぜ Re:VIEW Starter なの？
なんとなくです。
とりあえず、Re:VIEW で始めたらええよという話は聞いていたのですが、この記事「技術系同人誌を書く人の味方「Re:VIEW Starter」の紹介 - Qiita」を読んでなんか良さそうな感じだったので。

まぁ、でも使う前に疑問は解決しておきたいので、ハッシュタグつけてツイートしたら回答いただけました。

Re:VIEW Starter (Re:VIEW 2.5) vs Re:VIEW 4.0
Re:VIEW Starter を始めようとすると、まず目につくのが以下の注意文。
なお、現在のところ Re:VIEW 2.5 のみをサポートしています。
Re:VIEW 3.0 はサポートしていません（2.x との互換性がないため）。ご注意ください。

Re:VIEW の方を確認したところ、2020/1/10 現在は version 4.0 まで更新されているようでした。
Re:VIEW Starter を使う場合、Re:VIEW 3.0 以降の更新の恩恵を受けられないので、デメリットとならないかが気になりました。
また、Re:VIEW の方で review update コマンドで旧バージョンからのアップグレードができるようになっているようだったので、
Re:VIEW Starter with Re:VIEW 4.0 環境でも使える？という疑問がありました。



というわけで、Re:VIEW Starter を採用することにしました。

始める
では、「プロジェクト作成を始める」から作成を開始！

まずはサークル名（もしくは著者名）を入力します。
自分の場合、ぼっちなのでどっちでもどっちでも良さそうですが、とりあえずサークル名を入れました。
（あとで直す場合は config.yml の「aut:」を編集すれば ok みたいなので）


続いて、本のタイトルを入力します。
まだ決めてなかったですので、とりあえず埋めます。
（あとで直す場合は config.yml の「title:」を編集すれば ok ）


つぎに本のサイズを決めます。A5 か B5 か。
わかりやすい説明が書かれているのでイメージが付きやすいと思います。アドバイスも参考になります。
今のところどっちでもいいかなーという感じだったので、B5 にしておきます。
（あとで直す場合は config.yml の「texdocumentclass:」を編集すれば ok 。以降も後で設定は変更できるみたいなので、気軽に初期設定を済ませてしまいましょう）




次はフォントサイズと余白。
とりあえず、オススメの設定にしておく。


次はページの設定。
目次は左でもいいやーと思ったので、「章は右ページ始まりにし、目次は左右どちらからでもよい」を選択。（本っぽくなってきましたね）


つづいて章・節・項の見た目を設定します。
デフォルトは、章の行数を２行にだけ変えました。
項のクローバーも別の文字に変えたいなと思ったが、初期設定では変更できそうになかったので、のちのち変えたいと思います（調べてないけどできると思っている）


次は、コードブロック・ターミナル用のフォントフェイスを決めます。
「'」と「`」の違いが分かりづらいのは、自分が書く本の場合困ると思ったので「inconsolata」にしました。


コードブロックの見た目はデフォルトのままにしました。


その他のオプションは、「原稿ファイルを「contents」ディレクトリにまとめる 」を有効にしました。
めちゃくちゃたくさん書く予定はないけど、まとまっていたほうが好みなので。


最後に、もろもろ埋めます。（まだ未定なものがありますが適当に埋めました。あとで変えられますし）


これで完成！！
プロジェクトをダウンロードします。


コンパイルする
ビルド用の Re:VIEW 2.5 の Docker イメージが用意されているので、それを使ってコンパイルしました。
手順どおりすれば問題なくコンパイルできると思います。
（このへんは CI に組み込めそうなので、来週はそれ系の記事を書こうかな・・）

というわけで、ここまで躓くことなくできました！！


まとめ
正直、本を書くのは初めてなので、どれが良いとか悪いとかわからないです。
なので、使い始めたけど自分とは合わなかったから別のものに変える可能性もあります。
まずは、中身が大事ですからね。

というわけで、頑張って内容を埋めるぞー

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

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年11月27日水曜日

[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 環境変数が追加されます。

今回は以上です。
では。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2019年11月12日火曜日

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

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

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

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

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


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

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




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





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

2019年11月5日火曜日

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

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


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


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



今回は以上です。
こういうのでアクセス稼ぐんだろうなーという学び。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2019年10月23日水曜日

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 を使う準備が整いました。
今回は以上です。それでは。
投稿者 時刻: 0 件のコメント:
ラベル: , , ,
登録: 投稿 (Atom)