Prevent crashing when files were removed

[milgner]

When a file was removed in the changeset, pronto would try to open it, leading to errors like

Errno::ENOENT: No such file or directory @ rb_sysopen - ...

This patch makes sure that the method returns false as expected.

[mmozuras]

@milgner could you expand on when it happens?

Because ideally, it should never happen. Pronto only cares about what was added. If a file was removed, Pronto should not try to open it.

[milgner]

Unfortunately I did not dig very deep into this. But one of our changesets removed a file and pronto tried to open it and crashed. The backtrace lead me to this location and after applying the patch, the error disappeared. I can try to find the output of our CI to illustrate but right now I did not find a way to quickly search all builds for a specific message.

[mmozuras]

@milgner having a repro would be immensely helpful. I think that what you describe could potentially mask some greater underlying issue, which I would like to try and find.

[milgner]

I totally understand! Right now I just came across a situation that might be related: Pronto is annotating problems on the removed part of the changeset, saying for example "Line is too long. [81/80]" on an old view template where the updated version isn't that long anymore. If it is looking at old file versions there then it might be the same code path that tried to open a deleted file, too.

For reference, this is how we invoke Pronto from our CI script:

bundle exec pronto run -c origin/develop -f github_pr github_status

[mmozuras]

@milgner thanks for the additional info. Which version are you using?

[milgner]

Current version in Gemfile.lock is 0.7.0.

[mmozuras]

@milgner it could be another manifestation of an already fixed bug (#149, #170) in 0.7.0. Could you update to 0.7.1 and check if it solves the issue?

[mmozuras]

@milgner any news? 😄

[milgner]

After updating to 0.7.1 the problems seem to have been tackled. Thanks for the assist, I'll close this PR.