github.run_id is a global counter across the whole Gitea instance (the
same numbering as the 'task NNNN' IDs in the runner's own logs), not
what Gitea's web UI uses in its /actions/runs/<n> URL - that's the
per-repository run_number. The email's 'Ver execução' link pointed at
a run belonging to a different, unrelated repo/workflow entirely.
The <style>-in-head version rendered broken in the actual mail client
(no card, no colors, no spacing - the email client stripped the style
block, a common limitation of HTML email). Rewrote as a table-based
layout with every style attribute inline, which is the robust approach
for cross-client HTML email compatibility, and added the real Atomenta
logo (https://atomenta.com.br/assets/images/logo_2024.png, the same
asset served by the Atomenta app's own public/assets). Dropped the
dark-mode media query - not expressible with inline-only styles, and
not essential for an internal CI notification.
Reused the visual style from the existing Atomenta transactional email
templates (src/views/emails/pedifoods/admin_review_alert.html in the
Atomenta repo) - card container, colored status badge, label/value
details box, dark-mode support. Branding is generic Atomenta (header
and footer), since this notification is shared across all projects on
this CI - only the email Subject names which project it's about
('[PediFoods CI] ...'). Sent as a proper MIME text/html message instead
of the earlier plain-text body.
Sends an email via the domain's own SMTP (mail.loverde.com.br:587,
STARTTLS) as the last step of both test.yml and beta.yml, using
if: always() so it fires regardless of the job's outcome - subject/body
include job.status, branch, commit and a link to the run. Credentials
(SMTP_USER, SMTP_PASS, NOTIFY_EMAIL_TO) come from repo/org secrets, not
hardcoded here.
User wants build numbers to always follow this format, incrementing
<n> across multiple builds on the same calendar day and resetting to 1
on a new day - not a manually-edited fixed string, and not the CI run
counter (which just uploaded a build as '51', unrelated to the real
versioning scheme).
Added next_build_version, which persists {date, build_number} to a
fixed path under this CI user's home directory on the Mac mini runner
(~/ci-build-version-state/pedifoods.json) - state has to live outside
the per-run checkout, since every CI run gets a fresh, throwaway clone
under .cache/act/<random-hash>/. assemble now passes this as the
CURRENT_PROJECT_VERSION xcarg instead of the project's committed value,
so every build gets a fresh, correctly-formatted, ever-increasing
version automatically.
assemble was passing CURRENT_PROJECT_VERSION=$BUILD_NUMBER (github.run_
number-style CI counter) as an xcarg, silently replacing the project's
real, manually-managed version (e.g. '2026.09.11.0.0.1') with an
unrelated small integer - the just-uploaded TestFlight build showed up
as '0.0.1 (51)' instead of the intended version. Removed the override
and the now-unused BUILD_NUMBER env var in beta.yml; CI now always
builds with whatever CURRENT_PROJECT_VERSION is committed in the
project. Re-running CI against the same commit without bumping it first
will now get a clear 'duplicate build number' rejection from Apple
instead of silently uploading under the wrong version.
The prior force:true fix only touched the main app's profile and let
sigh name it '<bundle id> AppStore' - a different name than the one
manual signing expects (PROVISIONING_PROFILE_SPECIFIER = 'LC Prov
PediFoods Dist Profile' / 'LC Prov PediFoods Dist Push Profile', baked
into PediFoods.xcodeproj per target). Xcode resolves profiles by exact
Name match against installed .mobileprovision files, so it never found
sigh's freshly-created one and kept falling back to the stale,
wrong-certificate profile under the old name - the extension's profile
was never touched at all, since sigh only acts on the app_identifier
it's given.
Added renew_provisioning_profiles (shared by beta and release), calling
get_provisioning_profile once per target with an explicit
provisioning_name matching what the project actually expects, plus
force: true so each is regenerated against the team's current
certificates.
Archive failed with 'Provisioning profile ... doesn't include signing
certificate iPhone Distribution: Loverde Company LTDA (K4E5BZMM4V)' for
both the app and NotificationServiceExtension targets, once ASC auth
itself was working. Without force: true, get_provisioning_profile just
downloads whatever profile already exists on Apple's servers as-is -
this CI keychain's distribution certificate differs from whatever the
existing profiles were last generated against. force: true makes sigh
regenerate them against the team's currently valid certificates.
The original helper only ever tapped the *first* product's add button
and assumed it went straight to Cart. That's the same single-path
assumption that produced the wrong 'product list never loaded'
diagnosis - the first product on this catalog ('Alcatra') has add-ons
and opens ProductDetailSheet ('Detalhes') instead of adding directly.
Fixing just the button selector would have hidden this and failed
differently on the next run.
Renamed reachCheckoutWithOneItem to reachCheckoutWithProducts(_:count:
Int = 3) and added addProduct(atIndex:in:), which taps the Nth
product's add button and branches on the real outcome: if
ProductDetailSheet appears, confirms via its own main action button
('Atualizar...') and waits for it to dismiss; otherwise the product
already added directly. Loops over the first 3 products (capped by the
actual button count) so both flows are exercised on every run,
regardless of which specific products the real catalog happens to give
add-ons to.
See decisions/2026-09-11-ui-test-shared-login-session.md follow-up.
quickDiagnostics finally showed the real state at the timeout: Store
Detail had genuinely loaded (store header, category tabs, a real priced
product 'Alcatra' R$ 14,00 all visible) - 'product list never loaded'
was simply the wrong diagnosis. The test was matching
app.images.matching(identifier: "plus") against the product row's add
button, relying entirely on SF Symbol systemName being exposed as an
implicit accessibility identifier - which wasn't holding on this Xcode
26/iOS 26 CI environment, and is inherently ambiguous anyway since
CartView's own quantity stepper reuses the same "plus" systemName.
Added a real .accessibilityIdentifier("storeDetailProductAddButton")
to the product row's add Button in StoreDetailView+Components.swift (an
app-source change, not just a test workaround), and updated the test to
match on that instead.
See decisions/2026-09-11-ui-test-shared-login-session.md follow-up.
'.map(\.label)' failed to build: XCUIElement.label is @MainActor-isolated,
and a bare key path literal must be formable from any isolation context,
which a main-actor-isolated property can't satisfy. This was a hard
compiler error (not just a concurrency warning), and it cascaded into a
flood of secondary diagnostics across the whole file/batch compile unit,
obscuring the actual cause. Replaced with a closure ('{ $0.label }'),
which isn't subject to that restriction.
The file-based diagnostic dump never worked: PediFoodsUITests-Runner
runs as an app inside the simulator, sandboxed to that device's own
container filesystem. NSTemporaryDirectory() called from test code
resolves inside the simulator's data container, invisible to the host
shell's $TMPDIR a later CI step tried to cat - confirmed by the new
step printing 'No UI test diagnostic log was written.' every time.
Replaced with quickDiagnostics(_:), which builds a short live-state
summary (closed-store snackbar, spinning activity indicator, any open
alert, visible 'erro' text, first ~15 visible static texts) and
interpolates it directly into each of the three XCTAssertTrue failure
messages - the one channel already confirmed working end to end on
every run. message: is @autoclosure, so this costs nothing when the
assertion passes. Removed the dead file-write helper and the now-unused
CI step.
See decisions/2026-09-11-ui-test-shared-login-session.md follow-up.
Confirmed (pasted full CI log around a timeout, searched for the
print()'d marker string, found nothing) that plain print() from inside
a UI test never reaches fastlane's xcodebuild log output on this
runner - its formatter only relays lines matching its own known
patterns and drops everything else.
CartCheckoutFlowTests now writes app.debugDescription to
NSTemporaryDirectory()+'pedifoods_uitest_diag.log' on each of its three
failure points (shared dumpDiagnostics helper, appending), clearing any
stale copy in class setUp(). test.yml gained a step after 'Run tests
with coverage' (if: always()) that cats that file when present - TMPDIR
is stable for the whole CI job, unlike the per-run-hashed workspace
path that broke the original screenshot attempt.
See decisions/2026-09-11-ui-test-shared-login-session.md follow-up.
All three failure-path screenshot saves in this file wrote to a
hardcoded path from a different machine/session
(/private/tmp/claude-501/-Users-loverde-co-.../scratchpad), which
doesn't exist under the Mac mini runner's user account - try? silently
swallowed the write failure, so no diagnostic evidence was actually
produced on CI failures.
Replaced with app.debugDescription printed to stdout, which lands
directly in the CI log with no extra file access needed - same
technique already used in
decisions/2026-08-06-ui-test-account-and-app-attest-bypass.md. Next
CartCheckoutFlowTests failure will show the actual accessibility
hierarchy at the point of timeout.
The extension's Debug/Release configs had CURRENT_PROJECT_VERSION = 1
(untouched Xcode default) while the main app target uses
2026.0.25.0.0.1, triggering 'The CFBundleVersion of an app extension
(1) must match that of its containing parent app' on every build/test
run. Both targets now build with the same CURRENT_PROJECT_VERSION.
The cart is on-device state (CartState/SessionStateStore), not purely
server-side - it survives app relaunches on the same simulator and has
been accumulating real quantities across every manual and automated run
against the 'MARIBA' test store, with no reset in between. No one-tap
'empty cart' UI action exists; the app's only full-clear path (the
'Trocar de loja?' alert's 'Limpar carrinho e adicionar') only fires when
switching to a genuinely different store, which this suite never does.
Added CartCheckoutFlowTests.setUp() (class) to drain the cart via its
own per-item 'minus' control in a capped loop before this class's tests
run, once per class rather than once per test, so every run starts from
a known-empty cart.
See decisions/2026-09-11-ui-test-shared-login-session.md follow-up.
Previous commit's per-test logoutIfAuthenticated() in HomeGuestFlowTests
and ProfileLoggedOutFlowTests ran the guest address-picker navigation
dance (reachProfileTabRegardlessOfAuthState) twice back-to-back per test
- once in the new launch helper, once again inside reachGuestHome/
reachLoggedOutProfile - doubling exposure to that dance's known race
and regressing 5 previously-stable tests ('Login never completed' was
fixed, but new failures appeared in its place).
Moved the forced logout into override class func setUp() so it runs
once per class instead of once per test; test bodies are back to the
plain XCUIApplication()+launch() pattern.
Also fixed OrderDetailsFlowTests: 'Ver Detalhes' now matches multiple
elements once the QA account has more than one real order (previously
masked because login itself was failing first). Switched to a label
predicate + .firstMatch.
See decisions/2026-09-11-ui-test-shared-login-session.md follow-ups.
All 7 authenticated-flow XCTestCase classes logged out for real in
tearDown, forcing a real OTP round trip against the production backend
on the next authenticated test. Under CI's back-to-back suite run this
produced ~9 real logins to the same QA phone number in ~9 minutes -
the first few succeeded (~30-40s each) but every one after that failed
to complete within timeout, cascading into 'Login never completed'
across CartCheckoutFlowTests, HomeFiltersFlowTests,
OrderDetailsFlowTests, SavedCardsFlowTests, UserProfileFlowTests.
Removed the per-test logout so the QA account's Keychain-backed session
persists across the whole suite (ensureLoggedIn already no-ops when
already authenticated). Moved the 'must start logged out' guarantee to
the two classes that actually need it - HomeGuestFlowTests and
ProfileLoggedOutFlowTests now force logout themselves right after
app.launch() via a small launch helper, instead of relying on whichever
authenticated class happened to run last.
See decisions/2026-09-11-ui-test-shared-login-session.md.
Shared macOS runner accumulates orphaned simulator entries (registry
present, data dir missing on disk) which fail run_tests with 'Unable
to boot device because it cannot be located on disk'. Clean up before
every test run instead of requiring manual simctl intervention.
LCEssentials 2.0.2 replaced request(url:params:method:headers:jsonEncoding:debug:)
with request(url:method:body:pathParams:headers:debug:timeoutInterval:networkServiceType:persistConnection:).
The pre-encoded params Data is now wrapped in RawBody to preserve the same
application/json Content-Type behavior that jsonEncoding: true used to set.
- Remove bitrise.yml (no longer used, replaced by Gitea Actions on
a native macos-build:host runner - Docker VM-based macos-ctl/
macos-release runners are dead per earlier session)
- test.yml: push-triggered on any branch except develop/release/main,
runs fastlane tests (coverage) instead of raw xcodebuild
- beta.yml: PR-to-develop triggered, builds + uploads to TestFlight;
drops the dead wake/sleep-macos-vm jobs, uses the archive-API
checkout workaround (see go-gitea/gitea#21819), points at the real
ci-build.keychain-db instead of the old ci-signing.keychain-db name
- release.yml removed: release/main run nothing automated per the
agreed branch flow, promotion is manual
- Fastfile: add a tests lane (coverage) so the workflow just calls
fastlane, matching LC Wallet's convention
Running 'xcodegen generate' to register a new test file reverted every
setting that lives in project.pbxproj but is missing or stale in
project.yml. Restored the file from its known-good state and re-added only
the four PublicStoreDistanceTests.swift references by hand.
What xcodegen had destroyed:
- TargetAttributes gained DevelopmentTeam = "" on the app, the extension
and the unit tests, which blanks the Team in Xcode's Signing UI so the
provisioning profile no longer resolves.
- APP_ATTEST_ENVIRONMENT = production removed entirely.
- NSLocationWhenInUseUsageDescription replaced with the English string from
project.yml, dropping the pt-BR one shipped for App Review.
- CURRENT_PROJECT_VERSION reset from 2026.0.25.0.0.1 to 1.
Verified the file now differs from the known-good state by exactly the four
new test-file lines, and that all four items above are back.
Guest browsing showed 'Distância indisponível' on every store card and a
'--' tile on store detail, because the public locator response carries no
distance and StoreSummary.init(publicItem:) hardcoded nil.
Backend contract (docs/plans/public-store-distance-consumer.md): distance
is a number, never null, 0 means unavailable. Implemented app-side ahead of
the backend - every change is forward-compatible, and the part that removes
the broken label works with no backend at all.
- PublicStoreListItem / PublicStoreDetail: + distance (optional, so today's
responses without the field still decode).
- StoreSummary.init(publicItem:): normalize the 0 sentinel to nil, so one
representation of 'unknown' reaches the label and the max-distance filter.
- fetchStoreDetail: send state/city from GuestLocationStore by default -
the server needs them to resolve the city centroid.
- formatDistance: empty string for nil/0/negative. It previously returned
'Distância indisponível' for nil, and - found by the new test - '0 m' for
0 and '-1000 m' for a negative.
- StoreCard: drop the distance segment and its '·' separator together,
otherwise the row ended in a dangling separator.
- StoreDetailView: drop the DISTÂNCIA tile and its divider instead of '--'.
Also fixes the same label in the authenticated flow when the user declined
location and has no address coordinates.
Tests: PublicStoreDistanceTests (decode with/without the field, passthrough,
0 normalization) + the empty case in HomeViewFilteringTests.
- RegistrationView / LoginEmailView / OtpView: pushed with no nav bar, so
they showed the oversized iOS 26 system glass back button. Wrapped each
in LCENavigationView with the standard AppBackButtonIcon, matching
LoginView and every other screen. Dropped the now-dead colorScheme dark
branches and forced .preferredColorScheme(.light) (app has no dark
theme).
- ContentView: root .auth <-> .main switched with no transition. Added
.move transitions on both branches and wrapped enterAuthFlow() /
LoginView's back action in withAnimation, so opening auth from Profile's
'Entrar ou Cadastrar' now slides in and back slides out.
- ProfileLoggedOutFlowTests: new test asserting the pushed auth screens
carry the LCENavigationView back button.
I reverted project.pbxproj earlier to drop Xcode's objectVersion churn
and wiped the manual signing config with it. Restored.
- project.pbxproj: back to the LC Prov profile set (Dev/Dist for the app,
Dev/Dist Push for NotificationService), CODE_SIGN_STYLE = Manual on all
targets - byte-identical to fix/signing/notification-extension-distribution.
- project.yml: was still pointing at the old 'PediFoods Dev/Dist Prov
Prof' names and CODE_SIGN_STYLE Automatic for the extension. Synced to
the same LC Prov set so 'xcodegen generate' reproduces the signing
instead of reverting it. Verified: regenerating from this project.yml
yields the same CODE_SIGN_* / PROVISIONING_PROFILE_SPECIFIER settings.
App Review rejected the 2026-08 build: tapping checkout as a guest
switched root to .auth, which replaced the whole UI with LoginView as the
NavigationStack root - no nav bar, no back, no dismiss. User was trapped.
- LoginView: rebuilt as a static screen in LCENavigationView with a back
button that sets root = .main, a 'Criar conta' and an 'Entrar' button,
and 'Termos de Uso' / 'Politica de Privacidade' links. Added #Preview.
- Forced .preferredColorScheme(.light) and fixed DS colors (the app has
no dark theme, so system dark mode was inverting the nav bar / title).
- Removed the entry-reveal animation machinery (heroVisible/textVisible/
buttonVisible/token/prepare flags across LoginView, AuthFlowView,
ContentView) - dead since guest browsing shipped and the root cause of
the 2026-08-06 'content stuck hidden' bug.
- enterAuthFlow() is now just root = .auth.
- UITestSupport.ensureLoggedIn taps 'Entrar' (new label).
- ProfileLoggedOutFlowTests: new test covering the choices and the way
back out of .auth.
- Localizable.xcstrings: catalog caught up to the new/removed strings.
Previous fix's VStack-level .frame(maxWidth: .infinity, alignment:
.leading) fixed the width but over-applied .leading to the empty
text too. Give it its own centered frame instead, matching the
isLoading/errorMessage branches right above it.
The empty-orders branch ("Nenhum pedido encontrado.") had no
.frame(maxWidth: .infinity), unlike the loading/error branches -
ScrollView sizes to its content's intrinsic width, so the whole
container (and its background) shrank to the text's width, leaving
the real black window visible on both sides. Forces the VStack (and
ScrollView) to always fill width regardless of which branch renders.
Cascades .buttonStyle(.plain) down from each LCENavigationView
instance instead of waiting on the LCEssentials package fix
(committed separately, unpublished: LC_Essentials commit 8b0f650) to
be released and this repo's Package.resolved bumped. Overrides
iOS 26's automatic Liquid Glass chrome on LCENavigationView's
internal nav buttons - including the invisible backfilled mirror
button on whichever side has no real action - without affecting any
button that already sets its own explicit style closer to itself.
setNavigationBarBackgroundColor was never called on the 15 screens
adopted in 3456184, so it stayed at the default .clear and the real
window background (black) showed through. Set it to
AppColors.backgroundLight on all of them, matching each screen's own
actual content background. Also wraps CartView's title in
LCENavigationView for consistency with the rest of the app - no
setLeftButton since Cart is a tab root, no back button needed.
The other reported bug (empty right-button slot rendering a visible
glass circle) is fixed in LCEssentials itself (separate repo,
commit 8b0f650 on fix/navigation/liquid-glass-button-chrome) but
won't take visual effect here until that's published and this
repo's Package.resolved is bumped to point at it.
