Drop the SSH + restricted-key design entirely. wake/sleep now runs on a
new macos-ctl runner (its own Docker container on the VPS, Docker socket
mounted) which runs docker start/stop macos directly on the sibling
container - no SSH indirection, and no borrowing of another project's
runner (pedifoods-web) to do it.
runs-on: docker matched no registered runner (labels are macos-release,
atomenta, pedifoods, lc-wallet-web). Use pedifoods, this repo's own
existing always-on runner, to run the wake/sleep SSH steps.
Replaces bitrise.yml with equivalent test/beta/release pipelines running
on the self-hosted macos-release runner (act_runner inside a dockur/macos
VM). Each workflow wakes the VM over SSH before the job and stops it
after, since the VM can't be left running 24/7 without starving the
VPS's other services.
Adds a pre-login public store locator (guest session via DeviceCheck/App
Attest, keychain-backed token storage) so the app no longer forces sign-in
before showing any content, plus updated support URL metadata.
Same class of bug as the earlier matching-cascade fix: selectedCustomerAddress
is resolved asynchronously against the address book and can lag behind or
mismatch. appState.address.display is set synchronously the moment the user
picks an address (AddressesView.selectAddress) — it's the authoritative live
value. customerAddressName had these backwards, checking the async value
first.
CheckoutView.swift's addressSection showed the literal string "Casa"
as the address name/label regardless of which address was actually
selected — only the street/detail line below it (customerAddressLabel)
was wired to real state. Added customerAddressName, preferring
selectedCustomerAddress?.label then appState.address.display, matching
the same fallback pattern already used for the detail line.
Explains why the delivery fee specifically never changed while other
address info (label, street) updated fine after the previous fix:
AddAddressFormView only sets latLong when the CEP lookup happens to
return coordinates (AddAddressFormView.swift:141-146) — plenty of saved
addresses have none. Without coordinates the backend can't distinguish
that address from the previous one, so the fee (and, in Checkout,
checkoutAddressWatchKey itself) never actually changes, without any
error surfacing since it likely falls back to some default fee instead
of rejecting.
Added LocationService.geocodeAddress(street:number:neighborhood:city:
state:zip:), a thin CLGeocoder wrapper, and call it in both
CartView.refreshDeliveryFee and CheckoutView+Logic.
validateDeliveryAddressIfNeeded whenever coordinates are missing,
persisting the result back into appState.address so it doesn't need to
re-geocode on every subsequent check.
CustomerAddress.id is genuinely optional (Services/ApiModels.swift:46) —
some address book entries have no id. AddressesView.selectAddress sets
appState.address.selectedId = address.id directly with no fallback, so
picking one of those addresses leaves selectedId nil. The matching
cascade in both CartView and CheckoutView+Logic then skipped straight to
a label match, which silently collides whenever two addresses share an
empty or duplicate label (common for unnamed entries), and finally fell
back to addresses.first — always redisplaying whatever's first in the
list regardless of what was tapped, with no error surfaced anywhere.
Coordinates are set immediately and reliably at selection time and are
far less likely to collide than a label. Checkout already had a lat/lng
fallback but ordered after the weak label match; promoted it ahead of
label matching in both files, and added the same fallback to Cart, which
didn't have one at all.
Cart's delivery fee and Checkout's address validation both fetched the
customer profile without forcing a cache refresh (2h TTL), then let that
possibly-stale address book unconditionally overwrite the just-picked
appState.address coordinates before building the fee/validation payload.
Result: changing the address on Home didn't reliably move the cart's
delivery fee, and Checkout's 'Alterar' could silently revert to the old
address when the stale coordinates made the backend report it as not
served.
Force-refresh the profile fetch and only use it to fill genuine gaps in
appState.address, never to override a live user selection.
Same failure again with platform: iOS set. Unlike xcode-archive@5's error
('Define the platform step input manually to avoid this phase in the
future'), this step's error gives no such hint — it has no override.
Confirmed twice now: this step cannot run on a target with
SUPPORTED_PLATFORMS = iphoneos iphonesimulator macosx. Back to relying
on xcode-archive@5's own automatic_code_signing: api-key alone.
Removing it earlier also removed the cert/profile provisioning it does
before archive — same mechanism LC Wallet's pipeline actually relies on.
The export failure ('No profiles for com.br.pedifoods.app were found',
'Cloud signing permission error') was that provisioning step missing,
not a Developer Portal or API key permission problem — both were already
confirmed fine. Should have looked for a platform override on this step
first, same as xcode-archive@5, instead of deleting it outright.
Same SDKROOT = auto issue as manage-ios-code-signing, this time inside
xcode-archive@5's own platform auto-detection. The step's log names the
fix itself: 'Define the platform step input manually to avoid this
phase in the future.'
Fails with 'no PLATFORM_DISPLAY_NAME config found for (PediFoods App)
target'. SUPPORTED_PLATFORMS = iphoneos iphonesimulator macosx on this
target (Skip's build) makes the step's platform detection ambiguous.
xcode-archive@5's own automatic_code_signing: api-key already handles
signing, so the step was redundant on top of being broken here.
xcode-archive@5 failed: 'unkown SDKROOT: auto'. Darwin/PediFoods.xcconfig
sets SDKROOT = auto and SUPPORTED_PLATFORMS = iphoneos iphonesimulator
macosx (Skip's multi-platform build target) — same root cause as the
earlier PLATFORM_DISPLAY_NAME failure from manage-ios-code-signing.
Both are Bitrise step-side project parsers that pre-guess a single
platform before invoking xcodebuild, and neither understands this
project's build shape.
xcodebuild itself has no problem with SDKROOT = auto (confirmed via a
local build). Only Bitrise's own step parsers choke on it. Going through
fastlane's build_app instead sidesteps that parser entirely — it's the
same approach the Darwin/fastlane/Fastfile already used before, restored
here with the earlier apikey.json JSON-escaping and DEVELOPMENT_TEAM
injection fixes kept.
Step failed: 'no PLATFORM_DISPLAY_NAME config found for (PediFoods App)
target'. It queries build settings without pinning an SDK, and this
target's SUPPORTED_PLATFORMS = iphoneos iphonesimulator macosx (Skip
builds Darwin for both iOS and Catalyst-style macOS) makes that
ambiguous — LC Wallet's iOS-only target never hits this.
xcode-archive@5 already has automatic_code_signing: api-key, which
manages signing itself during archive. The separate step was redundant.
Referenced build_for_testing/test_without_building workflows that were
never defined — copied the pipeline block from LC Wallet without its
matching workflow definitions. Unused anyway (not in trigger_map, no
PR trigger wanted), so removing instead of completing it.
Switch from fastlane-driven build (build_app + hand-rolled apikey.json)
to Bitrise's own xcode-archive step, matching LC Wallet 1:1: manage-ios-
code-signing + xcode-archive@5 (automatic_code_signing: api-key) do the
build/sign, deploy-to-itunesconnect-deliver@2 handles TestFlight in the
beta workflow, fastlane only runs for the release lane (metadata push +
App Store upload) reading BITRISE_IPA_PATH — same shape as LC Wallet's
Fastfile beta/release lanes.
Only genuine differences from LC Wallet, all forced by this project's
actual layout:
- BITRISE_PROJECT_PATH/SCHEME point at Darwin/PediFoods.xcodeproj
- fastlane work_dir is Darwin/ (Fastfile lives there, not repo root)
- build number bumps CURRENT_PROJECT_VERSION in Skip.env instead of
agvtool — this project has no VERSIONING_SYSTEM set, Skip.env is the
actual shared source of truth for both Darwin and Android
- team_id comes from a DEVELOPMENT_TEAM secret instead of a hardcoded
literal — LC Wallet's Apple team ID isn't necessarily this app's
ASC_KEY_CONTENT is the raw .p8 private key, which contains literal
newlines. The heredoc interpolated it straight into a JSON string,
producing invalid JSON (JSON::ParserError in get_provisioning_profile).
Build the file with Ruby's JSON encoder instead so newlines are escaped
correctly. Verified locally against a realistic multi-line PEM value.
