I'm trying to automate detection a lot of the "nitpick" code review comments and providing a route to automatically fixing the issues apriori.

What I have added to CI is equivalent to locally running:

isort --check-only --sort-reexports --multi-line VERTICAL_GRID_GROUPED --line-length 90 --force-alphabetical-sort-within-sections --project devito,examples .
ruff check --preview  --select E,W,F,B,UP,SIM,I,RUF022 --ignore F403,E226,E731,E275,F405,E722,E741,W605 --line-length=90 --output-format concise

Most command line arguments are included in the pyproject.toml and checking out this branch you can just run

isort --check-only .
ruff check --output-format concise

Fixing most linting issues is as simple as

isort .
ruff check --fix

if you trust the auto-formatter!

This PR also extends linting to Dockerfiles and Github actions too.

An excerpt from CONTRIBUTING.md:

Coding guidelines

Some coding rules are "enforced" (and automatically checked by our Continuous Integration systems), some are "strongly recommended", others are "optional" but welcome.

• We enforce PEP8, with a few exceptions, listed here
• We enforce a maximum line length of 90 characters.
• We enforce indentation via 4 spaces.
• We suggest to use flake8 to check the above points locally, before filing a Pull Request.
• We strongly recommend to document any new module, class, routine, ... with NumPy-like docstrings ("numpydoc").
• We strongly recommend imports to be at the top of a module, logically grouped and, within each group, to be alphabetically ordered. As an example, condider our init.py: the first group is imports from the standard library; then imports from third-party dependencies; finally, imports from devito modules.
• We strongly recommend to follow standard Python coding guidelines:
  • Use camel caps for class names, e.g. class FooBar.
  • Method names must start with a small letter; use underscores to separate words, e.g. def _my_meth_....
  • Private class attributes and methods must start with an underscore.
  • Variable names should be explicative (Devito prefers "long and clear" over "short but unclear").
  • Comment your code, and do not be afraid of being verbose. The first letter must be capitalized. Do not use punctuation (unless the comment consists of multiple sentences).
• We like that blank lines are used to logically split blocks of code implementing different (possibly sequential) tasks.