Channels
android_tests
apple-silicon
arm-architecture
auditing-warroom
aws
carving
code-review
community-feeds
core
darkbytes
doorman
ebpf
eclecticiq-polylogyx-extension
extensions
file-carving
fim
fleet
fleet-dev
fleetosquery
foundation
fuzzing
general
golang
goquery
infrastructure
jobs
kolide
linen-dev
linux
macos
officehours
osctrl
plugins
process-auditing
querycon
queryhub
random
selfgroup
sql
tls
uptycs
vendor-feeds
website
windows
zeek
zentral
zercurity
Title
t
theopolis
01/28/2021, 5:14 PMwould love some help https://github.com/osquery/osquery/pull/6919 (adding more tests)
z
zwass
01/28/2021, 5:19 PMgotcha
s
seph
01/28/2021, 5:37 PMIf the intent is to test with multiple versions of rpm database, I’d love to make it more clear how to add them.
But I’m also not sure I understand
queryRpmDbt
theopolis
01/28/2021, 6:39 PMCan you guys leave notes on the PR? The intent of the PR is to test that the RPM APIs work. For context some assumptions about the API change in the newer librpm versions and our current integration tests do not catch this since they only run on debian machines. Adding a RPM-based integration test machine is also a good idea but IMO a unit-style test that runs everywhere is the best.
And yeap, the code is written to support more tests easily. Right now we only support 1 type of RPM database. When I bump the librpm version we will have the ability to support a few more, and I will add more tests. 🙂
It will look like this:
• Add single test for the single type of RPM db
• Bump librpm and continue to support a single type of db
• Change a config option in how we build librpm to support sqlite and dbn types and add tests for these
s
seph
01/28/2021, 6:51 PMDo you think it makes sense to test the API (as you’re doing) vs querying a test distributed database?