Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
152 changes: 152 additions & 0 deletions .github/workflows/nightly.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,152 @@
name: nightly

on:
schedule:
# Run at 11:00 UTC every day (19:00 CST)
- cron: "0 11 * * *"

jobs:
build_and_upload:
strategy:
fail-fast: false
matrix:
include:
- 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

Comment on lines +14 to +34
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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 -40

Length 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 -10

Length 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 -50

Length of output: 1397


🏁 Script executed:

#!/bin/bash
# Check LLVM setup and version requirements
cat "cmake/llvm_setup.cmake" 2>/dev/null

Length of output: 8492


🏁 Script executed:

#!/bin/bash
# Check package.cmake for version info
cat "cmake/package.cmake" 2>/dev/null | head -50

Length 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/null

Length 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")).

runs-on: ${{ matrix.os }}

steps:
- name: Free disk space (Linux)
if: runner.os == 'Linux'
uses: jlumbroso/free-disk-space@main

- name: Increase swap file size (Linux)
if: runner.os == 'Linux'
run: |
echo "===== Initial Status ====="
sudo swapon --show
free -h
echo "===== Creating Swap File ====="
sudo swapoff -a
sudo fallocate -l 16G /mnt/swapfile
sudo chmod 600 /mnt/swapfile
sudo mkswap /mnt/swapfile
sudo swapon /mnt/swapfile
echo "===== Final Status ====="
sudo swapon --show
free -h
df -h
- name: Setup dependencies (Linux)
if: runner.os == 'Linux'
run: |
sudo apt update
sudo apt install -y gcc-14 g++-14 libstdc++-14-dev cmake ninja-build
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-14 100
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-14 100
sudo update-alternatives --set gcc /usr/bin/gcc-14
sudo update-alternatives --set g++ /usr/bin/g++-14
wget https://apt.llvm.org/llvm.sh
chmod +x llvm.sh
sudo ./llvm.sh 20 all
- name: Setup dependencies (MacOS)
if: runner.os == 'macOS'
env:
HOMEBREW_NO_AUTO_UPDATE: 1
run: |
brew install llvm@20 lld@20
- name: Checkout repository
uses: actions/checkout@v4

- name: Setup xmake
uses: xmake-io/github-action-setup-xmake@v1
with:
xmake-version: 3.0.4
actions-cache-folder: ".xmake-cache"
actions-cache-key: ${{ matrix.os }}
package-cache: true
package-cache-key: ${{ matrix.os }}-pkg-nightly-v1
build-cache: true
build-cache-key: ${{ matrix.os }}-build-nightly-v1

- name: Get build identifiers
id: vars
shell: bash
run: |
echo "sha_short=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT
echo "date=$(date +'%Y%m%d')" >> $GITHUB_OUTPUT
- name: Check for new commits
id: check_commits
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
shell: bash
run: |
# Get the SHA of the last successful run of this workflow on the main branch
last_successful_sha=$(gh run list --workflow="nightly.yml" --branch="main" --status="success" --limit=1 --json headSha -q ".[0].headSha")
current_sha="${{ github.sha }}"
echo "Last successful SHA on main: ${last_successful_sha:-"None"}"
echo "Current SHA: $current_sha"
if [[ "$last_successful_sha" == "$current_sha" ]]; then
echo "No new commits since last successful run. Skipping build."
echo "should_skip=true" >> $GITHUB_OUTPUT
else
echo "New commits found. Proceeding with build."
echo "should_skip=false" >> $GITHUB_OUTPUT
fi
- name: Configure and Package
if: steps.check_commits.outputs.should_skip == 'false'
shell: bash
run: |
if [[ "${{ runner.os }}" == "Windows" ]]; then
xmake config --yes --enable_test=n --dev=n --release=y --mode=releasedbg --toolchain=${{ matrix.toolchain }} -p windows
elif [[ "${{ runner.os }}" == "Linux" ]]; then
xmake config --yes --enable_test=n --dev=n --release=y --mode=releasedbg --toolchain=${{ matrix.toolchain }}
elif [[ "${{ runner.os }}" == "macOS" ]]; then
export PATH="/opt/homebrew/opt/llvm@20/bin:/opt/homebrew/opt/lld@20/bin:$PATH"
xmake config --yes --enable_test=n --dev=n --release=y --mode=releasedbg --toolchain=${{ matrix.toolchain }} --sdk=/opt/homebrew/opt/llvm@20
fi
xmake pack -v
- name: Upload Main Package Artifact
if: steps.check_commits.outputs.should_skip == 'false'
uses: actions/upload-artifact@v4
with:
name: ${{ matrix.asset_name }}-${{ steps.vars.outputs.date }}-${{ steps.vars.outputs.sha_short }}
path: build/xpack/clice/${{ matrix.artifact_name }}

- name: Upload Symbol Package Artifact
if: steps.check_commits.outputs.should_skip == 'false'
uses: actions/upload-artifact@v4
with:
name: ${{ matrix.symbol_asset_name }}-${{ steps.vars.outputs.date }}-${{ steps.vars.outputs.sha_short }}
path: build/xpack/clice/${{ matrix.symbol_artifact_name }}
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ Beyond performance, clice provides instantiation-aware template processing, supp

## 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:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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:

  1. The nightly.link service recognizes the workflow name "nightly" from .github/workflows/nightly.yml
  2. 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)

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/main to 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.


```jsonc
{
Expand Down