|
| 1 | +# GPUBench Release Process |
| 2 | + |
| 3 | +This document describes how GPUBench builds and publishes releases for different targets. |
| 4 | + |
| 5 | +## Release Architecture |
| 6 | + |
| 7 | +GPUBench uses a hybrid release process: |
| 8 | +1. **Windows Binaries**: Built and published automatically in the cloud via GitHub Actions. |
| 9 | +2. **Linux Packages**: Built locally on the development machine and uploaded manually using the GitHub CLI (`gh`). |
| 10 | + |
| 11 | +--- |
| 12 | + |
| 13 | +## 1. Windows Releases (Automated) |
| 14 | + |
| 15 | +Windows binaries are handled by the GitHub Actions workflow in `.github/workflows/release.yml`. |
| 16 | + |
| 17 | +- **Trigger**: Pushing a tag matching `v*` (e.g. `v1.1.0.1`). |
| 18 | +- **Generated Assets**: |
| 19 | + - `GPUBench-*-win64.zip` (Portable ZIP) |
| 20 | + - `GPUBench-*-win64.exe` (NSIS Installer) |
| 21 | +- **Workflow**: |
| 22 | + 1. Commit changes and update the `BUILD_NUMBER` in `CMakeLists.txt`. |
| 23 | + 2. Tag the commit (e.g., `git tag v1.1.0.1`). |
| 24 | + 3. Push the tag to remote (`git push origin v1.1.0.1`). |
| 25 | + 4. The GitHub Actions runner will automatically build, package, and publish the Windows binaries to the release page. |
| 26 | + |
| 27 | +--- |
| 28 | + |
| 29 | +## 2. Linux Releases (Local Dev Machine) |
| 30 | + |
| 31 | +Linux binaries (DEB, RPM, Tarball) must be built locally on the development Linux machine (which has the Vulkan SDK, OpenCL development libraries, and `glslc` compiler installed). |
| 32 | + |
| 33 | +### Step 1: Build and Package Locally |
| 34 | +Run the compile and packaging steps inside the local `build/` directory. |
| 35 | + |
| 36 | +> [!IMPORTANT] |
| 37 | +> Fedora/RedHat systems may have exported shell function definitions (like `ml` or `module` from Lmod) in the environment that cause `rpmbuild` to fail with bad exit statuses. Always package using a clean environment wrapper (`env -i`). |
| 38 | +
|
| 39 | +```bash |
| 40 | +# Navigate to the build directory |
| 41 | +cd build |
| 42 | + |
| 43 | +# Configure and compile release targets |
| 44 | +cmake .. -DCMAKE_BUILD_TYPE=Release |
| 45 | +cmake --build . --parallel $(nproc) |
| 46 | + |
| 47 | +# Generate packages using a clean environment wrapper |
| 48 | +env -i HOME=$HOME PATH=$PATH USER=$USER cpack -G DEB |
| 49 | +env -i HOME=$HOME PATH=$PATH USER=$USER cpack -G RPM |
| 50 | +env -i HOME=$HOME PATH=$PATH USER=$USER cpack -G TGZ |
| 51 | +``` |
| 52 | + |
| 53 | +### Step 2: Upload to GitHub Release |
| 54 | +Upload the generated assets directly to the existing GitHub release page using the GitHub CLI: |
| 55 | + |
| 56 | +```bash |
| 57 | +# Upload assets to the corresponding tag |
| 58 | +gh release upload v1.1.0.1 \ |
| 59 | + build/GPUBench-1.1.0.1-Linux.deb \ |
| 60 | + build/GPUBench-1.1.0.1-Linux.rpm \ |
| 61 | + build/GPUBench-1.1.0.1-Linux.tar.gz \ |
| 62 | + --clobber |
| 63 | +``` |
0 commit comments