Closed tepickering closed 3 years ago
Great to see github actions as potentially part of the template. I used this PR to transition one of my repositories. Very useful, especially as travis was becoming more and more cranky with time. Will be doing making the same transition for a bunch of repositories. Would be a great if this was officially part of the cookiecutter method.
thanks for the review @pllim! now that astropy has taken the actions plunge, circling back to fix this up is high on my list. will get on it asap...
I would vote with not having stages which add complication
Thanks for your patience, @tepickering ! I will be happy to have another look after the next round of changes, so feel free to ping me. 😸
i renamed the main workflow file and significantly cleaned it up to more closely match what astropy and photutils are doing in terms of structure. namely, i did away with the multi-level matrix in favor of bespoke steps to explicitly choose what to do, where, and how.
did some more expunging of references to travis and updated the docs to reflect the changes. i see that the template itself is still using travis for its own CI. migrating that is probably best left to a different PR though...
the template itself is still using travis for its own CI
Yes, @Cadair said he would deal with that separately, I think.
The old travis setup split the tests into sections: "initial" and "comprehensive". I recently switched to GitHub CI and have found this to be possible by splitting the tests into jobs, setting fail-fast=False
within each job and setting up job dependencies.
As an example,
sections: "initial" and "comprehensive"
@astrofrog already stated his objection to re-introducing stages in Actions due to increased complexity.
increased complexity.
Is there any other means to prevent a code linter check from stopping the other tests? the codestyle is useful, but ...
Is there any other means to prevent a code linter check from stopping the other tests?
Without stages and with "fail fast" on (the default), you hope that it finishes first, or you make it into another job. But I think in some cases, you actually want a failing linter check to stop other jobs. 🤷
i think in the use case of starting from scratch with a fresh code base, having the linter check fail fast and stop everything else is useful. shimming an actions workflow into an existing codebase is a different use case where you either want to allow the check to fail somehow or adjust the check to only fail in the worst cases.
i built a dummy repo from this branch and you can see the results of the CI here:
https://github.com/tepickering/tep_test/actions/runs/369174337
a bit of light whingeing about ubuntu-latest
moving to ubuntu-20.04
soon, but clean otherwise.
Thanks, @tepickering and everyone who reviewed!
While not perfect, I've been finding Github Actions to be a lot easier and more convenient to use overall than Travis and Azure. Here is a basic configuration that does a matrix of python tests across OS (though only Ubuntu by default), python version, and tox environment. I used this branch to create a test repository for verifying that the Actions workflow does work. Results from a successful test run can be viewed at https://github.com/tepickering/pkgtest/actions/runs/43196684.
EDIT: Address part of actions/toolkit#499