Lemmons / pytest-raises

An implementation of pytest.raises as a pytest.mark fixture

MIT License

19 stars 8 forks source link

Check out all history on Github Actions #27

Closed AetherUnbound closed 4 years ago

AetherUnbound commented 4 years ago

Possible fix for #26 - the actions/checkout@v2 was optimized for efficiency but this is a pretty small repo so checking out the entire history is probably fine. I'm not sure if there's a best way to test this besides running another deploy... unfortunately. I'm also uncertain if this will also fetch all tags or if this only pulls the commits.

codecov[bot] commented 4 years ago

Codecov Report

Merging #27 into master will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #27   +/-   ##
=======================================
  Coverage   98.01%   98.01%           
=======================================
  Files           2        2           
  Lines         101      101           
=======================================
  Hits           99       99           
  Misses          2        2

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update ccbc9d5...bf38bdb. Read the comment docs.

svenevs commented 4 years ago

Ahhhh ok interesting, in hindsight that makes some of the things I found online make more sense.

I think though, long term, it would be better to revamp the distribution tooling instead. Lean-and-mean setup.py + setup.cfg. I'm not opposed to pyproject.toml, but I need to do a little extra research this weekend and see if the tooling has caught up yet. It used to be the case that unless a setup.py was present, you wouldn't be able to do git installs. I plan to either open a PR for review or raise an issue around updating the setup.py stuff this weekend. I think we can avoid the git stuff altogether.

Sound good to you?

AetherUnbound commented 4 years ago

I think though, long term, it would be better to revamp the distribution tooling instead. Lean-and-mean setup.py + setup.cfg. I'm not opposed to pyproject.toml, but I need to do a little extra research this weekend and see if the tooling has caught up yet. It used to be the case that unless a setup.py was present, you wouldn't be able to do git installs. I plan to either open a PR for review or raise an issue around updating the setup.py stuff this weekend. I think we can avoid the git stuff altogether.

Sound good to you?

I'm on board! 🙂