james-willis opened a new issue, #837:
URL: https://github.com/apache/sedona-db/issues/837
## Symptom
The `r / macos-latest (release)` job intermittently fails with:
```
error: error: unexpected argument 'build' found
Usage: rustup-init[EXE] [OPTIONS]
```
…coming from this command in `r/sedonadb/src/Makevars.in`:
```
cargo +nightly build --lib --profile release
--manifest-path=./rust/Cargo.toml --target-dir … --target
-Zbuild-std=panic_abort,std
```
When `cargo +nightly` is invoked and the nightly toolchain isn't installed,
the rustup proxy hands the args to `rustup-init`, which treats `build` as an
unrecognised arg and exits 1.
## Why it's a flake, not a regression
The same head SHA shows both `success` and `failure` for this job on
consecutive workflow runs (observed on `a97def9429` against the
`jw/nd-raster-type` PR branch, and is widespread on `main` runs). Adjacent runs
on `main` over the past week pass. No code change has plausibly toggled it.
## Underlying confusion
`r/sedonadb/src/Makevars.in` selects between two cargo invocations:
```make
if [ "$(TARGET)" != "wasm32-unknown-emscripten" ]; then
cargo build $(CARGO_BUILD_ARGS);
else
...
cargo +nightly build $(CARGO_BUILD_ARGS) --target $(TARGET)
-Zbuild-std=panic_abort,std;
fi
```
…and `r/sedonadb/configure` only sets `TARGET=wasm32-unknown-emscripten`
when `uname` returns `Emscripten`. On `macos-latest`, neither condition should
hold, so the regular `cargo build` branch ought to fire.
Yet the `--target ` value in the failed command is empty, indicating
`TARGET` is empty at Make-expansion time — which would route to the regular
branch — but the `cargo +nightly` invocation runs anyway. That's the part that
doesn't add up from reading the configure / Makevars source alone. Possible
candidates:
- An env-var named `TARGET` leaking in on the runner that survives configure
but expands as empty inside Make.
- Rust-cache restoration pulling in a Makevars rendered against a different
`TARGET`.
- A second recipe path I'm missing.
Either way, the actual error is an environmental flake: macos-latest doesn't
carry a nightly toolchain by default, and the R workflow's `Use stable Rust`
step only installs stable.
## Proposed mitigation
Two angles:
1. **Defensive (cheap): install nightly + `rust-src` on the macos R
workflow** so that even if the wasm/nightly branch fires for any reason, the
build doesn't crash on a missing toolchain. PR coming.
2. **Root cause (follow-up): gate the wasm branch on a stronger condition**
(e.g. a `SEDONADB_TARGET_WASM=1` env-var only set in wasm-targeting workflows)
so it cannot accidentally fire on macos / linux at all.
This issue tracks both. The PR is just (1).
## Recent occurrences
- `r / macos-latest (release)` failed on `a97def9429` (PR #749), then passed
on a rerun of the same SHA.
- Sister jobs `ubuntu-latest (release)` and `windows-latest (release)` were
green for the same SHAs.
## Component
`.github/workflows/r.yml`, `r/sedonadb/configure`,
`r/sedonadb/src/Makevars.in`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
