glue-viz / glue-wwt

WorldWideTelescope viewer in glue
BSD 3-Clause "New" or "Revised" License
2 stars 6 forks source link

Switch CI from Azure to GitHub actions #82

Closed dhomeier closed 2 years ago

dhomeier commented 2 years ago

Description

Transition using the reusable workflows from https://github.com/OpenAstronomy/github-actions-workflows

codecov[bot] commented 2 years ago

Codecov Report

Merging #82 (63d20d9) into main (1e86d98) will decrease coverage by 2.20%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #82      +/-   ##
==========================================
- Coverage   74.18%   71.97%   -2.21%     
==========================================
  Files          18       18              
  Lines         860      860              
==========================================
- Hits          638      619      -19     
- Misses        222      241      +19     
Impacted Files Coverage Δ
glue_wwt/viewer/tests/test_wwt_widget.py 97.47% <100.00%> (-2.53%) :arrow_down:
glue_wwt/viewer/tools.py 50.94% <0.00%> (-30.19%) :arrow_down:

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 1e86d98...63d20d9. Read the comment docs.

astrofrog commented 2 years ago

@dhomeier - I think we should skip the tour saving test until we figure out #84 - that way we can move forward with the migration anyway.

dhomeier commented 2 years ago

Yes, just thought so as well – and the Windows jobs seemed to be stuck for 15 minutes after the actual tox runs again.

dhomeier commented 2 years ago

Mysteriously the Windows runs are no longer hanging – or could it have been the switch to v1.0.2? I'd still feel safer if there was a shorter timeout...

dhomeier commented 2 years ago

@astrofrog I don't know if there is a syntax to pull the dev branch of the workflows for testing if the fail-fast setting works as I believe it would, but that can certainly wait for a v1.0.3 release as well.

The Shapely 1.8.0 installations on macOS and Windows py310 seem to have similar geos_c problems – in fact the other Pythons are already on 1.8.1post1, so maybe that is the bugfix.

astrofrog commented 2 years ago

You can always replace @v1 by @main when calling the workflows to get the very latest version

dhomeier commented 2 years ago

OK, that would be better than accidentally staying stuck at @v1.0.2 in any case. Hmm, so @v1 currently is @v1.0.2; so that was obviously not what unstuck the windows runs.

dhomeier commented 2 years ago

So mac and win py310 have updated there Shapely as well.

astrofrog commented 2 years ago

Ok thanks! You can now revert back to using the default fast-fail as v1.0.3 of the workflows is out.

Also I think we can drop Python 3.6 as glue-core requires 3.7 (https://github.com/glue-viz/glue/blob/main/setup.cfg#L26) which might help resolve the remaining CI issues. Can you update this in setup.cfg too?

dhomeier commented 2 years ago

Ok thanks! You can now revert back to using the default fast-fail as v1.0.3 of the workflows is out.

Already used in the last run (set in tests to true and in allowed_failures to false, though the py310 arguably could be moved back to the "required" tests now ;-). Well, with py36 gone that would not leave any allowed failures at the moment.

astrofrog commented 2 years ago

I think we should just remove the fast-fail options from our config now - the default of 'false' is what we want I think

dhomeier commented 2 years ago

The default was true – at least for all envs in the same job; therefore I wanted this for the allowed failures. false arguably would make debugging more tedious, but otoh avoid burning CI time if it's always the same env failing.

I think the middle path recommended for astropy coordinated packages was to define a smaller set of mandatory tests that first have to pass (actually not starting the full set before that, which seems not possible here, but at least anything failing early on on setup or so would cancel the remaining jobs soon). But for this repo perhaps not so useful, since there are no environments with minimal deps or dev/very extended tests.