Conversation
24694f9 to
0280a6a
Compare
Contributor
Author
|
Note: this depends on libbpf/ci#181 |
theihor
added a commit
to theihor/libbpf-ci
that referenced
this pull request
Apr 30, 2025
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
theihor
added a commit
to theihor/libbpf-ci
that referenced
this pull request
Apr 30, 2025
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
theihor
added a commit
to theihor/libbpf-ci
that referenced
this pull request
Apr 30, 2025
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
theihor
added a commit
to theihor/libbpf-ci
that referenced
this pull request
Apr 30, 2025
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
theihor
added a commit
to theihor/libbpf-ci
that referenced
this pull request
Apr 30, 2025
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
theihor
added a commit
to theihor/libbpf-ci
that referenced
this pull request
Apr 30, 2025
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
theihor
added a commit
to libbpf/ci
that referenced
this pull request
Apr 30, 2025
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
The 'toolchain' matrix parameter has been used in a confusing way. The
'version' field was only applicable to LLVM, but there is also a
separate 'llvm-version' action parameter spread across the workflows.
Now that we want to be able to specify a particular GCC version for
kernel build, a refactoring is appropriate.
Given that libbpf/ci/setup-build-env action sets up a particular
compiler version systemwide, and mixing LLVM versions between kernel
and selftests build is an unlikely scenario, it makes sense to simply
have gcc_version and llvm_version parameter, fixed within a particular
workflow. And so the composite 'toolchain' becomes unnecessary: it's
enough to distinguish between gcc and llvm build of the kernel.
However 'toolchain' and 'toolchain_full' are still useful variables
between the workflows and actions, particularly for identifying build
artifacts.
Here is what happens now:
* DEFAULT_{GCC,LLVM}_VERSION is set in matrix.py
* 'toolchain' is replaced with 'kernel_compiler' in the job matrix
* test.yml workflow looks at kernel_compiler to construct and pass
'toolchain' and 'toolchain_full' to other workflows
* '{gcc,llvm}_version' inputs are used to determine compiler
versions for the build setup
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The 'toolchain' matrix parameter has been used in a confusing way. The
'version' field was only applicable to LLVM, but there is also a
separate 'llvm-version' action parameter spread across the workflows.
Now that we want to be able to specify a particular GCC version for
kernel build, a refactoring is appropriate.
Given that libbpf/ci/setup-build-env action sets up a particular
compiler version systemwide, and mixing LLVM versions between kernel
and selftests build is an unlikely scenario, it makes sense to simply
have gcc_version and llvm_version parameter, fixed within a particular
workflow. And so the composite 'toolchain' becomes unnecessary: it's
enough to distinguish between gcc and llvm build of the kernel.
However 'toolchain' and 'toolchain_full' are still useful variables
between the workflows and actions, particularly for identifying build
artifacts.
Here is what happens now:
'toolchain' and 'toolchain_full' to other workflows
versions for the build setup