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.
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.
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.
- 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
Upload rejected with "bundle version must be higher than previously
uploaded version: 1" - agvtool new-version requires VERSIONING_SYSTEM =
apple-generic, which this project never sets, so it did nothing every
run despite reporting success. Pass CURRENT_PROJECT_VERSION directly
via xcargs instead, parameterized from the job's run number.
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.
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 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.
