You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: article/article.md
+21-21Lines changed: 21 additions & 21 deletions
Original file line number
Diff line number
Diff line change
@@ -28,12 +28,12 @@ Here are the linters and checks we are going to use:
28
28
29
29
**Disclaimer**: author assumes you are familiar with the above-mentioned linters, tools, and checks.
30
30
31
-
I would like to share how to configure them for the python project. I prepared a full [github actions python configuration demo repository](https://github.com/iamtodor/demo-github-actions-python-configuration).
31
+
I would like to share how to configure them for the python project. I prepared a full [github actions python configuration demo repository](https://github.com/iamtodor/demo-github-actions-python-linter-configuration).
32
32
33
33
We use `flakeheaven` as a `flake8` wrapper, which is very easy to configure in one single `pyproject.toml`. The whole `pyproject.toml` configuration file can be found in
34
-
a [demo repo](https://github.com/iamtodor/demo-github-actions-python-configuration/blob/main/pyproject.toml).
34
+
a [demo repo](https://github.com/iamtodor/demo-github-actions-python-linter-configuration/blob/main/pyproject.toml).
I would say the config file is self-explainable, so I will not stop here for long. Just a few notes about tiny tweaks.
39
39
@@ -61,7 +61,7 @@ utils.py
61
61
62
62
We are ok if not every module will be documented. We are also ok if not every function or method will be documented. We are not going to push documentation for documentation's sake. So we want to disable `C0114` and `C0116` checks from pylint.
We assume that the developer who writes the code and imports the libs is responsible for the writing reliable tests. So if the test does not pass it means that it's something with the import or code (logic) itself. Thus the import check is not something we would like to put as a linter job.
86
+
We assume that the developer who writes the code and imports the libs is responsible for writing reliable tests. So if the test does not pass it means that it's something with the import or code (logic) itself. Thus, the import check is not something we would like to put as a linter job.
87
87
88
88
Also, there is another possible solution to disable this check by including `# noqa: E0401` after the import statement.
More info about rules could be found on [flake8 rules page](https://www.flake8rules.com/).
138
138
@@ -142,53 +142,53 @@ More info about rules could be found on [flake8 rules page](https://www.flake8ru
142
142
143
143
We configure GitHub Workflow to be triggered on every PR against the main (master) branch.
144
144
145
-
The whole `py_linter.yml` config can be found in a [demo repo](https://github.com/iamtodor/demo-github-actions-python-configuration/blob/main/.github/workflows/py_linter.yml). I will walk you through it step by step.
145
+
The whole `py_linter.yml` config can be found in a [demo repo](https://github.com/iamtodor/demo-github-actions-python-linter-configuration/blob/main/.github/workflows/py_linter.yml). I will walk you through it step by step.
We are interested in running linter only when a PR has `.py` files. For instance, when we update `README.md` there is no sense in running a python linter.
152
152
153
-
153
+
154
154
155
155
### What files does it run against
156
156
157
157
We are interested in running a linter only against the modified files. Let's say, we take a look at the provided repo, if I update `dags/dummy.py` I don't want to waste time and resources running the linter against `main.py`. For this purpose we use [Paths Filter GitHub Action](https://github.com/dorny/paths-filter), which is very flexible.
If we have modified a `.py` file and any other files such as `.toml` in one PR, we don't want to run a linter against the non-python files, so we configure filtering only for `.py` files no matter the location: root, tests, src, etc.
162
162
163
-
The changed file can have the following statuses: `added`, `modified`, or `deleted`. There is no reason to run the linter against deleted files as your workflow would simply fail, because that particular changed file is no longer in the repo. So we need to configure what changes we consider to trigger the linter.
163
+
The changed file can have the following statuses: `added`, `modified`, or `deleted`. There is no reason to run the linter against deleted files as your workflow would simply fail, because that particular changed file is no longer in the repo. So we need to configure what changes we consider triggering the linter.
I define the variable where I can find the output (only the `.py` files) from the previous filter. This variable would contain modified `.py` files that I can further pass to a `flakeheaven`, `black`, and `isort`. By default, the output is disabled and "Paths Changes Filter" allows you to customize it: you can list the files in `.csv`, `.json`, or in a `shell` mode. Linters accept files separated simply by space, so our choice here is `shell` mode.
Before we run the linter on changed files we run a check to see if there are actual changes in `.py` files by checking if there are any `.py` files from the previous step.
178
178
179
-
179
+
180
180
181
181
Next, using the before-mentioned output variable we can safety pass the content from this `steps.filter.outputs.py_scripts_filter_files` variable to linter.
0 commit comments