Move packaging logic to osquery-packaging by alessandrogario · Pull Request #692...
source link: https://github.com/osquery/osquery/pull/6921
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Conversation
This migrates this build-from-source packaging logic into a separate repo.
- The wiki documentation is updated with the new instructions on how to package from source builds.
- The CI is updated to use the new repo for package testing.
force-pushed the alessandro/cmake/use-standalone-cpack-packaging
branch
from
ce0ce7a
to
b2d7f21
11 months ago
force-pushed the alessandro/cmake/use-standalone-cpack-packaging
branch
3 times, most recently
from
366da03
to
16ab164
11 months ago
We definitely need to document why this change is happening. And we need to update the docs with instructions on how to build packages.
force-pushed the alessandro/cmake/use-standalone-cpack-packaging
branch
from
16ab164
to
81a4537
11 months ago
At least on macOS, this does produce a package_data, which is awesome.
Some nits/suggestions, both of which are not blocking:
- This build should leave a VERSION file. The packaging consumer should not need the to find the version
- I want to quibble about the structure in
package_data-- on macOS, there are 3 directories.control,private, andusr. I'm pretty sure the first is a meta directory, and the latter two are in/. I feel like convention would be to createcontrolandroot.
Anyhow, quibbles.
To create a DEB, RPM, or TGZ on Linux, CPack will attempt to auto-detect the appropriate package type.
You may override this with the CMake `PACKAGING_SYSTEM` variable as seen in the example below.
export OSQUERY_VERSION=$(git describe --tags --always)
I suspect this is a a carryover, but I think this would be cleaner if cmake --build . --target install dropped a VERSION file for the packaging to consume later.
Regardless, I think we can improve after merge,
force-pushed the alessandro/cmake/use-standalone-cpack-packaging
branch
from
613281d
to
92a8873
9 months ago
This looks good but heads up it has not updated the build_aarch64 workflows. Those will start to fail after this is merged. Do you want to update them in the same PR or let them break and follow up with another PR.
A good way to test them is to develop in a feature branch on osquery/osquery.
This looks good but heads up it has not updated the
build_aarch64workflows. Those will start to fail after this is merged. Do you want to update them in the same PR or let them break and follow up with another PR.A good way to test them is to develop in a feature branch on
osquery/osquery.
I was wondering how to test this, as I would have preferred to not break the AArch64 workflow; I'll create a new branch and switch my PR to work against it
changed the base branch from master to feature/cmake/use-standalone-cpack-packaging
merged commit 10af94a
into
osquery:feature/cmake/use-standalone-cpack-packaging on Apr 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
No one assigned
None yet
No milestone
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK