I will have to check this later when I am at a computer

And @Stefano Bonicatti might also have a clue

This came up because there is a group I am working with that is deploying osquery and their deployment package is massive. Looks like they are using the tarball as the source.

there’s should also be minimal logic to upload the debug symbols separately in the codesign repo, but again that should be straightforward

But this is all deep in the cpack code. And I don’t know who other than the ToB folk really understand it

For osquery specifically though we have split things. We first install via CMake only into a folder, whose files are used to create the packages in a second step and with a different CMake/CPack project (osquery-packaging)

Now the last tidbit is that CPack can only create one package per target defined in CMake. I don’t think it’s worth making all the changes to duplicate the targets or components inside

osquery-packaging

, and instead we should simply add an option that decides if to strip or not when creating the TGZ. Which means that the CI will have to run cpack an additional time for a tgz without debug symbols

The logic that drives the packaging via CI is here: https://github.com/osquery/osquery/blob/e29abce93789f718aeb56fd5da3e94c6fee08073/.github/workflows/hosted_runners.yml#L433

As far as telling CPack to strip files, there’s the

CPACK_STRIP_FILES

variable to set, which is documented in the link I gave above

I gave a long explanation just to give more insight in how things work, it seems complicated but it’s not that much and CPack is documented and behaves much like CMake (it’s automatic and you can control it via flags; no ones remember them by heart the options, so the manual is there to help), and now that I’m writing this, I think you could even not touch the

osquery-packaging

project and just act on the CI, passing

CPACK_STRIP_FILES

via command line, after adding a second run for a TGZ package.

From there the work is just letting the CI know where this new tgz is and upload it where necessary; the logic would be all in the

osquery

CI workflow

From there we have to take over in the codesign repo, to copy the new tgz coming from the

osquery

CI workflow run and upload it to the github release

https://osquery.slack.com/archives/CBLGAN1HD/p1681463866643789?thread_ts=1660787519.172489&cid=CBLGAN1HD Forgot the aarch64 workflow too (the logic there is a copy basically) https://github.com/osquery/osquery/blob/master/.github/workflows/self_hosted_runners.yml#L351

Another thing you will encounter is that the name of the archive generated is parametric but the parameters are given via the CMakeLists.txt, so unless you change them it’s “hardcoded”. This means that a second run of the tgz packaging will overwrite the previous tgz. Here, depending on if we want to have this logic be usable outside of the CI, you can just rename the first archive in the workflow, after you generate it, and then call the second tgz generation with the stripping. Or if we want to have this logic easily available just by passing an option to the

osquery-packaging

CMake, then we have to move this

if

, from the CI workflow to the

osquery-packaging

CMake logic.