wickra

490 Commits 1 Branch 71 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
kingchencandGitHub	929fc17127	ci: harden cache, timeouts and retries across CI and release (#328 ) Hardens both workflows after the R-on-ubuntu job repeatedly hit the 20-minute job cap and was cancelled (no R-package cache + no retry + a slow source build). Each item below maps to the requested checklist. ### CI (`ci.yml`) - Timeouts 20 → 30 min on every job (backstop only; real jobs finish well under). - R dependencies cached: replace the manual `install.packages(testthat/knitr)` with `r-lib/actions/setup-r-dependencies` — restores a cached R library and pulls RSPM binaries instead of compiling from source (the slow/flaky path that blew the cap). This is the actual root-cause fix. - NuGet cache for the C# job (`~/.nuget/packages`, keyed on the project files). - Retry the network installs that had none — `npm ci`, `dotnet test`, `mvn install` — via `nick-fields/retry` (2–3 attempts, backoff). On top of the existing env-level retries (`CARGO_NET_RETRY`, `npm_config_fetch_retries`, `PIP_RETRIES`) and the setup-* CDN-flake retries. - Go stays `cache: false` on purpose: the module has no `go.sum` / external deps, so there is nothing to cache (enabling it would only warn). ### Release (`release.yml`) - Per-job timeouts added (there were none — only GitHub's 6h default): 45 min, higher than CI's 30 because the wheel/build jobs compile from source incl. vendored OpenSSL and must not be killed mid-build. - wasm-publish gets a `Swatinem/rust-cache` like the other Rust-build jobs. - Retry the no-retry network installs (`npm ci` ×2, `dotnet pack`). The actual publish/deploy steps are left alone — they are already idempotent (skip-existing / skip-duplicate), so re-running the job is the safe recovery. ### R binding download (`bindings/r/configure[.win]`) - A freshly cut release can 404 for 1–2 min while assets propagate, which broke the C ABI download (`cannot open URL … 404`). Add a `wickra_download` retry helper (6 × 20s ≈ 2 min backoff) for both the release-asset and wasm-source downloads. Note: the CI R job builds the C ABI locally (`WICKRA_*_DIR`), so it never downloads — this fix covers the real-world r-universe / end-user build. This PR's own CI exercises the CI changes (the reworked R job, caches, retries, timeouts) before merge; the release-only changes are validated on the next tag.	2026-06-17 23:42:06 +02:00
kingchencandGitHub	6433c9b3de	bindings/r: build the C ABI from source for the WebAssembly target (#244 ) ## Problem r-universe builds every package to WebAssembly (webR) in addition to the native platforms, calling `./configure --host=wasm32-unknown-emscripten`. `bindings/r/configure` only knew Linux/macOS/Windows and exited with `unsupported OS 'Emscripten'`, so the WASM job was the single red check on an otherwise fully-published r-universe build (all native platforms + deploy are green; the package installs fine everywhere). ## Fix The r-universe wasm build image ships cargo (`/usr/local/cargo/bin`) and emscripten (`EMSDK` on PATH). So instead of needing a prebuilt wasm lib (which would risk an emscripten ABI/version mismatch), `configure` now detects the Emscripten host and builds the C ABI staticlib from source for `wasm32-unknown-emscripten` in-place — compiled with the image's own emscripten, so the ABI always matches. The static `libwickra.a` is linked into the package object (no shared lib, no rpath). `wickra-core`'s rayon batch needs threads (absent on wasm), so the wasm build drops it via `--no-default-features`. `wickra-c` now takes `wickra-core` as a direct path dep with `default-features = false` plus a default `parallel` feature that re-enables it for native builds (a member-level `default-features = false` is ignored when inheriting a workspace dep — that was the trap). ## Validated locally - `cargo build -p wickra-c` (default) → rayon present, builds. - `cargo build -p wickra-c --no-default-features` (the wasm feature path) → rayon gone, builds. - `cargo build --workspace`, clippy, fmt all clean; `configure` passes `sh -n`. ## Cannot be validated locally No Rust/emscripten wasm toolchain here. The wasm build only runs in r-universe, and `configure` downloads the matching `v${version}` source tag — so this takes effect from the first release that includes it (the tagged source must contain the feature toggle). Open risks: whether the image has the `wasm32-unknown-emscripten` Rust target pre-installed (configure runs `rustup target add` best-effort) and the wasm build time. Worth one r-universe rebuild to confirm. Not merging — review first.	2026-06-10 01:44:48 +02:00
kingchencandGitHub	5b7523265c	Make the R binding self-contained (fetch the C ABI at install time) (#235 ) ## Problem The R package built only inside the dev/CI workspace. `src/Makevars` and `configure.win` hard-required `WICKRA_INCLUDE_DIR` / `WICKRA_LIB_DIR` pointing at a pre-built `libwickra` (`configure.win` literally `: "${WICKRA_LIB_DIR:?...}"`), and there was no Unix `configure`. So r-universe and any plain `install.packages` / `install_github` failed — R had no working end-user install path. ## Fix Fetch the prebuilt `wickra-c-<triple>.tar.gz` release asset matching the package version at install time and bundle the library into the package (same outcome as the C# / Java bindings, which bundle per-platform native libs): - New POSIX `configure` (the Unix hook R lacked): detect OS/arch → triple, download + `untar` via base R (no curl/wget system dep), stage `wickra.h` + `libwickra.{so,dylib}` into `src/`, generate `src/Makevars` from `Makevars.in` with an rpath (`$ORIGIN` Linux, `@loader_path` + `install_name_tool` macOS) so the bundled lib resolves post-install. - `configure.win`: drop the hard `WICKRA_LIB_DIR` requirement; download the Windows triple when unset, then keep the existing `wickra_abi.dll` rename + `objdump`/`dlltool` import-lib dance (sourcing the dll/header from the asset). - `install.libs.R` also bundles `libwickra.dylib` (macOS); the `.so`/`.dll` globs already covered Linux/Windows. - `WICKRA_INCLUDE_DIR`/`WICKRA_LIB_DIR` stay as an optional dev override. - CI (3 OS) keeps building against the locally built C ABI (version-independent — avoids the chicken-egg of downloading the in-flight version) but no longer exports `LD_LIBRARY_PATH`/`DYLD_LIBRARY_PATH`, so it now verifies the bundled rpath — the real self-contained path users and r-universe get. `Makevars` is now generated from `Makevars.in`; `SystemRequirements` + ignore/attributes files updated. ## Validation - The Windows `objdump`/`dlltool` import-lib dance was smoke-tested locally against the real v0.7.9 asset (2412 `wickra_` exports → import lib built). - Linux/macOS rpath bundling can't be tested on this Windows host → the 3-OS `r` CI job is the gate (now without the loader-path mask). - Follow-up (separate, after release): set up `wickra-lib/wickra-lib.r-universe.dev` (`packages.json` → `bindings/r`). Closes the R half of the self-contained-distribution gap (`todo-10`).	2026-06-09 22:11:50 +02:00

Author

SHA1

Message

Date

kingchencandGitHub

929fc17127

ci: harden cache, timeouts and retries across CI and release (#328 )

Hardens both workflows after the R-on-ubuntu job repeatedly hit the 20-minute
job cap and was cancelled (no R-package cache + no retry + a slow source build).
Each item below maps to the requested checklist.

### CI (`ci.yml`)
- **Timeouts 20 → 30 min** on every job (backstop only; real jobs finish well under).
- **R dependencies cached**: replace the manual `install.packages(testthat/knitr)`
  with `r-lib/actions/setup-r-dependencies` — restores a cached R library and pulls
  **RSPM binaries** instead of compiling from source (the slow/flaky path that blew
  the cap). This is the actual root-cause fix.
- **NuGet cache** for the C# job (`~/.nuget/packages`, keyed on the project files).
- **Retry** the network installs that had none — `npm ci`, `dotnet test`,
  `mvn install` — via `nick-fields/retry` (2–3 attempts, backoff). On top of the
  existing env-level retries (`CARGO_NET_RETRY`, `npm_config_fetch_retries`,
  `PIP_RETRIES`) and the setup-* CDN-flake retries.
- **Go stays `cache: false`** on purpose: the module has no `go.sum` / external
  deps, so there is nothing to cache (enabling it would only warn).

### Release (`release.yml`)
- **Per-job timeouts** added (there were none — only GitHub's 6h default): **45 min**,
  higher than CI's 30 because the wheel/build jobs compile from source incl.
  **vendored OpenSSL** and must not be killed mid-build.
- **wasm-publish** gets a `Swatinem/rust-cache` like the other Rust-build jobs.
- **Retry** the no-retry network installs (`npm ci` ×2, `dotnet pack`). The actual
  publish/deploy steps are left alone — they are already idempotent
  (skip-existing / skip-duplicate), so re-running the job is the safe recovery.

### R binding download (`bindings/r/configure[.win]`)
- A freshly cut release can 404 for 1–2 min while assets propagate, which broke
  the C ABI download (`cannot open URL … 404`). Add a `wickra_download` retry
  helper (6 × 20s ≈ 2 min backoff) for both the release-asset and wasm-source
  downloads. Note: the CI R job builds the C ABI **locally** (`WICKRA_*_DIR`), so
  it never downloads — this fix covers the real-world r-universe / end-user build.

This PR's own CI exercises the CI changes (the reworked R job, caches, retries,
timeouts) before merge; the release-only changes are validated on the next tag.

2026-06-17 23:42:06 +02:00

kingchencandGitHub

6433c9b3de

bindings/r: build the C ABI from source for the WebAssembly target (#244 )

## Problem
r-universe builds every package to WebAssembly (webR) in addition to the native platforms, calling `./configure --host=wasm32-unknown-emscripten`. `bindings/r/configure` only knew Linux/macOS/Windows and exited with `unsupported OS 'Emscripten'`, so the **WASM job was the single red check** on an otherwise fully-published r-universe build (all native platforms + deploy are green; the package installs fine everywhere).

## Fix
The r-universe wasm build image ships **cargo** (`/usr/local/cargo/bin`) and **emscripten** (`EMSDK` on PATH). So instead of needing a prebuilt wasm lib (which would risk an emscripten ABI/version mismatch), `configure` now detects the Emscripten host and **builds the C ABI staticlib from source** for `wasm32-unknown-emscripten` in-place — compiled with the image's own emscripten, so the ABI always matches. The static `libwickra.a` is linked into the package object (no shared lib, no rpath).

`wickra-core`'s rayon batch needs threads (absent on wasm), so the wasm build drops it via `--no-default-features`. `wickra-c` now takes `wickra-core` as a direct path dep with `default-features = false` plus a default `parallel` feature that re-enables it for native builds (a member-level `default-features = false` is ignored when inheriting a workspace dep — that was the trap). 

## Validated locally
- `cargo build -p wickra-c` (default) → rayon present, builds.
- `cargo build -p wickra-c --no-default-features` (the wasm feature path) → rayon **gone**, builds.
- `cargo build --workspace`, clippy, fmt all clean; `configure` passes `sh -n`.

## Cannot be validated locally
No Rust/emscripten wasm toolchain here. The wasm build only runs in r-universe, and `configure` downloads the matching `v${version}` source tag — so this takes effect from the **first release that includes it** (the tagged source must contain the feature toggle). Open risks: whether the image has the `wasm32-unknown-emscripten` Rust target pre-installed (configure runs `rustup target add` best-effort) and the wasm build time. Worth one r-universe rebuild to confirm.

Not merging — review first.

2026-06-10 01:44:48 +02:00

kingchencandGitHub

5b7523265c

Make the R binding self-contained (fetch the C ABI at install time) (#235 )

## Problem
The R package built **only** inside the dev/CI workspace. `src/Makevars` and `configure.win` hard-required `WICKRA_INCLUDE_DIR` / `WICKRA_LIB_DIR` pointing at a pre-built `libwickra` (`configure.win` literally `: "${WICKRA_LIB_DIR:?...}"`), and there was no Unix `configure`. So **r-universe** and any plain `install.packages` / `install_github` failed — R had no working end-user install path.

## Fix
Fetch the prebuilt `wickra-c-<triple>.tar.gz` release asset matching the package version at install time and bundle the library into the package (same outcome as the C# / Java bindings, which bundle per-platform native libs):

- **New POSIX `configure`** (the Unix hook R lacked): detect OS/arch → triple, download + `untar` via **base R** (no curl/wget system dep), stage `wickra.h` + `libwickra.{so,dylib}` into `src/`, generate `src/Makevars` from `Makevars.in` with an rpath (`$ORIGIN` Linux, `@loader_path` + `install_name_tool` macOS) so the bundled lib resolves post-install.
- **`configure.win`**: drop the hard `WICKRA_LIB_DIR` requirement; download the Windows triple when unset, then keep the existing `wickra_abi.dll` rename + `objdump`/`dlltool` import-lib dance (sourcing the dll/header from the asset).
- **`install.libs.R`** also bundles `libwickra.dylib` (macOS); the `*.so`/`*.dll` globs already covered Linux/Windows.
- `WICKRA_INCLUDE_DIR`/`WICKRA_LIB_DIR` stay as an optional **dev override**.
- **CI (3 OS)** keeps building against the locally built C ABI (version-independent — avoids the chicken-egg of downloading the in-flight version) but **no longer exports `LD_LIBRARY_PATH`/`DYLD_LIBRARY_PATH`**, so it now verifies the bundled rpath — the real self-contained path users and r-universe get.

`Makevars` is now generated from `Makevars.in`; `SystemRequirements` + ignore/attributes files updated.

## Validation
- The Windows `objdump`/`dlltool` import-lib dance was smoke-tested locally against the real v0.7.9 asset (2412 `wickra_` exports → import lib built).
- Linux/macOS rpath bundling can't be tested on this Windows host → **the 3-OS `r` CI job is the gate** (now without the loader-path mask).
- Follow-up (separate, after release): set up `wickra-lib/wickra-lib.r-universe.dev` (`packages.json` → `bindings/r`).

Closes the R half of the self-contained-distribution gap (`todo-10`).

2026-06-09 22:11:50 +02:00