Fix Mac App Store publish hanging forever on build processing
The Mac App Store release job hung indefinitely on "Publish to App Store",
spinning until Actions' 6h default killed the (10x-billed) macOS runner:
Waiting for App Store Connect to finish processing the new build
(3.7.0 - 24) for MAC_OS
Root cause: the release lane ran upload_to_testflight with the build-processing
wait enabled. That wait lives in FastlaneCore::BuildWatcher, which polls each
build's processingState until it reads complete. For macOS builds the App Store
Connect API never reliably reports processingState as VALID, so it polls
forever even though the upload succeeded and the build is usable. iOS is
unaffected because its processingState does flip. deliver's select_build only
avoids the same hang when handed an explicit build number (direct lookup); a
nil/"latest" number routes it back into BuildWatcher.
- Fastfile (mac): skip_waiting_for_build_processing on the upload, and always
submit by an explicitly resolved build number so deliver takes the
direct-lookup path and never re-enters BuildWatcher. Widen the submit retry
budget for the release flow. iOS keeps its working wait-based flow.
- Workflows: add timeout-minutes: 120 to both App Store jobs as a hard cost
backstop, and a desktop_submit dispatch lane on the Mac workflow (mirrors
iOS) to submit an already-uploaded build without a rebuild.
- Add an Announce Release workflow plus a shared discord-release-message.sh
script, so a release's Discord message can be posted for a given tag when the
automated notify job was skipped (e.g. a cancelled run). notify now builds
its message from the same script, so the two can't drift.
The repository moved from github.com/Wavesonics/hammer-editor to
github.com/Darkrock-Studios/hammer-editor. Update all URLs across
source, build scripts, web templates, docs, store metadata, and
test fixtures.
deliver exits 1 even though App Store Connect's eventually-consistent
build relationship accepts the submission, so the release job went red
while the build shipped. After a deliver error, verify the real version
state and treat an already-submitted version (with the intended build
attached) as success. Add an ios_submit-only workflow path to re-submit
without a rebuild.
The dry run served its purpose (verified the pipeline and surfaced the
two-cert signing bug, now fixed in publish-mac-app-store.yml). Drop the
dry-run workflow and its desktop_build_only lane; keep only the fix.
* ci: add Mac App Store dry-run lane and workflow
Adds a way to exercise the Mac App Store build/sign/package pipeline
without releasing anything to App Store Connect.
- fastlane: new `mac desktop_build_only` lane builds, signs, and verifies
the .pkg (via build-appstore.sh) but skips the App Store Connect build
number lookup and the upload — no API key needed.
- workflow: new "Dry Run — Mac App Store" (workflow_dispatch) mirrors the
real publish workflow's keychain + provisioning-profile setup, runs the
build-only lane, and saves the .pkg as an artifact instead of uploading.
Verified locally: lane builds + passes codesign/pkgutil checks.
* ci: temporarily trigger mac dry-run on push to its branch
workflow_dispatch requires the workflow to exist on the default branch
before it can be dispatched. Add a branch-scoped push trigger so the dry
run can be exercised now; remove before merging.
* ci: import Mac signing certs from two separate p12 files
macOS `security import` only ingests one identity from a combined
multi-key .p12 (which one wins is non-deterministic), so a single secret
holding both the Application and Installer certs left one of them missing
from the CI keychain — caught by the dry run, which failed with "Mac
Installer Distribution certificate not found".
Import the Application and Installer certs from their own single-identity
.p12 files instead. Adds a second secret, MAC_INSTALLER_CERT_P12_BASE64.
Applied to both the dry-run and the real publish-mac-app-store workflows.
* ci: drop temporary push trigger from mac dry-run workflow
The dry run was triggered via a branch-scoped push trigger because
workflow_dispatch only works once the workflow exists on the default
branch. Now that it's merging to develop, revert to workflow_dispatch
only.
Replace ad-hoc icon scripts with a single source-of-truth manifest
(scripts/assets.yaml) and a Python generator that renders every app icon,
store-listing graphic, MSIX tile, favicon, and the Play feature graphic from
two SVG sources. Compositions (icon + "Hammer" wordmark in Kingthings
Trypewriter) are defined once as percentages of canvas and reused across the
Play feature graphic, MSIX wide/splash tiles, and the Snap featured banner.
Adds the missing snap store icon, fixes the snap desktop icon to the correct
256x256 hicolor size, and routes uploads-only assets to build/store-assets/
(gitignored).
See docs/ASSET-GENERATION.md for the manifest schema.
Mirror the Mac setup with an :ios platform block exposing ios_testflight
and ios_release lanes, plus a publish-ios-app-store job in the release
workflow. Both lanes reuse the existing App Store Connect API key (the
.p8 isn't platform-specific). The CI job installs the provisioning
profile to both Xcode 16's path and the legacy Fastlane location for
compatibility.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Wire up two Mac lanes (desktop_testflight, desktop_release) alongside the
existing Android setup, and a publish-mac-app-store job in the release
workflow so each new release uploads a sandboxed .pkg to TestFlight on a
macos-latest runner. The lane respects BUILD_NUMBER from env (CI sets it
to github.run_number) and falls back to TestFlight + 1 locally.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
