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.
- 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
