Osquery uses basic SQL commands to leverage a relational data-model to describe a device.

osquery

I can spin up a github issue but wanted to bring it up here. Would it make sense to put the actual osquery version in the Info.plist of the app bundle? Currently there isn’t one. This would make it very easy for tools to make sure the correct osquery version is installed without jumping through extra hoops or shelling out to osquery itself.

```&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "<http://www.apple.com/DTDs/PropertyList-1.0.dtd>"&gt;
&lt;plist version="1.0"&gt;
&lt;dict&gt;
    &lt;key&gt;CFBundleExecutable&lt;/key&gt;
    &lt;string&gt;osqueryd&lt;/string&gt;
    &lt;key&gt;CFBundleIdentifier&lt;/key&gt;
    &lt;string&gt;io.osquery.agent&lt;/string&gt;
    &lt;key&gt;CFBundleInfoDictionaryVersion&lt;/key&gt;
    &lt;string&gt;6.0&lt;/string&gt;
    &lt;key&gt;CFBundleName&lt;/key&gt;
    &lt;string&gt;osqueryd&lt;/string&gt;
    &lt;key&gt;CFBundlePackageType&lt;/key&gt;
    &lt;string&gt;APPL&lt;/string&gt;
&lt;/dict&gt;
&lt;/plist```


That's a great idea! osquery packaging is a little different since we use CMake + CPack across platforms, so it's not super straightforward, but I will try to chew on it

Though we also have `osquery_info` table, which has the version info (just fyi in case you missed that), but as you said, would require a query

cool, I was just looking through the repo to see how the pkg gets built and you are right it is a tad tricky haha

`CFBundleVersion` or `CFBundleShortVersionString` would work great in the `Info.plist`

tad is a bit of an understatement haha! But we have really overhauled it, and this works cross platform, and it's mostly automated now!

<https://github.com/osquery/osquery/issues/7312>

If I get on a soapbox….

1. We should also create distribution packages
2. Whicih will need metadata set
3. because the apple tooling strips the title out when it coverts package formats.

I just ran across this myself, would it make sense to add a directive to `build_x86.yml`, to stick the version in the Info.plist file there? I'd submit a PR if I can make sure I'm understanding this correctly, I'm not very familiar with GitHub Actions

GitHub actions are kinda like yaml annotated shell scripts. If you see an obvious looking command, you're probably looking in the right place. 

Sure, it's more enviroment/context type stuff I'm puzzling through, like this `ccache` bit

I'll give it a shot and see what happens :shrug:

If you point me at a line, I can tell you what it does. Or the github docs are okay.

But each “step” is like a shell script (or single command) and they’re run mostly in series.

We're renaming that one to `hosted_runners.yml` and making quite a few changes in this PR just FYI <https://github.com/osquery/osquery/pull/7330/files#diff-9f96c7398750f97ef9c6b9389a79c9282ceac7bfc98f27404473d88d03b9b00d>

The change I'm proposing is pretty minor, seems like it would slot in just as well somewhere in the proposed change to `hosted_runners.yml`