-
Notifications
You must be signed in to change notification settings - Fork 769
[CI][UR][Offload] Add Offload build-only job #18700
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: sycl
Are you sure you want to change the base?
Conversation
Add a new job that verifies that the offload adapter can be built. It does not attempt to run any tests or detect any hardware.
Co-authored-by: Kenneth Benzie (Benie) <[email protected]>
build_type: [Release] | ||
compiler: [{c: gcc, cxx: g++}] | ||
|
||
runs-on: "ubuntu-24.04" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we want to use one of our build runners? i expect these ones are really slow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah we should do this, any reason you didn't already @RossBrunton ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No reason other than the fact that ur-source-checks
and ur-benchmarks
don't. What runner should I be using for this? It doesn't need any fancy GPUs or libraries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we should use a UR CI machine, @igchor any ideas?
|
||
- name: Build | ||
# This is so that device binaries can find the sycl runtime library | ||
run: cmake --build build -j $(nproc) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you add -GNinja
to the cmake you don't need -j
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm using Make to be consistent with the ur-build-hw jobs.
|
||
- name: Install liboffload | ||
run: | | ||
sudo curl -sSL https://apt.llvm.org/llvm-snapshot.gpg.key -o /etc/apt/trusted.gpg.d/apt.llvm.org.asc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we add the key into the build image itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or even the install liboffload apt packages in the build image? how often are those regenerated @sarnex, nightly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually only when someone changes it or there's a driver update, so if we only need a general upstream LLVM install we could do it there, but if we want a changing llvm version we should do it in the CI job.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay, we're looking to use the upstream nightly for the liboffload packages so probably not suitable to install them in the build images then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah sure. the key should be stable and id like to prevent a sudo
in the CI job if possible, so maybe we could do that in the images.
Add a new job that verifies that the offload adapter can be built.
It does not attempt to run any tests or detect any hardware.