Identity is visible via the same commands over interactive SSH but not
from this job's own process, even within a single merged step - adding
whoami/HOME/path/keychain-info printouts to see what's actually
different about this execution context before guessing further.
Identity was visible with find-identity inside the unlock step itself
but still invisible to fastlane in the next step - each run: block
likely spawns a distinct process/session on this host executor, so the
unlock doesn't survive across steps even though keychain search-list
membership does. Run unlock and fastlane in the same shell invocation
to remove that boundary entirely.
A Gitea Actions job runs in a different macOS security session than an
interactive SSH login - login.keychain-db's unlock state and search-list
membership don't reliably carry over across that boundary, so the
identity was invisible to the job even after successful unlock. Point
the workflow's unlock step at a dedicated ci-signing.keychain-db instead,
created independent of any login session.
Unlocking alone wasn't enough - the launchd session's default keychain
search list apparently doesn't include the login keychain by default,
so sigh/fastlane still found zero identities even after a successful
unlock. Explicitly set it as both the search list and default keychain,
and print find-identity in the step itself to verify before fastlane runs.
act_runner's launchd daemon now runs as loverde_vm_mac (UserName set),
but its background session doesn't inherit the unlock state from an
interactive SSH session - the login keychain is still locked when
fastlane/sigh looks for signing identities, so none are found. Unlock it
explicitly at the start of each signing job instead.
actions/checkout@v4 is a JS action, and act_runner's host-executor JS
action path hits a known upstream caching bug on this runner (nested
hostexecutor/.cache/act path never gets the downloaded action, causing
MODULE_NOT_FOUND on every run). Introducing a config.yaml to work around
it (workdir_parent) triggers a separate act_runner bug requiring a Docker
socket that doesn't exist on this Mac. Side-stepping both by doing the
checkout as a plain shell git clone, which the host executor runs fine.
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.
