Public Access
ADR 0014 gave the phone a nightly and ADR 0013 rule 3 gave the desktop none, so the two heads had different answers to the same question — how does somebody try what is on main? — for no reason except the order the work happened in. This is the desktop's answer: CI publishes a build from main on every push, and it installs beside the release one rather than over it. The phone gets its separation from the platform. Android refuses an update signed by a different key, so its two channels cannot replace one another whatever anybody does. Nothing refuses anything here: Velopack applies what its feed serves and verifies no signature. So all of it is construction, and there are four separations because each closes a different door. A pack id each, so the two install in different directories and neither feed's package can be applied to the other's install. A Velopack channel each — win and win-nightly — so neither build ever reads the other's release index; the name reaches the wire as releases.win-nightly.json, which is why the constant in VelopackUpdateChannel and the argument in ci.yml have to agree or the channel answers nothing forever with no error. A prerelease flag, so the release channel cannot see the nightly even by accident. And a profile directory each, which is the one that is easy to skip and would hurt most: the cache schema is migrated on every launch, before unlock, so a shared profile means a nightly quietly upgrading a database the release build then opens. Both are installed at once by design, so that is an ordinary Tuesday rather than a corner case. The prerelease flag turns out to be load-bearing across heads as well. The phone's release channel reads releases/latest, which skips prereleases — so a desktop nightly published as a stable release would become the newest release in this repository and every phone on the release channel would start failing its check against a release carrying no Android manifest. Which build this is arrives as assembly metadata, the same mechanism and the same reasoning as the Android head: the updater needs the string rather than a branch, and a value baked into the assembly is one a crash report can be asked for. Three things read it — the feed, the prerelease flag, and the profile — and one more shows it: the titlebar says DodoSSH Nightly. Everything else that distinguishes the two is somewhere nobody is looking while typing a passphrase into one of them. The version needed a floor and it is applied to the whole build rather than to the packaging. MinVer answers 0.0.0-alpha.0.N until the first v* tag and vpk refuses anything below 0.0.1, so the job lifts the patch digit and keeps the height — through MinVerVersionOverride, so the assemblies carry the same number the installer does. Packing a version the assembly disagreed with would put one string on the preferences screen and another in the feed, which is the screen somebody reads when asked which nightly they are on. Two things found by running it rather than reading it. -t:MinVer needs a restore first, because the target arrives with the package and MSB4057 on a clean checkout reads like a typo in the workflow rather than a missing restore; the release script had the same gap and now restores before it reads. And vpk rejects an empty --packVersion loudly, which is how a broken version handoff announces itself rather than shipping a package called 1.0.0. Rule 3 is untouched. The release channel still has no job, no token and no runner, and the two channels cannot see each other. What a nightly costs is written where somebody reads it before installing one: whoever can write a release here can put a build on every nightly machine, which is fine for a build being tried and is not fine for a build holding somebody's infrastructure credentials. Verified by running the job's own steps against a clone in a Linux container: DodoSSH.Desktop.Nightly-win-nightly-Setup.exe, and an index naming pack id DodoSSH.Desktop.Nightly at 0.0.1-alpha.0.144. The upload itself is the one step not exercised — it needs a real forge and a write token, and check 16.10 is what walks the half no runner can.
110 lines
5.4 KiB
C#
110 lines
5.4 KiB
C#
using Avalonia;
|
|
using Avalonia.Media;
|
|
using DodoSSH.Client.App.Platform;
|
|
using DodoSSH.Client.Session;
|
|
using Velopack;
|
|
|
|
namespace DodoSSH.Client.App;
|
|
|
|
internal static class Program
|
|
{
|
|
/// <summary>
|
|
/// Entry point.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// <c>STAThread</c> is required, not decorative: WebView2 checks the apartment state and refuses
|
|
/// to initialise on an MTA thread. Without it the terminal is simply blank on Windows. It applies to
|
|
/// everything below, which is why the Velopack call lives inside this method rather than in an entry
|
|
/// point of its own.
|
|
/// </remarks>
|
|
[STAThread]
|
|
public static void Main(string[] args)
|
|
{
|
|
// First, before Avalonia is even configured.
|
|
//
|
|
// The installer, the updater and the uninstaller all re-run this executable with arguments that
|
|
// mean "do the install bookkeeping and stop". Run() is what notices, does it, and exits — so on
|
|
// those runs nothing below happens at all, and that is the point rather than a side effect:
|
|
// DodoSshApp.Compose opens the SQLite cache and starts the terminal workspace's listening socket,
|
|
// and a silent installer run that reached either would be a background process holding the cache
|
|
// file open during the very file operations the installer is performing.
|
|
//
|
|
// There are deliberately no OnFirstRun or OnAfterUpdate hooks. A hook process has no passphrase,
|
|
// so the cache is bytes it cannot read, and the one thing that would want doing after an update —
|
|
// a schema migration — already runs on every ordinary launch from MainWindowViewModel.StartAsync,
|
|
// before unlock and touching no encrypted content.
|
|
VelopackApp.Build().Run();
|
|
|
|
KeepTheWebViewProfileOutOfTheInstallDirectory();
|
|
|
|
BuildAvaloniaApp().StartWithClassicDesktopLifetime(args);
|
|
}
|
|
|
|
/// <summary>
|
|
/// Puts WebView2's user data folder beside the vault cache instead of beside the executable.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// <para>
|
|
/// WebView2 defaults this to a directory next to the host executable. Under a Velopack install that is
|
|
/// <c>%LOCALAPPDATA%\DodoSSH.Desktop\current\</c>, and <c>current\</c> is <em>replaced</em> by every
|
|
/// update — so the browser profile would be destroyed on each one, and the first connect afterwards
|
|
/// would pay a cold WebView2 start: a new user data directory and a fresh process tree, which is the
|
|
/// slow path <c>TerminalWorkspaceOptions.RendererTimeout</c>'s fifteen seconds was sized for. It would
|
|
/// land at the exact moment somebody is most ready to believe the update broke the terminal.
|
|
/// </para>
|
|
/// <para>
|
|
/// The profile directory is the right home because Velopack never touches it — the pack id is
|
|
/// deliberately not <c>DodoSSH</c>, so the install root and <c>ClientPaths.DataDirectory</c> are
|
|
/// siblings rather than the same folder. See docs/adr/0013-desktop-distribution-and-updates.md.
|
|
/// </para>
|
|
/// <para>
|
|
/// An environment variable rather than the control's own options, because it is read by the WebView2
|
|
/// loader before any of this application's UI exists, and because it needs no reference to whichever
|
|
/// WebView package the terminal happens to be hosted by.
|
|
/// </para>
|
|
/// </remarks>
|
|
private static void KeepTheWebViewProfileOutOfTheInstallDirectory()
|
|
{
|
|
if (!OperatingSystem.IsWindows())
|
|
{
|
|
return;
|
|
}
|
|
|
|
// The same profile directory the rest of the application resolves, channel and all — a nightly
|
|
// pointing WebView2 at the release build's profile would put two browser profiles in one folder
|
|
// and hand the pair of them whichever process opened first.
|
|
var folder = Path.Combine(
|
|
ClientPaths.ForChannel(DesktopChannel.Name).DataDirectory,
|
|
"WebView2");
|
|
|
|
try
|
|
{
|
|
Directory.CreateDirectory(folder);
|
|
|
|
Environment.SetEnvironmentVariable("WEBVIEW2_USER_DATA_FOLDER", folder);
|
|
}
|
|
catch (Exception exception) when (exception is IOException or UnauthorizedAccessException)
|
|
{
|
|
// Left unset, which puts the profile back beside the executable. That is a slow first connect
|
|
// after each update, not a broken terminal, and refusing to start an SSH client over it would
|
|
// be the wrong trade.
|
|
}
|
|
}
|
|
|
|
/// <summary>Used by the designer as well as by <see cref="Main"/>.</summary>
|
|
/// <remarks>
|
|
/// <c>WithInterFont</c> registers Inter; it does not make it the default, and until this line the
|
|
/// application shipped a font it then declined to use — falling back to Segoe UI on Windows and to
|
|
/// whatever fontconfig offered on Linux. Almost nothing visible moves, because App.axaml sets
|
|
/// <c>MonoFont</c> on essentially every control that draws text, but the fallback behind those is now
|
|
/// a font that travels with the build rather than one the machine is assumed to have. The layout
|
|
/// suite pins the same family, and has to: see HeadlessApp.
|
|
/// </remarks>
|
|
public static AppBuilder BuildAvaloniaApp() =>
|
|
AppBuilder.Configure<DodoSshApp>()
|
|
.UsePlatformDetect()
|
|
.WithInterFont()
|
|
.With(new FontManagerOptions { DefaultFamilyName = "avares://Avalonia.Fonts.Inter/Assets#Inter" })
|
|
.LogToTrace();
|
|
}
|