This is a hack to make it easier for our GitHub branching rules to
require a single check to pass before merging. This lets us describe the
required checks in code rather than via the GH UI.
The auto-update prompt isn't useful for local (source) builds. Disable
it by default by setting Sparkle's SUEnableAutomaticChecks Info.plist
key to NO (false) for all build configurations.
We then selectively re-enable it by deleting that Info.plist key from
our release workflows. We delete the key instead of setting its value to
YES (true) to give us Sparkle's default behavior of prompting the user
to enable update checks on the second application launch. (YES tells
Sparkle to skip that prompt and silently enable update checks.)
See also: https://sparkle-project.org/documentation/customization/
(This is a safer alternative to #3273.)
Fixes: #3179
Continuing from #3043 I agree that it seems idiomatic to have an archive
with format <name>-<version>.tar.gz and matching prefix for packaging,
RPM and Debian packaging guides seem to assume this format and the
automated extract tooling assumes it too.
# Testing
I haven't tested running this workflow, and am unsure about the yaml
substitution at lines 105-106
# Breaking changes
This would break existing packaging scripts, not sure how we want to
version it
The auto-update prompt isn't useful for local (source) builds. Disable
it by default by setting Sparkle's SUEnableAutomaticChecks Info.plist
key to NO (false) for all build configurations.
We then selectively re-enable it by deleting that Info.plist key from
our release workflows. We delete the key instead of setting its value to
YES (true) to give us Sparkle's default behavior of prompting the user
to enable update checks on the second application launch. (YES tells
Sparkle to skip that prompt and silently enable update checks.)
See also: https://sparkle-project.org/documentation/customization/
We've used a zip for the duration of the private beta but macOS users
expect a dmg. This commit changes both of our release workflows to begin
building a dmg instead of a zip.
Ghostty now has a release channel build configuration. Current valid
values are "tip" and "stable" but I imagine more will be added in the
future.
The release channel is inferred whether the version we specify with the
`-Dversion-string` build flag has a prerelease tag or not. If it does,
the release channel is "tip". If it doesn't, the release channel is
"stable".
This also adds a configuration to specify the release channel for
auto-updates for the macOS application.
This adds a new workflow for building and releasing _tagged versions_
of Ghostty. The workflow is triggered automatically by new tags in the
format of `vX.Y.Z` but can also be manually triggered by running the
workflow from the GitHub Actions UI.
Release artifacts are uploaded to a completely separate R2 bucket
with its own access policy, retention, API keys, and so on.
There is currently no way to switch between "channels" in the macOS
app. I will follow up with a separate commit to add this feature.
This enables the compile options and Xcode configuration so that logging
in Metal shaders shows up in our Xcode debug console. This doesn't add
any log messages, but makes it so that when we iterate on the shaders in
the future, we can add and see logs to help us out.
