Closed dhomeier closed 2 years ago
Merging #82 (63d20d9) into main (1e86d98) will decrease coverage by
2.20%
. The diff coverage is100.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.
@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.
Yes, just thought so as well – and the Windows jobs seemed to be stuck for 15 minutes after the actual tox runs again.
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...
@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.
You can always replace @v1 by @main when calling the workflows to get the very latest version
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.
So mac and win py310 have updated there Shapely as well.
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?
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.
I think we should just remove the fast-fail options from our config now - the default of 'false' is what we want I think
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.
Description
Transition using the reusable workflows from https://github.com/OpenAstronomy/github-actions-workflows