chore(deps)(deps): Bump gradle-wrapper from 9.4.1 to 9.5.0 in /core - #4
Merged
Merged
Conversation
Bumps [gradle-wrapper](https://github.com/gradle/gradle) from 9.4.1 to 9.5.0. - [Release notes](https://github.com/gradle/gradle/releases) - [Commits](gradle/gradle@v9.4.1...v9.5.0) --- updated-dependencies: - dependency-name: gradle-wrapper dependency-version: 9.5.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
gkrost
added a commit
that referenced
this pull request
May 1, 2026
Pre-fix the scan-progress line read
Scanning local changes... 12450 items (47s elapsed, ~15800 items/min, ETA: 5-15m)
with the count un-grouped, the elapsed in '47s / 5m 12s / 1h 23m' shape,
and the ETA in coarse buckets ('<5m', '5-15m', '15-60m', '>1h'). UD-757
asks for a denser, parser-friendlier shape:
Scanning remote changes... 12,450 items · 0:18 · ETA 1:02
Changes to CliProgressReporter:
- Phase label translation: 'remote' → "remote changes",
'local' → "local files" (was "local changes" pre-fix; the ticket
explicitly renames).
- Comma-grouped item count via Locale.ROOT (locale-stable; de-DE used
to yield '12.450' which parsers misread as 12).
- M:SS for under one hour, H:MM:SS above — applied to both elapsed
and ETA so the two numbers are visually parallel.
- Throughput suffix (~N items/min) dropped: redundant once ETA
renders an actual time string.
- ETA bucketing dropped: the existing UD-747/UD-748 math (count-aware
extrapolation with 4x sanity clamp + 5%-progress floor; falls back
to wall-clock subtraction otherwise) is preserved verbatim, but the
return type changed from String? bucket to Long? remainingSecs and
the renderer formats it via formatTime().
- clock injection: new constructor parameter (default System) so the
new tests can pin elapsed/ETA strings deterministically without
Thread.sleep.
Folder/file split (acceptance criterion #4) deferred per the ticket —
v1 keeps the count combined.
IPC and Notify reporters unchanged — they don't override the hint
methods and onScanProgress already supports the count.
Tests updated:
- UD-742 line-shape tests rewritten to assert the new format
('1,234 items', ' · 0:00', "Scanning local files...").
- UD-713 throughput tests removed (segment dropped).
- UD-747/UD-748 helper tests renamed formatEtaBucket → computeEtaSecs
and now assert numeric remainingSecs instead of bucket strings.
- New UD-757 cases:
* formatTime M:SS / H:MM:SS / negative-input clamp
* formatCount comma-grouped under Locale.GERMAN
* count == 0 renders bare label
* no-history renders count + elapsed but no ETA
* with-history renders ETA via count-aware path (12,450 / 100k @
18s → ETA 2:06)
* with-history + overrun → ETA absent
* phase transition (remote → local) resets phaseStartMs
Test summary:
./gradlew build → BUILD SUCCESSFUL
./gradlew :app:cli:test → all green
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
gkrost
added a commit
that referenced
this pull request
May 3, 2026
… GETs Without an explicit stable sort, paginated full-scans can drop or duplicate rows whenever a concurrent mutation reshuffles the server-side default order — every insert/update/delete during the walk shifts page boundaries, and `delta()` walks with `limit=50` over thousands of items. This is a structural correctness prerequisite for `delta()` and feeds into mechanism #4 of the audit (`docs/audits/internxt-api-vs-spi.md` §3, §6). The Drive spec exposes `sort` ∈ {`updatedAt`, `uuid`} and `order` ∈ {`ASC`, `DESC`}. Only `uuid` is stable under concurrent mutation; row UUIDs are opaque and immutable while `updatedAt` is reshuffled by every write. `order=ASC` is the conventional choice. Refactored both `listFiles` and `listFolders` to a shared `listingQueryParams` helper so the wire shape lives in one place and can be unit-tested without HTTP infrastructure. Two unit tests pin the shape (default + with-cursor). Refs: docs/audits/internxt-api-vs-spi.md §3c, §6 mechanism 4. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 tasks
gkrost
added a commit
that referenced
this pull request
May 16, 2026
* docs(backlog): file 5 open findings from the UD-014 session Backlog hygiene: capture findings surfaced during the UD-014 (MCP provider-agnostic interactive-auth, PR #32) session that weren't in scope for the UD-014 PR itself. UD-221 InteractiveAuthSpiContractTest pulls provider HTTP stacks into :app:core test classpath — 29 new lockfile entries (ktor-cio, sqlite, kotlin-reflect, ...). Question whether this dep bleed is acceptable or the test should move to a new module. Recommended status quo for now. UD-229 IpcServer.kt:69 uses DelicateCoroutinesApi without opt-in or structured scope. Compile warning on every build. UD-319 OneDriveProvider.kt:235 unnecessary safe call on non-null ParentReference. Trivial Kotlin warning fix. UD-320 OneDrive OAuthService.getDeviceCode missing postWithFlakeRetry wrapper. First call in the device-flow handshake hard-fails on TLS handshake blip; the other four OAuth calls all use the retry helper. Surfaced as Minor #4 in the UD-014 end-to-end review. UD-710 docs/dev/lessons/README.md index drift: 3 lesson files present in the dir but missing from the table (http-retry-policy, internxt-notifications-websocket, tool-result-injection-scoping). All five are low-priority XS/S items. Pre-existing for UD-229, UD-319, UD-320, UD-710; UD-221 was introduced by UD-014 itself as a deliberate trade-off with the recommended-status-quo answer already noted in the ticket body. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * docs(backlog): renumber to non-colliding IDs (PR #35 review) Codex review on PR #35 caught that `backlog.py next-id` only scans current frontmatter `id:` lines, not prose cross-references. Four of the five IDs I filed collided with prior repo-wide allocations: UD-221 → UD-246 (UD-221 was a closed UI tray submenu ticket; see CLOSED.md:176 — tray status reference) UD-229 → UD-250 (UD-229 is "OneDrive Graph coverage" research, referenced from BACKLOG.md:115/127/332/349) UD-319 → UD-339 (UD-319 is the Internxt robustness deliverable, referenced from docs/providers/internxt-robustness.md) UD-320 → UD-374 (UD-320 is the OneDrive robustness deliverable, referenced from docs/providers/onedrive-robustness.md and CLOSED.md:2021) UD-710 stays (clean — only my new entry references it). New IDs verified zero prior references via: grep -rnE "UD-246|UD-250|UD-339|UD-374" docs scripts core --include="*.md" --include="*.kt" --include="*.py" --include="*.sh" → no output. Per AGENT-SYNC: IDs live forever and are referenced from docs/code. Reusing numbers makes future grep / changelog / follow-up tickets ambiguous between unrelated pieces of work. Internal cross-references in my own entries also updated: UD-339's body: "tracked separately under UD-229" → UD-250 UD-250's body: "redundant safe-call — tracked separately under UD-319" → UD-339 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
gkrost
added a commit
that referenced
this pull request
Jun 4, 2026
Fifth and sixth plans (P4b split into two files for output-token reasons; both halves implement one logical plan). Part 1 (Tasks 0-7): deb + rpm + AUR channel recipes, render-changelog shared by all three, extension of local-build.sh to cover deb/rpm/AUR, and sign-packages.sh (sftp to pkg-signer via ProxyJump, sign-drop, sftp back). Part 2 (Tasks 8-17): publish-apt / publish-dnf / publish-aur / publish-gh-release / release.sh top-level orchestrator, repo-server skeleton, Docker smoke matrix (ubuntu:24.04 / fedora:40 / archlinux:latest / debian:13), test-packaging.yml + release.yml CI workflows, AUR bot-account setup walkthrough. Spec: docs/dev/specs/unidrive-distribution-design.md §4.2, §4.3, §4.4, §4.6, §4.7, §5.1, §5.2, §7.3, §7.3.1, §8.1, §8.2, §8.6, §10 AC #4, #5, #6. P5 still to draft: first-release cutover (RELEASES.md content, real publish, AC verification, BuildInfo reconciliation from review-3 Issue 1, install landing page).
gkrost
added a commit
that referenced
this pull request
Jun 4, 2026
* docs(spec): distribution & release engineering design Specifies how UniDrive ships to end users on Linux: a third repo (unidrive-dist) handles packaging, signing, and publishing; the existing unidrive and unidrive-mount-linux repos only publish their own raw artefacts on tag. Four MVP channels: tarball + apt + dnf + AUR. Snap/Flatpak deferred with explicit rationale. krost-infra gains a pkg-server container serving apt.unidrive.krost.org and dnf.unidrive.krost.org. Brainstormed and approved; awaiting implementation plan. * docs(spec): address review findings on distribution design Incorporates the review at docs/dev/reviews/unidrive-distribution-design-review.md plus the prior round of review notes: - §3.3 drop forced lockstep tagging; sibling repos tag only when their own code changes; unidrive-dist tag is authoritative; fetch-artefacts.sh queries latest matching SemVer GH Release. - §3.4 spell out the v0.0.1[-pkgN] tag-parsing regex; remove "trivial" hand-wave. - §4.2 fix invalid `systemctl --global daemon-reload` in deb postinst (and rpm %post); systemd auto-discovers user units, no daemon-reload needed. - §4.2 fix invalid `java21-runtime` virtual package dependency; use `java-runtime-headless (>= 21)`. - §4.2 add JDK shelf-life note: MVP pins to JDK 21; --enable-native-access flag form changes in 22+. - §4.3 add sourced verification that RHEL 10 ships kernel 6.12 (above the 6.9 floor). - §4.7 add changelog strategy: single RELEASES.md as source of truth, build-time render into debian/changelog and rpm %changelog. - §5 replace ambiguous in-CI signing with dedicated pkg-signer container on krost-infra; signing key never reaches the GH Actions runner. - §6 add RELEASES.md to repo layout. - §7.3.1 add unidrive.repo contents with repo_gpgcheck=1 and gpgkey=. - §7.4 change A records to CNAMEs targeting unidrive.krost.org so server-IP changes update one record, not three. - §7.5 rewrite SSH deploy account section; add deploy-key rotation playbook matching the GPG-key rotation in §3.7. - §8.2 ubuntu:24.04 (LTS, exists today) is primary smoke target; 26.04 added when GA. AUR smoke test creates non-root build user with sudo for pacman because makepkg refuses to run as root. - §10 AC #7 uses Ubuntu 24.04 LTS for first-release E2E smoke. - §4.4 AUR push uses a dedicated bot Arch account (unidrive-bot) registered on aur.archlinux.org; deploy keys aren't supported at the repo level on AUR. - §4.1, §4.2 JAR naming aligns with existing build output convention (unidrive-X.Y.Z.jar, not unidrive-cli-X.Y.Z.jar). - §4.1 tarball install.sh dynamically generates wrapper script with the versioned JAR path baked in. - §9 drop man page from MVP; CLI --help is canonical. - §9 replace "remote signing service" deferred item with "hardware-backed signing key (HSM/YubiKey)" since on-server signing container is now MVP. Also captures the review under docs/dev/reviews/ alongside the spec for posterity. * docs(spec): fold in second-review minor clarifications Second review (docs/dev/reviews/unidrive-distribution-design-review-2.md) confirmed no blocking issues. Folding in three of its six observations as spec-level clarifications: - §4.7: name the maintainer identity for debian/changelog and rpm %changelog headers (UniDrive Releases <releases@unidrive.krost.org>, matching the GPG identity from §5). - §5.2: explicitly list SHA256SUMS (tarball bundle), apt Release/InRelease, and dnf repomd.xml in the set of artefacts pushed to pkg-signer; remove ambiguity about what gets signed. - §8.4: note that the E2E manual smoke is interactive by design (unidrive auth opens a real OAuth flow); no headless equivalent for MVP. Three other observations from the review are deferred to writing-plans: pkg-signer stdin-vs-drop-dir choice (§5.1), sign-packages.sh local vs production role (§6, §8.5), Snap re-evaluation angle (§4.5; flagged by reviewer as design-continuity awareness only). * docs(plan): P1 — JVM release-workflow implementation plan First of five plans implementing the distribution spec. Adds a tag-triggered GH Actions workflow to unidrive that publishes the signed CLI fat JAR to GH Releases on v* tag push. Bite-sized tasks; full code blocks; local dry-run verifies the bash logic before the workflow ever fires. Spec: docs/dev/specs/unidrive-distribution-design.md §3.3 step 1, §4.1, §5, §10 AC #1. * docs(plan): P2 — Rust release-workflow plan for unidrive-mount-linux Second of five plans. Tag-triggered GH Actions workflow that cross-builds unidrive-mount for x86_64 and aarch64 (latter via cross-rs/cross), packages each as a tarball with LICENSE+NOTICE, signs and attaches to a GitHub Release. The plan describes work in the sibling unidrive-mount-linux repo but the plan file lives here because unidrive-mount-linux's AGENTS.md "Doc surface is bounded" rule does not sanction a docs/plans/ path, while this repo's AGENTS.md does. Also bumps unidrive-mount/Cargo.toml version 0.1.0 → 0.0.1 to align with the coordinated MVP release version per spec §10 AC #2. Spec: docs/dev/specs/unidrive-distribution-design.md §3.3 step 2, §4.1, §5, §10 AC #2. * docs(plan): P3 — krost-infra pkg-server + pkg-signer Third of five plans. Provisions the krost-infra side of the distribution stack: two new Docker Compose services (pkg-server static nginx for apt + dnf sub-domains; pkg-signer SSH-keyed signing service), Traefik routes, DNS CNAMEs, restricted SSH deploy users, GPG key generation on the VPS, GH Actions secrets provisioning, and the krost-infra docs sync required by its AGENTS.md. Plan lives in unidrive/docs/dev/plans/ (rather than krost-infra) because the distribution-spec plans co-locate with the spec; krost- infra has no docs/plans/ convention. Spec: docs/dev/specs/unidrive-distribution-design.md §5, §7.1–§7.6. * docs(plan): P4a — unidrive-dist scaffolding + tarball channel + fetch-artefacts Fourth of six plans (the original P4 split into P4a + P4b to keep each plan reviewable). Creates the new unidrive-dist GitHub repo with its scaffolding (LICENSE, AGENTS.md with version-exception clause, BACKLOG, CLOSED, RELEASES, README, docs/), the tarball packaging channel, the fetch-artefacts.sh script (spec §3.4 tag regex + sibling GH-Release resolution), and the local-build.sh dev-loop driver. Spec: docs/dev/specs/unidrive-distribution-design.md §2.2, §3.3, §3.4, §4.1, §4.7, §6, §6.1, §10 AC #3. * docs(plans): address review-3 findings on plans P1-P4a Six findings from the third review (now captured at docs/dev/reviews/unidrive-distribution-plans-review.md). Applied inline across the four affected plans: - P1: rewrote "no BuildInfo changes" scope clause to make the tension with spec §3.5 explicit; reconciliation deferred to P5 pre-flight rather than silently violating the spec at first tag. - P2: added KNOWN RISK comment in the workflow YAML noting two fallback strategies for cross 0.2.5 + edition 2024 incompatibility, and a new Task 4a that runs a real local aarch64 cross-build before the first tag push. - P3: added recovery-path comment to pkg-signer's sign-drop forced-command (sftp-pull retry, not re-sign). - P4a: documented version-extraction fragility for the awk-based parsing of core/build.gradle.kts; added gh-CLI auth prerequisite to fetch-artefacts.sh header; carved out the dev-loop exception in AGENTS.md's "no source code" rule. All six findings were minor-to-medium; none blocked the planning phase. P4b and P5 remain to be drafted. * docs(plan): P4b — unidrive-dist channels + orchestration + smoke matrix Fifth and sixth plans (P4b split into two files for output-token reasons; both halves implement one logical plan). Part 1 (Tasks 0-7): deb + rpm + AUR channel recipes, render-changelog shared by all three, extension of local-build.sh to cover deb/rpm/AUR, and sign-packages.sh (sftp to pkg-signer via ProxyJump, sign-drop, sftp back). Part 2 (Tasks 8-17): publish-apt / publish-dnf / publish-aur / publish-gh-release / release.sh top-level orchestrator, repo-server skeleton, Docker smoke matrix (ubuntu:24.04 / fedora:40 / archlinux:latest / debian:13), test-packaging.yml + release.yml CI workflows, AUR bot-account setup walkthrough. Spec: docs/dev/specs/unidrive-distribution-design.md §4.2, §4.3, §4.4, §4.6, §4.7, §5.1, §5.2, §7.3, §7.3.1, §8.1, §8.2, §8.6, §10 AC #4, #5, #6. P5 still to draft: first-release cutover (RELEASES.md content, real publish, AC verification, BuildInfo reconciliation from review-3 Issue 1, install landing page). * docs(plan): P5 — first-release cutover for v0.0.1 Sixth and final plan. Operator runbook for cutting the first real v0.0.1 UniDrive release. Touches all four working repos: - unidrive: fix(cli) reconciles BuildInfo --version output with spec §3.5 (review-3 Issue 1 resolution). - unidrive-mount-linux: tag v0.0.1. - unidrive-dist: first RELEASES.md entry, tag v0.0.1, fill in docs/release-process.md. - krost-infra: sites/unidrive/install/index.html landing page with per-channel install instructions and the GPG fingerprint. Includes: - AC #1-#8 verification map. - First AUR push + co-maintainer setup. - E2E manual smoke on Ubuntu 24.04 LTS per spec §8.4. - Common CI-failure recovery notes (cross 0.2.5 fallback, etc.). All six plans (P1, P2, P3, P4a, P4b, P5) now drafted on spec/distribution.
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.
Bumps gradle-wrapper from 9.4.1 to 9.5.0.
Release notes
Sourced from gradle-wrapper's releases.
... (truncated)
Commits
3fe117dUpdate jdks.yaml (#37703)33d145aUpdate jdks.yamlf7a05d1Update Gradle wrapper to version 9.5.0-rc-4 (#37654)266facdUpdate Gradle wrapper to version 9.5.0-rc-40ad6dd8Suppress OSC taskbar reset on plain/piped stdout (#37646)966025dSuppress OSC taskbar reset on plain/piped stdoute745573Polish IP docs (#37642)d5cfd07Ensure BuildOperationQueue will progress without extra leases (#37629)acdf0c3Ensure BuildOperationQueue will progress without extra leasesf7d0e4fRename anchorDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)