Silently omit git argument when git is unavailable

[nirizr]

Tries to fix #174

Alternatively, we could require a flag or take the test out of the git_info method although it seems fitting imo.

[GitCop]

There were the following issues with your Pull Request

• Commit: 9f2ccfc
• Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/coveralls-clients/coveralls-python

---

This message was auto-generated by https://gitcop.com

[nirizr]

Failures within the ci/circleci: check test seem unrelated. I think this PR is ready for review.

[jvarho]

Would it make sense to make this an option like --no-git instead?

That would make it explicit that you intended it and didn't e.g. accidentally run outside the repo. You'd probably want a warning from this check that mentions the options in that case.

[nirizr]

tbh I'm not sure the risk/damage of accidentally proceeding without git is high. worst thing you'll get something over to coveralls instead of nothing. Definitely warrants a warning though.

What do you think about adding a warning but keeping it the default to silently proceed without git? Perhaps a --require-git to turn the warning into an error instead?

lmk what you think is best and i'll have a commit doing whatever you pick.

[TheKevJames]

I personally think the flag would be overkill, but if you could please log a warning in the case where git support is not detected, that would be great.

[TheKevJames]

Could you please put the try catch around the already-existing commands? No need to run an extra git command here.

[nirizr]

I thought about that; the original reason I ended up adding a git status command was to avoid any possible errors related specifically to the existing commands, that may be because of something other than git not being available.

I can't think of a good scenario but an unlikely example could be having a git version that does not support the current command (or any future changes). Either because git version is too old or too new with backwards incompatible cli changes.

WDYT?

[TheKevJames]

That makes sense -- I think if we add the logging, something like "could not collect git data -- are you running coveralls in a repository?", along with logging the CoverallsException message (which contains the process output), that should cover it!

[nirizr]

Yes. Will amend with a more verbose log (and phrasing that's more to your liking).

[TheKevJames]

Ah, and as per the tests -- so long as only the unused-variable for __class__ is failing, that's no problem. Known issue with pylint, I will update it outside of this PR.

[GitCop]

There were the following issues with your Pull Request

• Commit: 017382d
• Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/coveralls-clients/coveralls-python

---

This message was auto-generated by https://gitcop.com

[GitCop]

There were the following issues with your Pull Request

• Commit: e215097
• Invalid type. Valid types are feat, fix, docs, style, refactor, perf, test, chore, revert

Guidelines are available at https://github.com/coveralls-clients/coveralls-python

---

This message was auto-generated by https://gitcop.com

[nirizr]

Pinging @TheKevJames @jvarho, any additional thoughts/comments?

[TheKevJames]

@nirizr still would like to see you wrap the other git commands rather than introducing a new one. Looks like your log formatting is a bit janky -- you have a bracket-interpolation param with no matching data being passed in. Go ahead and take that out and just throw a log.exception(e) after your warning line.

[nirizr]

Apologies, I thought you agreed with the git status thing, removed.
Sorry again for missing the formatting.

I used the exc_info optional argument instead of adding a log.exception so the exception info will be included in the warning. lmk if you want an log.exception instead or in addition to the log.warning.

[TheKevJames]

This LGTM, thanks for the fix! I will cut a new release as soon as I can.

[nirizr]

Splendid! thanks for the quick responses!