ci: install bpftool from released package if available#2749
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ekoops The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Perf diff from master - unit testsHeap diff from master - unit testsHeap diff from master - scap fileBenchmarks diff from master |
b04e3ab to
bd42a4a
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #2749 +/- ##
=======================================
Coverage 74.56% 74.56%
=======================================
Files 292 292
Lines 29998 29998
Branches 4651 4651
=======================================
Hits 22367 22367
Misses 7631 7631
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
6ef2372 to
2ccf4ed
Compare
Install `bpftool` from released package if available. Currently, this is the case for `amd64` and `arm64`, while it is not for `s390x` and `ppc64le`. In these latter cases, install build it from sources and install it. Keep using `bpftool` provided by the package manager on `test-drivers-ppc64le` for the moment, until the self-hosted runner is replaced. Signed-off-by: Leonardo Di Giovanna <leonardodigiovanna1@gmail.com>
2ccf4ed to
3f41644
Compare
bpftool from released package if available
irozzo-1A
left a comment
There was a problem hiding this comment.
Just a nit, but it's no blocker for me
| arch: | ||
| description: "Machine architecture (e.g.: 'amd64')" | ||
| required: true # To make it difficult for a user to rely on the wrong default. |
There was a problem hiding this comment.
nit: you could rely on the runner architecture instead of passing it as input https://docs.github.com/en/actions/reference/workflows-and-actions/variables
There was a problem hiding this comment.
Consider the fact that github doesn't provide support for s390x and ppc64le (indeed we are using dedicated runners and/or externally provided ones). In those cases, we couldn't rely on runner architecture... I thought to use uname -m, but then I have to introduce a mapping logic (e.g.: x86_64 -> amd64)
What type of PR is this?
/kind design
Any specific area of the project related to this PR?
/area CI
Does this PR require a change in the driver versions?
What this PR does / why we need it:
This PR installs
bpftoolfrom released package if available. Currently, this is the case foramd64andarm64, while it is not fors390xandppc64le. In these latter cases, it builds it from sources and then installs it. Notice that we keep usingbpftoolprovided by the package manager ontest-drivers-ppc64lefor the moment, until the self-hosted runner is replaced.Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
/milestone 0.23.0
Does this PR introduce a user-facing change?: