Switch CI from Azure to GitHub actions

[dhomeier]

Description

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

[codecov]

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%)	⬇️
glue_wwt/viewer/tools.py	50.94% <0.00%> (-30.19%)	⬇️

---

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]

@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]

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

[dhomeier]

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]

@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]

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

[dhomeier]

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]

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

[astrofrog]

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]

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]

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]

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.

[astrofrog]

Looks good! I agree about trying to follow something more like what we do in astropy with different stages of testing, though packages like this are low traffic enough that I'm not sure if it's worth the extra complexity. Fast failing is not a good option in any case as if you run the CI again you might not have the same job fail which makes debugging impossible.