17-minute hang on git clone, far past the http.lowSpeedLimit abort
threshold, isn't explained by a data-transfer stall. Now that the VM has
a real GUI session (auto-login), git-credential-osxkeychain could be
popping a GUI dialog nobody's there to dismiss, bypassing
GIT_TERMINAL_PROMPT. Disable the credential helper and force askpass to
fail immediately instead of prompting.
Blanket xcargs (CODE_SIGN_STYLE=Manual etc.) applied to every target in
the build, including the SPM package's own generated targets (PediFoods,
pedi-foods_PediFoods) which explicitly reject provisioning profiles and
need to stay Automatic. Use update_code_signing_settings scoped to just
"PediFoods App" instead, guarded behind DEVELOPMENT_TEAM being set so
Bitrise's existing automatic-signing path is untouched.
Main app target signed fine after the manual signing override, but the
SPM-generated pedi-foods_PediFoods target still failed with "requires a
development team" - it needs DEVELOPMENT_TEAM directly since profile
specifiers only map to the app's own bundle ID. Already available as a
job env var, just wasn't being passed into xcodebuild's build settings.
xcodebuild ignored sigh's downloaded provisioning profile because the
Xcode project's signing style is Automatic, which needs an interactive
Apple ID session unavailable in headless CI. Override at build time via
xcargs instead of changing the checked-in project signing settings.
git clone froze for 9+ minutes on one run with no clear cause. Set
GIT_TERMINAL_PROMPT=0 so it fails fast instead of hanging if credential
auth ever goes wrong, and abort via http.lowSpeedLimit/lowSpeedTime if
the transfer genuinely stalls instead of just being slow.
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.
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
