integration working with a test-fork of osquery: https://github.com/theopolis/osquery-ci-test/runs/2136674997?check_suite_focus=true this approach wont work for pull requests because of GitHub properly limiting access to secrets from non-collaborators. We might be able to get up and running with this by having these workflow jobs run on the main branch and tags. And we can find a solution for pull requests in the future. To have this work for master is a matter of copying and pasting that PR into
and setting the proper secrets.
We might be able to get up and running with this by having these workflow jobs run on the main branch and tags.What I mean here is I consider building aarch64 on master to be the MVP for what we need to consider support official. If we implement testing on master then we at least know before we tag a release that aarch64 is working. We'll also have packages built and ready as artifacts for the release process.
And we can find a solution for pull requests in the future.Longer term the Envoy or CB approach is ideal so that we give PRs the confidence they are not breaking aarach64. I proposed the
as a quick stop-gap solution. But I'd like to give @seph more time to continue to investigate the Envoy approach.