背景
railsでdelay_jobやwheneverを実装し、ローカル開発環境では問題なくジョブが走った。
しかし本番環境にデプロイ後、ジョブが走らなかった。
エラーログを確認したところrailsのbinディレクトリ以下の各ファイルの権限が644となっており、実行権限がないことが判明。
だとしたら、ローカル開発環境でも動かないはずだろ？？
そんな思いからいろいろ調べてみた。
windows環境でのgitbashはchmodが効かない！！
chmod 777 ファイル名してもchmod 644 ファイル名してもchmod o+w ファイル名しても何しようが権限が変更されない。
大丈夫！
これはwindowsの仕様の問題らしい。
なのでスッキリあきらめよう！
git addするとパーミッションが自動的に変更され644になってしまう！！
これはgitの仕様。
おそらくですが、大規模開発を想定し、ファイルパーミッション管理の保守性を向上させているのでは？と自分なりに理解してみる。。
以下のように.git/configのfilemodeがデフォルトでfalseになっていると、パーミッションを変更してもgit addすると644になってしまうのです。
では、どうやってパーミッションを変更するのか？
例えば、test.rbに実行権限を付与したいときは以下のコマンドを実行する必要があります。
git update-index --add --chmod=+x test.rb
update-indexのインデックスってなんだ？
ここでgit update-indexのindex（インデックス）ってなんだ？という疑問が沸きます。
インデックスはgit addした時にファイル状況が保存される領域のことです。
-
git addワーキングツリー → インデックス -
git commitインデックス → ローカルリポジトリ -
git pushローカルリポジトリ → リモートリポジトリ
という感じです。
つまり、インデックス領域に対して権限変更処理を実行しておけばコミット先で644に変更されないというgitの仕様が存在しているのです。
ではインデックス上での権限変化をどのようにして確認するのか
残念ながらwindows環境だと、ls -laしても変化は確認できません。
（chmodが機能しないので、権限を変更させられないという方が正しい言い回しかもしれないです。）
（Windowsの仕様なので、ここはあきらめましょう！）
ではどうやって権限変化を確認するのか？
以下のような流れで確認します。
- 該当ファイルを
git addしてインデックス領域に入れて置く。 -
1.を実行するとgit ls-files -sでインデックス内のファイルの権限を確認できます。実行してみるとこの時点では644になっています。 -
git update-index --add --chmod=+x test.rbして実行権限を付与。 - 改めて
git ls-files -sでインデックス内のファイルの権限を確認。 - しっかりと
644→755になっていることがわかります。（さらにgit update-index --addでは所有者、グループ、ユーザすべてに働きかけていることも分かります！）
まとめ
つまりローカル開発環境でジョブの実行がうまくいったのは、ワーキングツリー上で確認できるよう、実行権限が付与されているため。
その後git addすることでパーミッションが644に変更してしまったので、それをもとにコミット、デプロイしている本番環境ではジョブが実行されなかったという事なのです。
長々と話しましたが、実行権限をつけておくべきファイルに対しては、git update-index --add --chmod=+x ファイル名を忘れないようにしましょう。
特に本番環境適用時には注意しましょう！