ci: add placeholder required status gate#4
Merged
Conversation
Satisfies the `required` status-check context in org ruleset `default-branch-baseline` (id 15191038, currently evaluate mode). Placeholder: this job always passes. Before the ruleset flips to active, harden it with `needs:` on real language-CI jobs or replace with a call to a reusable workflow from resq-software/.github once the matching lang-ci.yml exists.
Contributor
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 54 minutes and 55 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
WomB0ComB0
added a commit
to resq-software/.github
that referenced
this pull request
Apr 17, 2026
…l dispatch Adds the two deferred reusable workflows: - dotnet-ci.yml: restore, build, format check, test. Configurable dotnet-version (default 9.0.x), solution path, working-directory. - cpp-ci.yml: CMake configure + build + test matrix across ubuntu/macos/windows (configurable). Harden-runner on Linux only (step-security action is Linux-native). Extends required.yml to dispatch the two new languages, and adds proto handling (security-only, no language build dispatched). New inputs: dotnet-version, dotnet-solution, cpp-os-list, cpp-source-dir, cpp-cmake-flags. After this lands, these placeholder consumer PRs can be hardened to call real CI: - resq-software/dotnet-sdk#36 (dotnet) - resq-software/viz#4 (dotnet) - resq-software/vcpkg#6 (cpp) - resq-software/ardupilot#1 (cpp)
Replaces the always-pass placeholder with a ci.yml that calls the org-wide `required` aggregator with `lang: dotnet` and the correct solution path. Pinned to resq-software/.github@6410acb (the commit introducing dotnet-ci.yml). After PR#12 on resq-software/.github merges, re-pin to the merge commit SHA or a semver tag. The top-level `required` job emits the status-check context consumed by org ruleset `default-branch-baseline`.
Updates @sha from the feat-branch tip to the merge commit of resq-software/.github#12 (f4b51a620aa1bf89c0bce4f434b36f92ff7d517d). Functionally equivalent — same content — but pins to a ref that now exists on main rather than a closed PR branch.
3 tasks
This was referenced Apr 28, 2026
WomB0ComB0
added a commit
that referenced
this pull request
Apr 28, 2026
* feat(viz): ray-batch sensor API + march_batch entry PR #3 of the WebGPU raymarcher direction. Introduces the ray-batch API that PR #4+ will dispatch from many sources (LiDAR, mesh-link line-of- sight, drone collision probes) — all walking the same brick-map DDA the camera path uses. New file: - client/webgpu/rays.ts — Ray (48 B) / RayHit (32 B) packing helpers, mask flag constants (MASK_OBSTACLES + reserved DENSITY/SDF), and hit flag constants (HIT_HIT/HIT_OBSTACLE + reserved VOLUME/TERRAIN). Modified: - client/webgpu/shaders/march.wgsl - Replace `Hit` with `RayHit` (carries t now, plus flags + material). - Add `Ray` struct + mask/flag constants in sync with rays.ts. - Add @binding(5)/(6) for rays/hits arrays (camera bindings 0..4 untouched; auto-derived layouts pick up only what each entry uses). - Refactor dda() to populate and return RayHit; the camera entry adapts its hit check to (h.flags & HIT_HIT) != 0u. - Add @compute @workgroup_size(64,1,1) march_batch — one thread per Ray, honors per-ray max_t (hits past max_t collapse to misses). - client/spikeMain.ts — adds a single-ray probe at startup that fires straight down through the terrain center, reads the hit back, and console.logs t/material/flags/normal. Demonstrator that the wire format and the new compute entry work end-to-end. - client/vite-env.d.ts — shim GPUMapMode runtime constants (TS 6's lib.dom omits these, same pattern as GPUBufferUsage/GPUTextureUsage). Validation: npm run typecheck and npm run build both pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(viz): address review feedback on ray-batch PR march.wgsl: - MAJOR: bounds-check both rays AND hits buffers in march_batch. Previously only checked arrayLength(&rays), so a host-side mismatch where the hit buffer was shorter than the ray buffer would overrun. - MAJOR: respect r.mask. A ray with MASK_OBSTACLES unset (or mask=0) no longer reports HIT_OBSTACLE — it short-circuits to a zero RayHit before consulting the brick map. Future DENSITY/TERRAIN_SDF masks will branch here too. - PERF: thread max_t into dda() so it can early-exit during traversal rather than post-filtering at the end. Pre-loop guard covers the trivially-out-of-range case (t_enter > max_t — short-range LiDAR rays skip the loop entirely). Top-of-loop guard covers empty-cell strides that cross the bound mid-walk. Camera entry passes 1e30 as the sentinel "no bound" max_t. rays.ts: - writeRay/readHit throw RangeError on out-of-bounds index instead of silently writing past or returning all-zero misses. The previous `?? 0` fallback in readHit made packing/count bugs look like legitimate "no hit" results. - writeRay JSDoc clarifies that `direction` must be a unit vector for max_t and the hit `t` to be in world-space units. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5 tasks
WomB0ComB0
added a commit
that referenced
this pull request
Apr 28, 2026
) * feat(viz): WebGPU sensor primitive on production route (foundation) PR #4 of the WebGPU raymarcher direction. First PR that crosses from the hidden /spike.html route into the production /index.html route. Foundation only — no rendering changes, no mesh-link opacity wiring; that arrives in PR #5 once this stabilises. What ships: - A WebGPU device + brick-map world (terrain voxelized into a 1024 m cube via `terrainHeight`) + a ray-batch LoS query manager initialise asynchronously at app boot, alongside the existing Three.js scene. - A one-shot sanity probe at boot fires a single ray straight down through origin and console.logs the resulting hit. Confirms the whole stack works end-to-end on each load. What does NOT ship (yet): - No production rendering changes. Three.js still draws everything (drones, terrain, mesh links) exactly as before. - No effects.ts or drones.ts changes. Mesh-link lines render with the same opacity they always have. Bundle impact: +20 KB minified (~3% of the existing 800 KB chunk). New files: - client/webgpu/world.ts: voxelizes terrainHeight() into a cubic brick-map world (128³ at 8 m per voxel, default origin [-512, 0, -512]). - client/webgpu/los.ts: LosQueryManager wrapper around march_batch. Accepts world-space rays, transforms to grid-space, dispatches, reads back hits, converts t back to world units. Single-slot async for now; PR #5 will add the readback ring when per-frame queries actually run. - client/webgpu/sensors.ts: bootSensors() / getSensorContext() singleton façade. Idempotent; null-safe fallback when WebGPU is unavailable. Modified: - client/app.ts: imports bootSensors and fires it at module load (`void bootSensors();`) alongside the existing `void start();`. Non-blocking, swallows its own errors. Single line of behaviour; no other production-route logic changed. Validation: npm run typecheck and npm run build both pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(viz): address sensor-foundation review + bundle budget CI: - client-budget was failing because the static import pulled the WebGPU stack into the main bundle (822 KB > 800 KB cap). Switch app.ts to a dynamic import — Vite emits sensors as its own ~20 KB chunk that loads in parallel. Main bundle now ~803 KB, back under budget. No behaviour change; bootSensors() still fires at module load. los.ts (CodeRabbit critical + Gemini medium): - Replace the shared-promise wait-loop with a real promise-chain queue. The previous `while (this.inFlight) await this.inFlight` let multiple waiters race past the same settled promise into runBatch() concurrently and corrupt the shared rayBuf/hitBuf/ readBuf. Now each query() appends to a chain via .then(), and inFlight is updated to a .catch()-wrapped tail so a failed batch settles the chain (lets later callers proceed) without poisoning their results. inFlight is non-nullable now (Promise.resolve() at init). world.ts (CodeRabbit critical): - Validate voxelScale > 0 + finite, gridSize > 0 integer, origin components finite — before voxelizing. The yiMax computation divides by voxelScale and indexes an N³ array, so zero/NaN/Infinity inputs would have produced an infinite loop or out-of-bounds writes. createWorld is exported, so it needed explicit bounds checking. Validation: typecheck, vite build (main bundle 803 KB / cap 800 KiB), dotnet build -c Release all pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
WomB0ComB0
added a commit
that referenced
this pull request
Apr 28, 2026
* feat(viz): mesh-link line-of-sight against terrain PR #5 of the WebGPU raymarcher direction. **First user-visible feature** of the whole arc — mesh-link lines in the production viz now visibly fade when terrain occludes the drone-pair line-of-sight. How it works: 1. effects.ts:_updateMeshLinks builds one LosRay per drone-pair each frame: origin = A, direction = normalize(B - A), max_t = ‖B - A‖, mask = MASK_OBSTACLES. 2. Dispatches the batch to the WebGPU sensor primitive landed in PR #4 (skip-if-busy throttle: at most one query in flight at a time, so queries don't queue unboundedly when GPU+readback can't keep up with the render). 3. When the query resolves, caches per-pair opacity (occluded pairs fade to 25% of base). The next frame's line teardown/rebuild reads from this cache, so opacity persists across the per-frame churn. Bundle architecture fix: - effects.ts importing getSensorContext from sensors.ts statically defeated the dynamic-import chunk split (Vite's INEFFECTIVE_DYNAMIC_ IMPORT warning), pulling the WebGPU runtime into the main bundle and blowing the client-budget cap. - New registry.ts holds the singleton context — runtime-free aside from a let + getter/setter — so effects.ts can import the getter without dragging the WebGPU stack along. sensors.ts calls setSensorContext() once boot finishes; getSensorContext() in registry.ts is what effects.ts reads. New file: - client/webgpu/registry.ts (~25 LOC): tiny singleton registry. Type- only import of SensorContext; no runtime WebGPU dependencies. Modified: - client/effects.ts: imports getSensorContext from registry, LosRay type from los, MASK_OBSTACLES + HIT_OBSTACLE constants from rays. EffectsManager gains _linkOpacityCache + _losQueryInFlight fields. _updateMeshLinks reads cached opacity, builds rays, dispatches one throttled LoS query per call, populates cache on resolve. - client/webgpu/sensors.ts: removes _ctx local cache + getSensorContext export, calls setSensorContext(ctx) at end of bootSensors() instead. Bundle: main 805 KB (under 800 KiB cap), sensors chunk 19 KB. Validation: typecheck, vite build, dotnet Release all pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(viz): address mesh-link LoS review feedback effects.ts (Gemini medium x3): - Cache the occlusion BOOLEAN, not the computed opacity. The previous Map<string, number> went stale whenever baseOpacity changed (e.g. mesh.partitioned toggling between true/false would have continued rendering at the cached opacity until the next LoS query landed). Now the cache is Map<string, boolean> and opacity is computed at line-creation time from baseOpacity * occludedFactor — base changes take effect immediately. - Key the cache by canonical drone IDs (`<idA>--<idB>` lexicographi- cally sorted) instead of array indices. Indices are not stable across reorderings of the drones array — using IDs prevents the cache from applying the wrong drone-pair's occlusion if the array happens to be sorted differently next frame. DroneState.id is the same field other EffectsManager state (trails, detections) keys on. - Field renamed _linkOpacityCache → _meshLinkOccluded to reflect the new semantics. occludedFactor (0.25) lives at the call site. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a minimal
required.ymlworkflow that always emits a greenrequiredstatus-check context — the context matched by the org rulesetdefault-branch-baseline(id 15191038, currently evaluate mode).This is a placeholder. Before flipping the ruleset to active, either:
needs:on real CI jobs in this repo, orresq-software/.githubonce the matching language-ci.yml exists.Context: resq-software/.github#12 defines the full reusable CI suite. This repo'''s lang is deferred in that PR and will get a proper workflow in a follow-up.