mirror of
https://github.com/stablyai/orca.git
synced 2026-09-25 08:02:31 +00:00
* feat(updater): add an adhoc release channel for branch builds Hourly covers main. This covers everything that is not main yet: a dispatchable macOS build of an unlanded branch, published to stablyai/orca-adhoc, so the team can run an experimental feature for a few days instead of reasoning about it from a diff. Adhoc sits at the bottom of the version order — 'adhoc' < 'hourly' < 'rc' < stable — so no routine check can walk anyone onto somebody's branch; only an explicit pinned jump reaches one. It gets its own repo rather than sharing orca-hourly's, because a branch build must not appear in the list a developer riding main is looking at. Signed and notarized exactly like hourly, for the same reason: macOS anchors a notarized app's TCC grants on identifier + team, so an unnotarized build reads as a new client and silently loses file access under Documents/Desktop/Downloads. Tags stamp to the second rather than the minute. Hourly runs under a concurrency group and cannot overlap itself; adhoc builds are dispatched on demand, so two people cutting from different branches inside one minute is ordinary — and a minute-resolution tag would collide and fail the second build after its whole pack-and-notarize run. Channel-specific behaviour now derives from one DEDICATED_REPO_CHANNELS list: repo mapping, macOS-only support, and UpdateSource. The RPC schema that validates releaseChannelOverride was a hand-copied enum missing the new channel, which would have rejected the override on its way to the main process; it reads the predicate now. * fix(updater): merge the duplicated shared/types import Co-authored-by: Orca <help@stably.ai> * fix(ci): default the adhoc build ref to the dispatch branch The Actions UI puts its own "Use workflow from" branch picker directly above the ref field, and picking a branch there is what most people read as "build this". Making the field optional means the obvious action is also the correct one; naming a branch explicitly still wins, so main's copy of the workflow runs rather than a stale one on an old branch. Co-authored-by: Orca <help@stably.ai> --------- Co-authored-by: Orca <help@stably.ai>
31 lines
1.2 KiB
JavaScript
31 lines
1.2 KiB
JavaScript
const RELEASE_NAME_TIME_ZONE = 'America/Los_Angeles'
|
|
|
|
/**
|
|
* `07-31 13:54` — the timestamp segment of a dev build's release title, shown
|
|
* verbatim in both the GitHub releases list and the in-app build picker.
|
|
*
|
|
* Why Pacific while the tag's own stamp stays UTC: that stamp is a sort key, and
|
|
* a local one would repeat an hour at every DST fall-back, making two distinct
|
|
* builds compare equal. A title is only ever read, so it uses the timezone the
|
|
* people reading it are in. The two therefore disagree by the current offset.
|
|
*/
|
|
export function formatReleaseTitleTimestamp(date) {
|
|
if (!(date instanceof Date) || Number.isNaN(date.getTime())) {
|
|
throw new Error('Release title timestamp is invalid.')
|
|
}
|
|
const parts = Object.fromEntries(
|
|
new Intl.DateTimeFormat('en-US', {
|
|
timeZone: RELEASE_NAME_TIME_ZONE,
|
|
month: '2-digit',
|
|
day: '2-digit',
|
|
hour: '2-digit',
|
|
minute: '2-digit',
|
|
// Why h23 rather than hour12: false: some ICU builds render midnight as 24.
|
|
hourCycle: 'h23'
|
|
})
|
|
.formatToParts(date)
|
|
.map((part) => [part.type, part.value])
|
|
)
|
|
return `${parts.month}-${parts.day} ${parts.hour}:${parts.minute}`
|
|
}
|