Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added automatic release to pypi on tag. #66

Merged
merged 19 commits into from
Nov 18, 2021

Conversation

cmccully
Copy link
Contributor

No description provided.

@cmccully cmccully requested a review from saimn October 27, 2021 19:55
@saimn
Copy link
Contributor

saimn commented Oct 29, 2021

@cmccully : could you rebase now that #59 is merged ? (This PR fixes a few useful things for the packaging)

pyproject.toml Outdated Show resolved Hide resolved
@cmccully
Copy link
Contributor Author

@saimn any ideas why it is not running the python tests?

@saimn
Copy link
Contributor

saimn commented Oct 29, 2021

@cmccully - It must configured on cibuildwheel: https://cibuildwheel.readthedocs.io/en/stable/options/#test-command
An example here: https://github.com/musevlt/mpdaf-wheels/blob/master/.github/workflows/build.yml#L17-L18
Since you already used pyproject.toml to configure cibuildwheel the config should go there.

@cmccully
Copy link
Contributor Author

cmccully commented Oct 29, 2021 via email

@codecov
Copy link

codecov bot commented Nov 1, 2021

Codecov Report

Merging #66 (a403cc9) into master (09a1c21) will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master      #66   +/-   ##
=======================================
  Coverage   93.09%   93.09%           
=======================================
  Files           7        7           
  Lines         782      782           
  Branches       12       12           
=======================================
  Hits          728      728           
  Misses         54       54           

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 09a1c21...a403cc9. Read the comment docs.

@cmccully
Copy link
Contributor Author

cmccully commented Nov 1, 2021

@saimn Looks the unit tests workflow was disabled. I re-enabled it. I removed the cron scheduled tests because that appears to be why we got disabled. I'm not sure right now it the cron tests add enough value to keep them going. Otherwise the PR should be ready to go.

.github/workflows/release.yml Show resolved Hide resolved
.github/workflows/release.yml Show resolved Hide resolved
@saimn
Copy link
Contributor

saimn commented Nov 2, 2021

Looks the unit tests workflow was disabled. I re-enabled it. I removed the cron scheduled tests because that appears to be why we got disabled.

Indeed, Github does that when there is no activity on the repo since some time, but I think once you reenable it it will not be disabled again.

However the normal unit test workflow is not run with the wheels, which I think would be good to have. That's the point of cibuildwheel's CIBW_TEST_REQUIRES and CIBW_TEST_COMMAND, once the wheels are build it will install it in a virtualenv and run the tests.

pyproject.toml Outdated Show resolved Hide resolved
@cmccully
Copy link
Contributor Author

cmccully commented Nov 3, 2021

Indeed, Github does that when there is no activity on the repo since some time, but I think once you reenable it it will not be disabled again.

I feel like for this particular repo the cron tests are a little bit of overkill. We rely on very little outside packages. The packages we do test against (numpy) for example are tested at merge for specific versions. Given that the set of versions we run against is static (i.e. I don't think we would automatically start testing against numpy 1.25 if it was released tomorrow) I'm not sure what periodic runs of the tests buys us.

@saimn saimn mentioned this pull request Nov 11, 2021
pyproject.toml Outdated

[tool.cibuildwheel]
# Skip pypy on mac due to numpy/accelerate issues
skip = "pp37-macosx_x86_64"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could skip pypy for all platforms. I'm not sure how binary wheels are supported on pypy, and astropy doesn't build pypy wheels.

pyproject.toml Outdated Show resolved Hide resolved
@saimn
Copy link
Contributor

saimn commented Nov 16, 2021

@cmccully - Tests are now running after each wheel creation though some of them are failing, sometimes because some wheels are missing for dependencies (scipy/astropy for py3.10), and also it seems is a real error on linux 32bits with test_median_clean:
https://github.com/astropy/astroscrappy/runs/4217562413?check_suite_focus=true#step:4:1500
I guess we could forget about 32bits, at least for now, since the usage is probably very low and and other project are considering removing 32bits support.

@cmccully
Copy link
Contributor Author

I think I agree with that @saimn. Should we flag that as a known issue? (Though I'm a little surprised there is an issue here).

@saimn
Copy link
Contributor

saimn commented Nov 18, 2021

I also skipped musllinux (raspberry I think) which is built by default by cibuildwhel since recently, so the jobs are now green and we have wheels for the most common platforms (except sadly cp10 on linux, where for some reason scipy won't install, but it's not specific to astroscrappy and we can fix that later hopefully).

astroscrappy-0.1.dev1+gf5963fd-cp310-cp310-macosx_10_9_x86_64.whl
astroscrappy-0.1.dev1+gf5963fd-cp37-cp37m-macosx_10_9_x86_64.whl
astroscrappy-0.1.dev1+gf5963fd-cp37-cp37m-manylinux_2_12_x86_64.manylinux2010_x86_64.whl
astroscrappy-0.1.dev1+gf5963fd-cp37-cp37m-win32.whl
astroscrappy-0.1.dev1+gf5963fd-cp37-cp37m-win_amd64.whl
astroscrappy-0.1.dev1+gf5963fd-cp38-cp38-macosx_10_9_x86_64.whl
astroscrappy-0.1.dev1+gf5963fd-cp38-cp38-manylinux_2_12_x86_64.manylinux2010_x86_64.whl
astroscrappy-0.1.dev1+gf5963fd-cp38-cp38-win32.whl
astroscrappy-0.1.dev1+gf5963fd-cp38-cp38-win_amd64.whl
astroscrappy-0.1.dev1+gf5963fd-cp39-cp39-macosx_10_9_x86_64.whl
astroscrappy-0.1.dev1+gf5963fd-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl
astroscrappy-0.1.dev1+gf5963fd-cp39-cp39-win32.whl
astroscrappy-0.1.dev1+gf5963fd-cp39-cp39-win_amd64.whl
astroscrappy-0.1.dev1+gf5963fd.tar.gz

@saimn
Copy link
Contributor

saimn commented Nov 18, 2021

Should we flag that as a known issue? (Though I'm a little surprised there is an issue here).

It was happening on several i686 builds, so it seems real but 🤷‍♂️

      def test_median_clean():
          # Because our image only contains single cosmics, turn off
          # neighbor detection. Also, our cosmic rays are high enough
          # contrast that we can turn our detection threshold up.
          _mask, clean = detect_cosmics(imdata, readnoise=10., gain=1.0,
                                        sigclip=6, sigfrac=1.0, cleantype='median')
      
          assert (clean[crmask] != imdata[crmask]).sum() == crmask.sum()
      
          # Run it again on the clean data. We shouldn't find any new cosmic rays
          _mask2, _clean2 = detect_cosmics(clean, readnoise=10., gain=1.0,
                                           sigclip=6, sigfrac=1.0, cleantype='median')
  >       assert _mask2.sum() == 0
  E       assert 2072 == 0

@cmccully
Copy link
Contributor Author

It does seem real, but I have no idea where there would be a difference between 32 and 64 bits in the code.

So are we ready to merge this? @saimn

@saimn
Copy link
Contributor

saimn commented Nov 18, 2021

Yes, I think we are ! 🎉

@cmccully cmccully merged commit 3e909d9 into astropy:master Nov 18, 2021
@cmccully cmccully deleted the feature/auto_release branch November 29, 2021 16:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants