0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

本稿でいいたいこと

QiitaCLIを使ってQiita投稿イベントに記事を投稿する時は、Webエディタが必須になるためupdated_atが必ず更新される事を認識しておこう

なぜか?

  • QiitaCLIで完結できず、Webエディタでの操作が必須
  • QiitaCLIで投稿イベントへの紐付けができない
  • Webエディタで本文もタグもタイトルも変えずに、イベントを追加する更新をしただけでも、 npx qiita pull でコンフリクトを起こしてしまう

当初想定と罠

QiitaCLIで記事を書けばGitHubのコントリビューションにも反映されるし、Qiitaにも投稿できるしでメリットしかない!という発想だった。
ZennもCLIを使っているので、その感覚で考えていたところもある。

ここに、Webエディタでも編集できることの問題に気付くのは今日まで時間がかかってしまっていた。
いや、違和感はあったがなんとか付き合っていこうと考えていた。

が、どうしても受け入れられなくなった。
「QiitaCLIで出来ないことをWebエディタでフォローすれば大丈夫でしょ」という感覚だったが、Webエディタを使うとどう足掻いてもコンフリクトを起こしてしまう
回避する手段もあるが、現実的ではない。

仕様を確認する

QiitaCLI

QiitaCLI-CIで新規に記事を投稿する場合、updated_atとidを空欄にしておくと、新しく記事の投稿情報が得られる
具体的には以下

  • npx qiita push 時に記事が投稿され、同時にupdated_atとidが更新される
  • QiitaCLI-CIは、更新された後の情報を適用するようにgitにコミットする

ここだけ切り取ると、何もおかしなところはない。それどころか、元記事を修正しやすいように自動的に当該記事のフロントフォーマッター部分を追記してくれる。
神がかってるな!と、当時の私は考えていた。なんなら「イベントに登録できないのはしょうがないか」ぐらいに考えていた。

QiitaのWebエディタで編集をすると、QiitaCLIでコンフリクトを起こす原因と、躓きやすいポイント

ここでは、QiitaCLI上で管理している項目に対して、一切の変更を加えることなく操作ができる、という思い込みが問題であることを言及しておく。
まず、Webエディタで編集をする。記事の内容もタイトルもタグも変えない。やったのは、エンジニアフェスタのキャンペーンに登録する。それだけだ。
先述した通り、これだけの作業でも必ずフロントフォーマッター部分は更新されるようになっている。具体的には updated_at である。
見た目上何もしなくても更新ボタンが押せてしまう事が、まさかこんな問題になるとは、この時は思いもしなかった。

私の頭の中は「何も変更していないので差分はなし。ただし、キャンペーンには後から登録できる」という考えだった。
上記の通り、差分は必ず発生する。

QiitaCLIで編集する

さて、Webエディタで編集したので、本来であればQiitaCLIで npx qiita pull しなければならないが、毎度のこと「あの記事を更新したから、編集する前にpullしよう」なんて思わない。
なんなら「とりあえずqiita pushしておいて、後から編集で追記すればいいよね」とまで考えている。

ここで、

  • QiitaCLI: updated_atが差し替えられていない状態で、本文などが変更された内容を保持する履歴
  • Webエディタ: updated_atだけが更新されている状態の、その他は前回のコミットから全く変更されていない履歴

がそれぞれに存在する。

当然、それぞれの履歴が異なるが同一ファイルを編集しているという扱いのためにコンフリクトを起こしてしまう。

で、 npx qiita pull はコンフリクトの解消はしてくれない。git pull(git merge)とは違うようだ。
人間の感覚としては「そんなもん、それぞれの前回の履歴と比較して変わっているところだけをそれぞれから抽出してくれよ」と思ってしまうわけだが、これが出来ないのでgitのような感覚でqiita pullを使うと危険である。

さらに、QiitaCLI-CIを使って初めて npx qiita push に失敗する事に気付けるので、直前までWebエディタ側の更新を誰も把握できないことになってしまう。
CIで運用する以上、トリガーとなる要素はpushやスケジュールを想定していると思われるため、このタイミングでは既にgitの履歴としてみた場合でも違う歴史になってしまう。

コンフリクトを解消する

やり方は単純で、今あるGitHubでの最後のBotのコミット履歴に戻ってqiita pullした後に今回の変更を適用するしかない。
コンフリクトが発生した履歴は消すか戻すかのどちらかで対応する必要がある。

その上で、updated_atを修正してコミットする。
決め打ちでupdated_atを差し替える事で半自動化は可能だが、問題の解消にはやはり運用対処が必要になってしまうだろう。

ポイントまとめ

  • QiitaCLIを使うことでGitHubのコントリビューションに反映することができる
  • QiitaCLIを使って記事のバージョン管理をしたいなら、Webエディタは使えない → 使ってはならない
  • Webエディタを使った場合、コミットする前にqiita pullする

これでGitHubとWebエディタを併用しながらQiitaCLIを使う事ができる

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?