[CI] Upload CI Artifacts to get Nightly Builds #285
Conversation
WalkthroughA nightly build system is introduced with a GitHub Actions workflow that compiles the project daily across Windows, Linux, and macOS, uploads build artifacts, and includes a README update directing users to the nightly builds resource. Changes
Sequence Diagram(s)sequenceDiagram
participant Schedule as Daily Schedule
participant Workflow as Nightly Workflow
participant Env as Environment Setup
participant Check as Commit Check
participant Build as Build & Package
participant Upload as Upload Artifacts
Schedule->>Workflow: Trigger (11:00 UTC)
Workflow->>Env: Prepare OS environment<br/>(dependencies, disk space)
Env-->>Workflow: Ready
Workflow->>Check: Compare SHA against<br/>last successful run
alt New commits detected
Check-->>Build: Proceed with build
Build->>Build: Configure with xmake
Build->>Build: Package binaries
Build->>Upload: Two artifacts<br/>(main + symbols)
Upload-->>Workflow: Complete
else No new commits
Check-->>Workflow: Skip build
end
Workflow-->>Schedule: Workflow complete
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Tip 📝 Customizable high-level summaries are now available in beta!You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
Example instruction:
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
README.md (1)
21-21: Minor: Clean up whitespace in nightly build link text.The text has an extra space before the opening parenthesis. Consider:
... releases page) or [nightly build](...)-Download the latest `clice` binary from the [releases page](https://github.com/clice-io/clice/releases) ( or [nightly build](https://nightly.link/clice-io/clice/workflows/xmake/main) ) and install the [vscode extension](https://marketplace.visualstudio.com/items?itemName=ykiko.clice-vscode). +Download the latest `clice` binary from the [releases page](https://github.com/clice-io/clice/releases) or [nightly build](https://nightly.link/clice-io/clice/workflows/xmake/main), then install the [vscode extension](https://marketplace.visualstudio.com/items?itemName=ykiko.clice-vscode).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/xmake.yml(3 hunks)README.md(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: linux (ubuntu-24.04, debug)
- GitHub Check: linux (ubuntu-24.04, release)
- GitHub Check: windows (windows-2025)
- GitHub Check: macos (macos-15, debug)
- GitHub Check: macos (macos-15, release)
🔇 Additional comments (4)
.github/workflows/xmake.yml (4)
59-64: Artifact upload strategy looks good for Windows.Uploads on all non-PR runs to enable nightly builds. Since Windows has no debug build variant, this effectively uploads release builds only, consistent with Linux and macOS.
118-123: Release-only uploads are appropriate for Linux.Filters to release builds only, avoiding debug artifacts in nightly builds. Artifact naming with commit SHA ensures traceability and uniqueness.
169-173: Release-only uploads are appropriate for macOS.Consistent with Linux job: uploads only release builds on non-PR runs. The nightly.link service will aggregate these artifacts across all platforms.
59-173: Verify artifact directory structure and binary discoverability.All three jobs upload
./buildas-is, which will be zipped with its full directory structure. Consider documenting expected directory layout for users extracting artifacts from nightly builds, or verify that the clice binary is in an obvious location (e.g.,./build/cliceor similar).
.github/workflows/xmake.yml
Outdated
| with: | ||
| name: clice-${{ matrix.os }}-${{ github.sha }} | ||
| path: ./build | ||
|
|
There was a problem hiding this comment.
I think we should modify release.yml rather than xmake.yml.
There was a problem hiding this comment.
In my understanding, a nightly build refers to building the latest version after each pull request or at regular intervals. If release.yaml is used, builds and uploads only occur during version updates.
There was a problem hiding this comment.
Moreover, if we use a nightly.yaml , it will reprocess builds that have already been done in either xmake.yaml or cmake.yaml.
|
Does this PR just upload the binary to the artifacts, without needing to create a new tag? Regarding the review question above, @16bit-ykiko wants the nightly build to be built with LTO. |
yeah, simply upload artifacts for each pull without tag. casue i think with a tag it should in release page not a nightly build. built with LTO is reasonable, i'll fix it |
|
We plan to update to LLVM 21.4 and change the release build type to 'Release with Debug Info' soon. This PR must be done after those changes. |
|
By the way, I think this build should run nightly. It should check for new commits since the last build, and if any exist, proceed to build and upload the artifacts for a nightly build. These nightly artifacts should use the same configuration as an official release, just considered less formal. |
|
llvm has been updated to 21.1.4 #292. But we fail to build releasedbg + lto version of llvm because of oom. See https://github.com/clice-io/llvm-binary/actions/runs/18961725591 for detail @star-hengxing. |
|
The packaging workflow is ready, so I believe we can proceed with nightly builds. |
AXiX-official
force-pushed
the
upload-ci-artifacts
branch
from
470944d to
d6299a1
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
README.md (1)
19-21: Clarify nightly build availability and freshness.While the README now links to nightly builds, it doesn't document:
- When nightly builds are available (e.g., "built daily at 11:00 UTC" per the workflow schedule)
- That nightly builds reflect the latest main branch commits but may be less stable than releases
- Which platforms/architectures are included (Windows, Linux, macOS)
Consider adding a brief note to manage user expectations, or keep it minimal if you prefer simplicity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/nightly.yml(1 hunks)README.md(1 hunks)
🔇 Additional comments (2)
.github/workflows/nightly.yml (2)
140-152: Verify artifact output paths.The upload steps assume artifacts are located at
build/xpack/clice/${{ matrix.artifact_name }}andbuild/xpack/clice/${{ matrix.symbol_artifact_name }}. Confirm that the xmake pack step (line 138) produces artifacts at these exact paths on all three OS platforms (Windows, Linux, macOS).
125-138: LTO is already enabled through the--release=yflag.The nightly.yml workflow correctly includes
--release=yin all xmake config commands (lines 130–136). In xmake.lua, this flag triggers the conditionif has_config("release"), which setsset_policy("build.optimization.lto", true)(line 30). LTO is not missing; it is configured as intended. The--mode=releasedbgflag controls the optimization mode separately from the--release=yconfig flag that enables LTO.Likely an incorrect or invalid review comment.
| - os: windows-2025 | ||
| artifact_name: clice.zip | ||
| asset_name: clice-x64-windows-msvc | ||
| symbol_artifact_name: clice-symbol.zip | ||
| symbol_asset_name: clice-x64-windows-msvc-symbol | ||
| toolchain: clang-cl | ||
|
|
||
| - os: ubuntu-24.04 | ||
| artifact_name: clice.tar.gz | ||
| asset_name: clice-x86_64-linux-gnu | ||
| symbol_artifact_name: clice-symbol.tar.gz | ||
| symbol_asset_name: clice-x86_64-linux-gnu-symbol | ||
| toolchain: clang-20 | ||
|
|
||
| - os: macos-15 | ||
| artifact_name: clice.tar.gz | ||
| asset_name: clice-arm64-macos-darwin | ||
| symbol_artifact_name: clice-symbol.tar.gz | ||
| symbol_asset_name: clice-arm64-macos-darwin-symbol | ||
| toolchain: clang | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
Verify toolchain versions align with project LLVM updates.
The workflow uses clang-20 on Linux and clang (unversioned) on macOS, but PR context mentions LLVM has been updated to 21.1.4 (PR #292) and 21.4 was planned. Confirm whether clang-20 is intentional for stability or whether the workflow should reference the updated LLVM versions.
🌐 Web query:
What is the latest stable LLVM version and what is clang-20 vs clang-21 versioning?
💡 Result:
Latest stable LLVM: LLVM 21.1.6 (released Nov 18, 2025). [1][2]
What "clang-20" vs "clang-21" means
- The clang major/minor labels track the LLVM release branch: "clang-20" = the Clang front-end from the LLVM 20.x release series; "clang-21" = Clang from the LLVM 21.x series. Each series has point releases (e.g., 21.1.6). Packages and distro repos commonly expose these as clang-20, clang-21, etc. [1][3][4]
If you need specific point-release numbers (e.g., clang 21.1.6 binaries) or distro package names for your OS, tell me your platform and I’ll fetch the exact package/version links.
Sources:
[1] llvm.org (project home / release announcement).
[2] LLVM Discourse announcement: "LLVM 21.1.6 Released" (Nov 18, 2025).
[3] Apt.llvm.org package listings (clang/llvm-20 and llvm-21 toolchains).
[4] Example release changelogs showing clang/clang-format tied to LLVM point releases.
🏁 Script executed:
#!/bin/bash
# Search for LLVM/clang version references in the codebase
rg -i "llvm|clang" --type-list | head -20
rg -ni "version.*llvm|llvm.*version|clang.*2[0-1]" -A2 -B2 --type-not=node_modules 2>/dev/null | head -40Length of output: 389
🏁 Script executed:
#!/bin/bash
# Check CMakeLists.txt and related build config files for LLVM requirements
fd -e "CMakeLists.txt" -e "cmake" -e "\.cmake$" --type f | xargs grep -l -i "llvm\|clang" 2>/dev/null | head -10Length of output: 42
🏁 Script executed:
#!/bin/bash
# Display the full nightly.yml workflow to understand broader context
cat ".github/workflows/nightly.yml" 2>/dev/null | head -50Length of output: 1397
🏁 Script executed:
#!/bin/bash
# Check LLVM setup and version requirements
cat "cmake/llvm_setup.cmake" 2>/dev/nullLength of output: 8492
🏁 Script executed:
#!/bin/bash
# Check package.cmake for version info
cat "cmake/package.cmake" 2>/dev/null | head -50Length of output: 1420
🏁 Script executed:
#!/bin/bash
# Search directly for LLVM version constraints across key files
rg -n "LLVM.*VERSION|find_package.*LLVM" --type cmake -A3 -B1 2>/dev/nullLength of output: 5398
Update nightly.yml workflow to use clang-21 instead of clang-20 on Linux.
The project's CMake build configuration explicitly requires LLVM 21.1.4 (setup_llvm("21.1.4") in cmake/package.cmake), but the nightly workflow on ubuntu-24.04 specifies toolchain: clang-20, which corresponds to LLVM 20.x. This version mismatch will cause the Linux nightly build to fail or produce artifacts against the wrong LLVM libraries. Change line 32 in .github/workflows/nightly.yml from toolchain: clang-20 to toolchain: clang-21.
🤖 Prompt for AI Agents
.github/workflows/nightly.yml around lines 14 to 34: the ubuntu-24.04 job is
using toolchain: clang-20 which mismatches the project's required LLVM 21.1.4;
update that line to toolchain: clang-21 so the Linux nightly uses LLVM 21 and
matches cmake/package.cmake (setup_llvm("21.1.4")).
| ## Getting started | ||
|
|
||
| Download the latest `clice` binary from the [releases page](https://github.com/clice-io/clice/releases) and install the [vscode extension](https://marketplace.visualstudio.com/items?itemName=ykiko.clice-vscode). Then, add the following configuration to your `.vscode/settings.json` file: | ||
| Download the latest `clice` binary from the [releases page](https://github.com/clice-io/clice/releases) ( or [nightly build](https://nightly.link/clice-io/clice/workflows/nightly/main) ) and install the [vscode extension](https://marketplace.visualstudio.com/items?itemName=ykiko.clice-vscode). Then, add the following configuration to your `.vscode/settings.json` file: |
There was a problem hiding this comment.
🧩 Analysis chain
Verify nightly.link URL points to the correct workflow.
The README links to https://nightly.link/clice-io/clice/workflows/nightly/main for nightly builds. Confirm that:
- The nightly.link service recognizes the workflow name "nightly" from
.github/workflows/nightly.yml - Users can download the uploaded artifacts through this link after the workflow runs
🌐 Web query:
How does nightly.link integrate with GitHub Actions workflows and how should the URL be formatted?
💡 Result:
nightly.link integrates by reading artifacts produced by GitHub Actions (those uploaded with actions/upload-artifact) and exposing stable, public download redirects to the latest artifact for a given repo/workflow/branch (or to a specific run/artifact). It can also be installed as a GitHub App so downloads use the app token (to avoid global API rate‑limit issues). [1][2]
URL format (common patterns)
-
Latest artifact for workflow on a branch:
https://nightly.link/{owner}/{repo}/workflows/{workflow-file-or-name}/{branch}/{artifact}.zip.
Example: https://nightly.link/crystal-lang/crystal/workflows/win/master/crystal.zip. [1][2] -
Specific run:
https://nightly.link/{owner}/{repo}/actions/runs/{run_id}/{artifact}.zip. [1] -
Direct artifact ID:
https://nightly.link/{owner}/{repo}/actions/artifacts/{artifact_id}.zip. [1]
Notes
- Append ?status=completed to include completed (not only successful) runs. [1]
- For repos you control, install the nightly.link GitHub App to avoid shared API rate limits. [1][2]
Sources: [1] nightly.link homepage/docs; [2] nightly.link GitHub repo.
---
🏁 Script executed:
```shell
#!/bin/bash
# Find nightly workflow file and extract artifact upload configuration
fd -t f "nightly.yml" .github/workflows/
Length of output: 29
---
🏁 Script executed:
```shell
#!/bin/bash
# Extract artifact upload configuration from nightly workflow
cat .github/workflows/nightly.yml
Length of output: 5532
Correct the nightly.link URL in README line 21—it's incomplete and non-functional.
The current URL https://nightly.link/clice-io/clice/workflows/nightly/main is missing both the artifact name and .zip extension. According to nightly.link documentation, the correct format is https://nightly.link/{owner}/{repo}/workflows/{workflow-file-or-name}/{branch}/{artifact}.zip.
Since the workflow generates dynamic artifact names with date and commit SHA (e.g., clice-x64-windows-msvc-20250119-abc1234), a static URL cannot reliably point to the latest build. Either:
- Direct users to
https://nightly.link/clice-io/clice/workflows/nightly/mainto browse available artifacts, or - Specify particular artifact(s) with a complete URL pattern
🤖 Prompt for AI Agents
In README.md around line 21 the nightly.link URL is incomplete; replace the
current link with either the nightly.link browse URL
(https://nightly.link/clice-io/clice/workflows/nightly/main) so users can view
available artifacts, or provide a full artifact ZIP URL pattern including the
artifact name and .zip (e.g.,
https://nightly.link/{owner}/{repo}/workflows/{workflow}/{branch}/{artifact}.zip)
and update the text to explain that artifact names are dynamic so users may need
to select the latest build.
done |
3 participants
Resolves #281
Summary by CodeRabbit
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.