I've added a small set of pre-commit hooks, including the flake8 linter, to the project. Developers can use these hooks by running pre-commit install. They can bypass the hooks if necessary with git commit -n; see also githooks(5).
I also added a continuous integration (CI) workflow using GitHub Actions. This workflow gets invoked when pushing changes to a branch on GitHub, when filing a pull request, or manually running the workflow (requires write access to the repository on GitHub). Right now, the CI workflow only runs the linter via pre-commit, but I plan to add test, build, and deployment jobs that replicate the old Travis CI workflow. Note that developers can run GitHub Actions locally using act, albeit with some limitations.
Except in one case, I have not actually made any changes to SATOSA's code style. I've also avoided making changes to how SATOSA gets built and packaged. Unfortunately, that means the CI workflow currently fails due to a number of flake8 errors. I'd like to coordinate future changes to address this in a future PR with the core development team and with other contributors (essentially, everyone with an open pull request).
All Submissions:
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
[x] Have you added an explanation of what problem you are trying to solve with this PR?
[x] Have you added information on what your changes do and why you chose this as your solution?
[x] Have you written new tests for your changes?
[x] Does your submission pass tests?
[x] This project follows PEP8 style guide. Have you run your code against the 'flake8' linter?
I've added a small set of pre-commit hooks, including the flake8 linter, to the project. Developers can use these hooks by running
pre-commit install
. They can bypass the hooks if necessary withgit commit -n
; see also githooks(5).I also added a continuous integration (CI) workflow using GitHub Actions. This workflow gets invoked when pushing changes to a branch on GitHub, when filing a pull request, or manually running the workflow (requires write access to the repository on GitHub). Right now, the CI workflow only runs the linter via pre-commit, but I plan to add test, build, and deployment jobs that replicate the old Travis CI workflow. Note that developers can run GitHub Actions locally using act, albeit with some limitations.
Except in one case, I have not actually made any changes to SATOSA's code style. I've also avoided making changes to how SATOSA gets built and packaged. Unfortunately, that means the CI workflow currently fails due to a number of flake8 errors. I'd like to coordinate future changes to address this in a future PR with the core development team and with other contributors (essentially, everyone with an open pull request).
All Submissions: