Add static check with "avocado-static-checks"#129
Add static check with "avocado-static-checks"#129clebergnu wants to merge 1 commit intoavocado-framework:mainfrom
Conversation
| if debug: | ||
| LOG.debug("Got password prompt, sending '%s'", | ||
| password) | ||
| LOG.debug("Got password prompt, sending '%s'", password) |
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information
| password_list[password_prompt_count]) | ||
| LOG.debug( | ||
| "Got password prompt, sending '%s'", | ||
| password_list[password_prompt_count], |
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information
| password_list[password_prompt_count]) | ||
| LOG.debug( | ||
| "Got password prompt, sending '%s'", | ||
| password_list[password_prompt_count], |
Check failure
Code scanning / CodeQL
Clear-text logging of sensitive information
| - name: Check out repository code | ||
| uses: actions/checkout@v4 | ||
| - name: run static checks | ||
| uses: avocado-framework/avocado-ci-tools@main |
There was a problem hiding this comment.
Yeah, I expected to see something like this coming when I saw that new repo... Anyway currently there are 2 checks only and both of them already exist as GH action targets. What is the benefit of bundling them and using the avocado-ci-tools target instead? I mean I'd rather have 2 independent psf/black@stable and isort/isort-action@v1 pipelines to one combined avocado-framework/avocado-ci-tools@main one.
There was a problem hiding this comment.
Hi @ldoktor, the reason for the avocado-ci-tools is to reduce the duplications in avocado workflows. Right now, it has static-checks and project. The project is for configuration of MR. Avocado bot which is automatization for avocado-project dashboard. And static-checks which is for running unified checks for all avocado related repos.
I understand that from your point the static-checks does the same work as psf/black@stable and isort/isort-action@v1, but the static-checks repo has one mayor advantage. We can use it as submodule for other repos and bring the same static-checks to CI and local environments for developers. I hope that this explanation will help you better understand why we use this.
There was a problem hiding this comment.
Hi @ldoktor, as @richtja explained, one of the goals is to allow for development time execution of those checks, that is, before it gets sent to a Git forge such as GitHub.
BTW, I'm keeping this as draft, because to be a fair request for change, this needs to implement at least as much as it's currently implemented in inspect checkall, OR, at least (transitionally) changing inspekt checkall to a combination of static-checks/check* and inspekt $SPECIFIC_CHECK_COMMAND.
There was a problem hiding this comment.
Sure, I understand although I'm wondering if separate checks wouldn't be easier to post-process on failure. I mean looking into one single blob with multiple checks might be hard to process using human eyes and harder to reproduce unless the output is pretty damn simple. Something like:
::group::Running style check
...
::endgroup::
::group::Running import order check
...
::error::Import order failed, use `isort --profile black .` to reproduce locally
::endgroup::
...
::group::Report
Successful checks:
* Style check
Unsuccessful checks:
* Import order
::endgroup::
Adds a Python module import order check, and code style check. This is based on "avocado-static-checks", which is being added here as a submodule. On CI, it uses the "avocado-ci-tools" actions to check out and run it, but the same can be done locally with the submodule. Signed-off-by: Cleber Rosa <[email protected]>
3d7315e to
28eaf9a
Compare
|
@clebergnu do you intend to follow-up on this PR? |
Adds a Python module import order check, and code style check.
This is based on "avocado-static-checks", which is being added here as a submodule. On CI, it uses the "avocado-ci-tools" actions to check out and run it, but the same can be done locally with the submodule.