とある開発プロジェクトで、開発員4名ほどのチーム開発を行っています。
みんな優秀なエンジニアで、これまで何か作業をする時に、GITやDockerの環境を整えるところからスタートしていたのが、
「GithubからリポジトリをCloneしておいて」というだけで、みんな自分の書いたREWADMEを見て環境構築が完了していたので、
使えるエンジニアと仕事をするって「なんて気持ちがよくて効率的なんだ！」と改めて気がついてしまいました。（当たり前やろ！）
そんななか、その開発エンジニアの中の一人が、「GitでPUSHできない！」と慌てふためいていたので、その顛末をブログに残しておきたいと思います。
400エラーが出た！
そのエンジニアは、自称「オレなんでもできるフルスタックエンジニアです」という自己紹介からはじまり、
まあまあなオッチョコチョイなエンジニアだという事はすでに理解済みです。
GitをCloneして、環境構築をする時に、他のエンジニアに聞こえないように、
「自分、Dockerよくわからないんですよね・・・」
と耳打ちしてきたので、こっそりとコマンドを教えてあげていました。
そして、それぞれ自分の更新分をGithubにpushして、リポジトリを更新しようとしていたところ、
そのオッチョコチョイエンジニアのpush時にだけ、以下のエラーメッセージが出ていました。
error: RPC failed; HTTP 400 curl 22 The requested URL returned error: 400
ホント、かわいくて憎めないヤツですね。
エラーの原因
このエラーは、PUSHするファイルが、2MB（1MBと解説しているページもあったので、大体の目安で）のファイル容量が含まれていて、
POSTデータの容量オーバーと言う事での400番エラーと言う事がわかりました。
腑に落ちないこととして、自分がPUSHしたブランチには、数MBの容量の画像データなどがたくさん入っている事を考えると、
特定の環境だけ容量制限が入っているのは何かおかしいと考えられる。
やはり、そのエンジニアの環境に問題があるはず。
どうやら、pushした時に、別のアラートも出ていて、
githubのアカウントと、pushした時のリポジトリのconfigに登録されている名前やメールアドレスが違っているらしく、
エラーじゃないけど、warningが出ていたようです。
もはや、そいつの環境が原因なのはかなりの高確率なのがわかりましたよね。
この400エラーの解決方法で、他のサイトなどに書かれているのは、postBufferという、アップロードファイルの容量を上げる設定をconfigに書くように、以下のコマンドが解説されています。
git config http.postBuffer 500M
でも、これって今回の環境において、最善策ではなく、本当の原因は別のところにありました。
本当の原因
フと思い出して、そのエンジニアに以下のコマンドをうちこんでもらいました 。
git remote -v
これで、表示されたURLのプロトコルで、原因が判別できました。
origin git@github.com:project-name/ripository.git (fetch)
origin git@github.com:project-name/ripository.git (push)
ssh接続でcloneされた場合、このような表示がされますが、
そのエンジニアの表示は、以下のようになっていました。
origin https://github.com/project-name/ripository.git (fetch)
origin https://github.com/project-name/ripository.git (push)
そうです、https経由でcloneしていたんですね・・・
ちゃんとコラボレータにも登録されているのに、httpsって・・・orz
少し解説
GitのClone時に、httpsと、sshと、Github CLIの3パターン用意されていますが、
単に今現在のリポジトリをcloneしたいだけならhttpsでいいんですが、
プロジェクトとしてpushする場合は、SSHまたはCLIが必須なんですよね。
SSHを使う場合は、事前に鍵の登録とか、色々な事前設定が必要になるんですが、
このエンジニアはそういう知識がなかったのか、安易にhttpsでcloneしていたという事でしたね。
お前、本当にフルスタックエンジニアなのか？
と、その場にいたエンジニアみんなが考えたに違いない。
あとがき
エラーが出た時に、そのエラーを調べるとだいたい答えに辿り着きますが、
今回のように、間違ってはいないけど、本体の修復方法になっていない場合の回答もネットには数多くあります。
こうしたことも一つの経験として、スキルアップのタネになると言う事がわかった、今回の出来事でした。
このブログも、他のエンジニアのタネになることを願っております。
0 件のコメント:
コメントを投稿