Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Build and CI: clear the warnings so the next real one stands out, and give the surface gallery job headroom

Open
  • Is something wrong?
#361 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
25/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
python, swift, yaml
Domain
build-system, ci-cd

Research direction

Start by running swift build -c release from a clean .build to reproduce the warnings, then fix the listed sites in WorkbenchHome.swift, MeetingWorkspaceView.swift, PhoneLink.swift and FloatingToolbar.swift. The timeout change is a one-line edit to timeout-minutes at ci.yml:183, plus its comment at ci.yml:19-20. Done means no warning: lines beyond PackCredentials.swift:36 and checks passing, but the pixel-identical render requirement needs a macOS setup.

Written by the indexing model from the issue text.

Description

Outcome: a clean build prints one deliberate warning, PackCredentials' deprecation. The slowest CI job no longer runs at up to 80% of its time limit.

1. Warnings (train head 14d06bc)

Evidence. Every warning below is at the cited line on 14d06bc.

  • Deprecated onChange(of:perform:) (deprecated since macOS 14, the deployment target in Package.swift:15): WorkbenchHome.swift:236, :237, :628, :629, :630, and MeetingWorkspaceView.swift:227.
  • Main-actor members used from nonisolated contexts:
    • PhoneLink.swift:591-592 calls refresh() from queue: .main observers.
    • FloatingToolbar.swift:225 reads controls.revealsResult inside the Sendable onGeometryChange transform.
    • HomeJourneyChecks.swift:211 reads TextDelivery.copiedMessage (TextDelivery.swift:40).
    • HandoffManualChecks.swift:218 calls RunLoop.main.run from an async context.
  • No-ops:
    • scripts/test-readback-resources.py:30: unused optionalMissing.
    • PresenterPauseChecks.swift:180: a weak var never mutated.
    • Tests/StageKitLegacy/PhoneOwnerTests.swift:331: unused result.
    • PersonaCameraTests.swift:1277: a try with nothing that throws.
    • Tests/PrivatePackKitTests/PackStoreTests.swift:175, :181: an await with no async work.
  • CI builds from clean (ci.yml:111, :126, :141, :193), so every run prints all of these with source excerpts. A new real warning is easy to miss among them.

Change

  • (a) Use zero-parameter .onChange(of:) at the five WorkbenchHome sites and { _, value in } in MeetingWorkspaceView. Bodies are unchanged.
  • (b) In PhoneLink, use { [weak self] _ in MainActor.assumeIsolated { self?.refresh() } }. The observers run on .main; FeedbackViews.swift:108 uses the same pattern.
  • (c) In FloatingToolbar, add let isResult = controls.revealsResult beside let state in body and use it in the transform.
  • (d) Make copiedMessage a nonisolated static let.
  • (e) Only with a before/after render of handoff-ready.png and handoff-manual.png: delete the nested RunLoop.main.run and raise the Task.sleep to 30 ms, which keeps the roughly 450 ms wait before the readiness guard (:220). Without that render, leave this one warning.
  • (f) Make the mechanical no-op fixes.
  • Keep PackCredentials.swift:36.
  • Add no warning-count guard: incremental builds don't re-emit warnings, so a guard would flake.
  • Swift 6 language mode is not adopted (Package.swift:41).

Acceptance

  • Start from a deleted .build. swift build -c release, swift build --build-tests, bash scripts/test.sh and bash scripts/test-stage.sh --ci print no warning: under Sources, Tests or the generated checks, except PackCredentials.swift:36.
  • --check-core, --check-floating-toolbar, --check-presenter and --check-handoff-jobs pass.
  • Home (including the permissions states), Meetings and toolbar renders are pixel-identical, apart from clock and timing.
2. Surface gallery timeout

Evidence

  • ci.yml:132, :147 and :183 give Release checks, Toolbar gallery and package, and Surface gallery 25 minutes each.
  • Over the 200 most recent CI runs (6 to 14 October), measured as step time:
    • Surface gallery: median 15.6 min, p90 17.6, worst 19.9, which is 80% of its limit. Its median rose from 14.4 to 16.9 min over the period.
    • Release checks: worst 17.4 min (70%).
    • Toolbar: worst 17.2 min (69%).
  • No timeout has fired yet.
  • The comment at ci.yml:19-20 still says the longest job takes 'about 13 minutes'. The measured median of the longest job is 16.1 minutes.

Change

  • Set Surface gallery's timeout-minutes to 30 (:183). Leave the other two at 25.
  • Change the comment to 'about 16 minutes; the surface gallery, the slowest, has taken up to 20'.
  • In the commit message, cite the medians and maximums, and note that SurfaceGallery's per-page deadlines (SurfaceGallery.swift:2650-2653) still stop a hung page.

Acceptance

  • A read-only script over the last 200 runs' job steps shows every native job's worst passing run at or under 70% of its limit.
  • The comment's stated time is within 2 minutes of the measured median.
  • scripts/test-ci-scope.py passes, and the workflow parses.
Value before scope
  1. Outcome: the next real warning stands out, and a slow runner doesn't time out a merge-queue run.
  2. Simpler route: the fixes the compiler names, and one limit raised.
  3. Owner: the files named, and ci.yml.
  4. Complexity: none added.
  5. Verified by: clean builds, checks, pixel-identical renders and measured CI timings.

Grammar: Codebase.

Refs #282

Build-ready record from the 15 Oct round-three pass (delight and code-base value), verified against the release train head 14d06bc by an independent skeptic per item. Closes only after native acceptance.

Dominant language
Swift
Stars
0
Forks
1
Avg merge
8h 5m
Merged PRs (30d)
215

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Ship-Work/workbench

All issues in Ship-Work/workbench

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.