GeezerVison

coderabbitai Bot left a comment

coderabbitai Bot left a comment

…flag name

build_nativescript.sh archived Mac Catalyst twice to the same
xcarchive path; the second archive overwrote the first, so the first
(~70s per build) never reached the xcframework. Keep the later one,
which uses the generic destination that ships today.

The simulator and device archives passed BUILD_LIBRARIES_FOR_DISTRIBUTION,
which is not an Xcode build setting (the setting is
BUILD_LIBRARY_FOR_DISTRIBUTION; "Build Libraries for Distribution" is
only its UI label). xcodebuild accepts any NAME=VALUE silently, so the
flag was a no-op and the project-level YES applied instead. Output is
unchanged; the flag now actually does what it says.

A new push to a PR now cancels the run still in progress for that PR.
Each run holds three macOS runners for ~10 min apiece, and restacking a
PR chain queued full runs for every intermediate push; with the org's
macOS concurrency cap that pushed wall-clock times to 70-97 min.

The 14 npm update entries and the github-actions entry each opened
their own PRs, and every PR runs the full macOS build and both test
lanes (11 PRs on 2026-11-01). Merge the npm entries into a single
multi-directory entry and group updates so each ecosystem gets one PR
per month. Ignore rules and schedule are unchanged.

…hase

The metadata-generator target ran a plain `make`, so the ~25-file
CMake build used one core; on 3-core CI runners it took 88s and every
TestRunner compile waited for it.

- Boot the simulator right after checkout (scripts/boot-ci-simulator.sh)
  and target it by UDID, so the boot overlaps dependency setup and the
  build instead of running after them (~3 min before the first test).
- Run `xcodebuild test` instead of `build test`: the test action builds
  what it needs, and the separate build action cost a second build pass
  (~37s).
- Export the junit attachments with xcresulttool via
  scripts/export-test-attachments.sh and drop xcparse, which Homebrew
  compiled from source on every test job (~70s).
- Route the metadata generator's CMake compiles through ccache in the
  pull request workflow, cached per job and keyed on the generator
  sources and LLVM version. The release workflow does not enable it:
  shipped binaries must not be built from restored caches.

The release workflow's test job gets the same simulator, test-action
and xcresulttool changes so both test jobs stay identical.

Each push to main runs the full release chain (build, test, then
GitHub release, ios-spm tag, npm publish, SPM verification), so a burst
of merges queued one complete run per commit on the shared macOS
runners. Give the build and test jobs per-ref concurrency groups that
cancel an older run when a newer push to main arrives; only the newest
commit's "next" gets published, and it contains the skipped commits.

The publishing jobs get no concurrency: cancelling them could leave a
half-published release (assets and ios-spm tag without the npm
package). Tag pushes and workflow_dispatch releases have their own
groups (event name and ref are part of the key) and never cancel.

Booting right after checkout overlapped the LLVM cache restore and the
dependency installs, and the contention cost more than it saved: the
cache restore went from ~11s to ~3.5 min and the test jobs got 2-3 min
slower overall, though tests started ~2 min sooner after the build.
Start the boot just before xcodebuild so it overlaps only the build.

Also log when the boot starts and finishes, print that log, and print
ccache stats in the pull request jobs, so CI logs show both directly.

Booting the simulator ahead of xcodebuild was slower wherever it ran.
Started right after checkout, it slowed the LLVM cache restore from
~11s to ~3.5 min. Started right before xcodebuild, xcodebuild waited
~3.7 min on the booting destination before building, and the freshly
booted simulator's background work roughly doubled the build time on
the 3-core runners. Booting after the build, as xcodebuild does, keeps
that work off the critical path, so go back to the name destination.

Drop ccache from the test jobs: it never hit there on CI (0/60, though
it hits locally through the same script phase), and with the generator
now compiling alongside the TestRunner build a hit would save about as
much as installing ccache costs. The Build job keeps it: warm, both
generator builds take 14s instead of ~50s.

…oups

A concurrency group keeps one running and one pending job; a newer
arrival replaces the pending one even without cancel-in-progress. With
the group keyed on event and ref, a third overlapping manual release
from main would have cancelled the second while it waited, and that
release would never publish. Only pushes to main share a group now;
every other event's group includes its run id.

Enable COMPILATION_CACHE_ENABLE_CACHING for the pull request workflow
through tools/ci-compilation-cache.xcconfig, loaded with
XCODE_XCCONFIG_FILE so it reaches every xcodebuild in a job, including
the ones the build scripts run. Each job restores and saves its own CAS
(keyed per job and test variant, rolling by commit). The release
workflow stays on Xcode 16.4 without caches: shipped binaries must not
be built from restored caches.

Drop -fembed-bitcode from OTHER_CFLAGS (Debug and Release): with caching
on, clang rejects it ("-mllvm is not supported with -fembed-bitcode").
It had no effect on the output: ENABLE_BITCODE is NO and none of the
shipped NativeScript binaries carries a bitcode section.

…main

PR runs can only restore caches saved by their own PR or by main, so
every PR's first push started with an empty compilation cache. Move the
release workflow to Xcode 26.3 (pull requests already use it, so both
now build with the same toolchain) and, on main, have its iOS build and
its test job compile with caching on into an empty CAS and save it
under the keys the pull request jobs restore. The release workflow
never restores one: shipped binaries are still compiled from source,
and an archive of the device slice built this way is byte-identical to
one built without caching.

Give each pull request test variant its own key segment
(test-default / test-asan): the old "test-" restore prefix of the
default variant also matched the ASan variant's keys.

update_version.sh wrote the package version into NativeScript-Prefix.pch.
Every file includes the prefix header, so a version bump changed the
input of every compile. PR and "next" versions include the run id, so
no two CI runs could share compilation-cache results, and a cache
seeded from main could never hit in a PR.

Move the define into NativeScript/runtime/Version.h, included only by
NativeScript.mm and Runtime.mm, the two files that use it.

No source file carries a version any more. A "Generate Version header"
build phase on the NativeScript target (next to Generate RuntimeBuiltins,
before Sources) runs tools/generate-version-header.sh, which reads
package.json with plutil and writes NativeScript/runtime/generated/Version.h
(gitignored), rewriting it only when the version changes. A fresh clone
builds from Xcode with no setup step, and update_version.sh no longer edits
sources.

Only NativeScript.mm and Runtime.mm include the header, so a version change
recompiles two files instead of every file that includes the prefix header.

Its remaining job was setting package.json's version from
PACKAGE_VERSION when given an argument, and no caller passed one:
build_all_ios.sh, build_all_vision.sh and the update-version npm script
all ran it without arguments. NATIVESCRIPT_VERSION now comes from
package.json at build time, so the README's release steps drop the
"npm run update-version" step too.

DefineNativeScriptVersion passed NATIVESCRIPT_VERSION, already a string
literal, through STRINGIZE_VALUE_OF, so __runtimeVersion held the
version wrapped in quote characters ("\"9.1.0\""). Pass the define
directly, as the Android runtime does with NATIVE_SCRIPT_RUNTIME_VERSION,
and drop the now unused STRINGIZE macros. Add a test that the global is
the bare package version.