CI: Create a nightly release workflow#156
Conversation
3bac116 to
562f0e4
Compare
jordan-turbofish
left a comment
jordan-turbofish
left a comment
There was a problem hiding this comment.
Do we want to change the installation path for the packages before releasing them nightly? Right now, files from the packages will be orphaned if the ROCm version is upgraded.
I think that we should update the ROCm versions in the containers so we're building the package against the latest release.
@jordan-turbofish I did make a note regarding this concern that will be posted with the release. Regarding the fix, this should be a separate effort outside of this PR. Our CI does not currently have the ability to be variable on ROCm releases. I do plan to work on that next. I think the question then becomes, do we want this PR to wait for that to be completed first, or have the next PR enabling CI to switch between ROCm versions update the nightly release at the same time.
Sure, we can do that separately. |
Will run once a night or on demand to produce a nightly release. Platform jobs are kept separate and are not in a matrix to avoid clobbering the outputs of the callable workflow. Release steps to be added later.
`gh release create` will fail if the release already exists.
Originally I wanted to be able to refer to each package produced by the build workflow. This is not possible in a matrix job as the output would be clobbered by whatever leg of the matrix completed last. If we are fine with using glob patterns to reference the packages accordingly, then we do not need the access the outputs of the build workflows.
562f0e4 to
4776efc
Compare
Do we want to spend time on building packages for multiple ROCm versions, or is releasing a package for the latest version good enough? If we updated ROCm in the Docker images, this small change would have our package install to the versioned path: diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8be557e..0552b59 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -120,7 +120,8 @@ list(APPEND CMAKE_PREFIX_PATH
# Set hipFile Install Path to the ROCm directory
# Note: CMAKE_INSTALL_PREFIX is set to a default by project().
if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
- set(CMAKE_INSTALL_PREFIX "${ROCM_PATH}" CACHE PATH "The path where hipFile should be installed" FORCE)
+ file(REAL_PATH "${ROCM_PATH}" ROCM_ABSOLUTE_PATH)
+ set(CMAKE_INSTALL_PREFIX "${ROCM_ABSOLUTE_PATH}" CACHE PATH "The path where hipFile should be installed" FORCE)
endif()
# Fix library install directory to "lib" to be inline with the rest of ROCm |
For the time being, we will hardcode the absolute path of the version of ROCm that is installed in the container. In the future, we will want the CI to have better control to dictate where the install path is and what version of ROCm we should be building against.
I think right now the latest version is fine. |
…ldixon/ci-nightly-release
There was a problem hiding this comment.
Pull request overview
This PR adds a nightly release workflow for hipFile that runs daily at midnight UTC. The workflow builds packages for Rocky, SUSE, and Ubuntu platforms, then creates a GitHub release tagged "nightly" with the built artifacts.
Changes:
- Created automated nightly release workflow with multi-platform build matrix
- Added reusable workflow for building hipFile on AIS infrastructure
- Introduced ROCM_PATH configuration using hardcoded version 6.4.2
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| .github/workflows/nightly-release.yml | Main workflow that orchestrates nightly builds across platforms and publishes release |
| .github/workflows/nightly-build-ais.yml | Reusable workflow wrapper for AIS builds with platform input parameter |
| .github/workflows/build-ais.yml | Updated build workflow to support ROCm version configuration via environment variable |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Motivation
We would like to produce a nightly release of hipFile.
Technical Details
Uses GH CLI for creating the release and uploading the packages to GitHub. There used to be a 1st party action to do this but has since been deprecated a few years ago.
Uses a glob pattern to fetch and reference the built hipFile packages. Best effort is used to only match runtime and development libraries, but we will need to verify this as we produce additional packages. This glob pattern will need to be updated/tested if a new platform is added to the support matrix or if the package filename changes.
Test Plan
Does this pass the existing build workflow and are packages uploaded to the nightly release?
Test Result
Ran the CI on my personal fork while the new nightly workflow had an added trigger of running on a
pull_request.https://github.com/riley-dixon/hipFile-test/actions/runs/21042360478?pr=14
AIHIPFILE-97