-
-
Notifications
You must be signed in to change notification settings - Fork 751
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use bandit (via pantsbuild) #5777
Conversation
837fb1c
to
356fdb0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - although the vote seems to be going for .lock files...
af1aff0
to
53d4e46
Compare
53d4e46
to
d7832e6
Compare
We do not want to have pants or git complaining about changes in the git submodule as those changes would require a separate PR process.
# do not fmt across git submodule boundary | ||
skip_black=True, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was requested in #5774 (comment)
I missed adding it before merging, so I'm adding it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bandit is one of my favorite tools. Nice :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Background
This is another part of introducing
pants
, as discussed in the TSC Meetings on 12 July 2022, 02 Aug 2022, 06 Sept 2022, and 04 Oct 2022. Pants has fine-grained per-file caching of results for lint, fmt (like black), test, etc. It also has lockfiles that work well for monorepos that have multiple python packages. With these lockfiles CI should not break when any of our dependencies or our transitive dependencies release new versions, because CI will continue to use the locked version until we explicitly relock with updates.To keep PRs as manageable/reviewable as possible, introducing pants will take a series of PRs. I do not know yet how many PRs; I will break this up into logical steps with these goals:
pants
to the st2 repo, andpants
step-by-step.Other pants PRs include:
pants_ignore
and bump pants to v2.14.0rc1 #5733BUILD
files with./pants tailor ::
#5738Overview of this PR
This configures pants to use
bandit
when running thelint
goal.By default, pants uses
bandit>=1.7.0,<1.8
, but I told it to use the version we have it pinned to:bandit==1.7.0
:st2/test-requirements.txt
Line 10 in 83904f6
Pants uses a lockfile for each tool it uses to ensure we get consistent results. Since I changed
[bandit].version
inpants.toml
, pants errors, saying that the lockfile (in this case the<default>
lockfile distributed with pants) is out-of-date. Note how the message is very helpful in explaining exactly what has to happen to fix this:As described in #5774, I'm putting lockfiles under the
lockfiles/
directory. I'm also not using an extension on the file. Pants does not care about extensions, so we can adopt our own convention on naming the lockfiles. For now, I skipped the extension, but we could easily use.lock
or something similar.NOTE: it is not safe to manually change the lockfiles. If we need to change any dependencies (including transitive deps), we need to use pants to regenerate the applicable lockfiles. Therefore, 481 lines of this change are auto-generated - you can review them for sanity, but we should not change them manually.
Unlike
black
(#5774) andflake8
(#5776), we do not need to addskip_bandit=True
in any of the BUILD files.I used
[bandit].args
to reuse the bandit settings we already have in the Makefile:st2/Makefile
Line 556 in 94d0798
st2/pants.toml
Lines 88 to 93 in 837fb1c
I had to look up what each of the args meant, so I documented the
-lll
arg in a comment, and used--exclude
instead of the shorter-x
so that it's easier to tell what it's doing. Also, I added the--quiet
arg because bandit has a very verbose success message--this was recommended in the pants docs.Relevant Pants documentation
./pants generate-lockfiles
goal./pants lint
goalpython_sources
python_source
Things you can do with pantsbuild
I needed to generate the
lockfiles/bandit
lockfile, which I did with this (the "scheduler" info messages occur wheneverpantsd
is starting up in the background, so we can ignore those.):You can run
./pants lint ::
to see if bandit finds any issues (the GHA Lint workflow runs this as well). You can run only one of the linters with the helpful--only
arg like this:The
--only
flag is "scoped" to the lint goal. So, these are equivalent if you wanted to specify that flag in a different order:./pants lint --only=bandit ::
./pants --lint-only=bandit lint ::
./pants lint :: --lint-only=bandit
note: that I had to add
lint
in the arg name to use a different order