master/main 混在している git submodule すべてをデフォルトブランチ最新にする

Git - サブモジュール

git submodule update --remote

以上！

---

下書き終えて、清書したら公開できる状態にしてあったのですが、git コマンド一発で解決することがわかったのでこの記事の↓↓の方の内容は読まなくて OK です。
でも、この過程ももったいないので残しつつ公開することにしました。
こういうときに Zenn のスクラップが便利なんだろうなーと思いました。

---

 GitHub のデフォルトブランチが master から main に変わって大分経ちました。
筆者も切り替わってから設定を master に戻すことはせず使ってきましたが、たまーに GitHub Actions の branches 指定を master/main で間違うくらいで特に困ってはいませんでした。

筆者の場合は、既存のリポジトリは今までのまま master としており、新規は main がメインブランチ（デフォルトブランチ）という感じになっています。
この状態の方も結構多いのではないでしょうか。

今までは特に困ってなかったのですが、ついに面倒くさい状態になったので備忘録を残しておきます。

なにが起きた

master がデフォルトブランチのリポジトリに複数のサブモジュールがぶら下がっているリポジトリがありました。
サブモジュールも含めてすべてデフォルトブランチが master でした。
ところが、ここに新規作成した新しいリポジトリをサブモジュールに追加したことで、main がデフォルトブランチのサブモジュールが増え、master/main 混在状態になりました。

でも、これだけであれば、まぁ git 操作時にうち間違えて面倒くさいってくらいだと思います。

サブモジュールの自動更新ジョブが止まった・・

問題が起きたのはサブモジュールの自動更新ジョブでした。
このジョブは毎日サブモジュールをデフォルトブランチ最新にし、commit/push するというものでした。
このジョブを作成した当時はデフォルトブランチは master だけだったので、特に気にせず master から pull してきてました。
はい。そうです。
main がデフォルトブランチのサブモジュールができたことで失敗するようになってしまいました。。

どうしたか

まず main → master を考えましたが、時代に逆行するのでやめました。（サブモジュール増えるたびに踏み抜きそうだったし）
次に master → main を考えましたが、これも面倒くさいのでやめました。

デフォルトブランチは検出することが可能なので、検出する action を書いたりもしましたがサブモジュールだと使いづらいというか、無理な感じだったので最終的にはデフォルトブランチを git submodule foreach 時に検出するようにしました。

コマンドはこんな感じです。

git submodule foreach "git remote show origin | grep 'HEAD branch' | awk '{print \$NF}' | xargs -I{} git pull origin {}"

デフォルトブランチを知る方法は他にもあるので調べてみてください。

では、今回は以上。

xcpretty で compile_commands.json を出力しても空になってしまう理由がわかった！

 １年以上前に非 CMake プロジェクトからなんとか CMake にできないかなーと思って compile_commands.json を仲介させる方法をやろうとしたけど、そもそもうまく出力できなかった理由が今日わかったんで備忘録！

原因は ccache

そのプロジェクトは ccache を利用しており、CC/CXX に ccache_wrapper.sh みたいなのを設定していました。最近 infer を試してて xcodebuild capture じゃうまくできなかったので、compile_commands.json でやろうとしたら１年ぶりに同じ罠にハマったのですが、今度は乗り越えた！圧倒的成長！！

xcpretty の parser.rb を見れば一目瞭然でした
https://github.com/xcpretty/xcpretty/blob/master/lib/xcpretty/parser.rb#L63

コンパイラー検出用の正規表現的に clang で終わるような CC じゃないと認識しれくれないかったのです。
ccache_wrapper.sh じゃなくて ccach_wrapper_clang だったらセーフだった・・

対応方法

CC/CXX はプロジェクトで設定されているので、xcconfig を食わせて CC/CXX を上書きするようにしました。

cxx.xcconfig

CC = clang
CXX = clang++

export XCODE_XCCONFIG_FILE=/path/to/dir/cxx.xcconfig 
xcodebuild -scheme XXX -project XXX.xcodeproj -configuration Debug -dry-run build | tee ./build.log | xcpretty  --report json-compilation-database --output ./compile_commands.json

ちょーすっきりした

【OSS】Miro 風ホワイトボード ourboard を立ててみる

 Miro はオンラインで共同編集可能なホワイトボードツールです。
リモートワークが増えた昨今、こういった共同編集ツールの需要が増えたのではないかと思います。私も仕事で Miro を使う機会が何度かありました。

こういったサービスはとても便利なのですが、仕事で使うには社内手続きが面倒だったり、そもそもクラウド NG などで使えないってケースもあると思います。

そういうときは OSS な類似ツールがないか探して使ってみることが多いです。
「ホワイトボード OSS」とかで検索すればいくつか候補が出てきます。
今回はその中でも Miro っぽい ourboard を使ってみることにしましたので、docker でサービスを立ててみました。

リポジトリはこちらです。
https://github.com/srz-zumix/docker-ourboard
git clone して docker-compose up すれば立ち上がります。
他の ourboard 紹介記事が db だけ docker 、ourboad はホストに立てていたのですが、こちらは ourboard も docker コンテナにしています。
（パスワードとかデフォルトのまま決め打ちになってるので適宜変えてください）

起動したら localhost:1337 をブラウザで開きます。
付箋・エリア・テキスト・矢印が使え、Undo/Redo にも対応しています。
↓の画像ではフレーム分割して薄いピンクの枠で囲ったところで同じページを開いて共同編集している様子です。相手のカーソル位置が表示されているのがわかります。
フレーム分割はこちら（TampermonkeyUserScripts）の iframe-splitter を使っています。

Miro は↓のような感じです。ourboard のほうが機能は少ないですが使い方は大分似ていると思いました。

ourboard は https://www.ourboard.io/ で試しに使ってみることもできますので、そちらで試してみてから検討しても良いと思います。

今回は以上。では。