a43286ece8a82313f295a959ea2524ea84b408fb
15
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  jaap-janandClaude Opus 5
|
ffab2be22a |
Drop the formatting step, which spent minutes agreeing with the build
`dotnet format --verify-no-changes` re-analysed the whole solution before the build did, to reach a verdict the build reaches on its own: IDE0055 is an error in .editorconfig, EnforceCodeStyleInBuild is on and warnings are errors, so a misformatted file fails the build step. What the separate step bought was hearing about it a few minutes earlier, and it charged those minutes on every run. Checked rather than assumed, because the whole justification rests on it: appending a badly-spaced member to a source file produces three `error IDE0055` lines and a failed build with no format step in sight. Three places said the old arrangement out loud and would now be wrong on their own — the comment on the IDE0055 line, the conventions list in the README, and a note in platform-flags telling people to run dotnet format before pushing or CI would fail them. They say the build enforces it now. dotnet format is still how to fix what the build complains about; it just no longer gates anything. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
jaap-janandClaude Opus 5
|
08a820adcf |
Stop the login step interpolating a comment I wrote in it
The secrets were never the problem. The log shows both arriving masked, which is what a runner does with a value it holds — so the repository secrets were configured correctly the whole time, and the guidance about Actions Variables was wrong. What broke was the guard added to diagnose them. Its comment contained an expression delimiter written out literally to explain what an unset secret renders as, and a shell comment is not a comment yet at that point: the runner substitutes the whole script before any shell sees it, so it tried to evaluate an empty expression and failed the step with a parse error carrying no line number. The step never ran, and push then reached the registry with nothing to authenticate as — "no basic auth credentials", which looks precisely like the missing-secret problem the guard was added to rule out. The comment now describes the delimiter instead of containing one, and warns the next person, since the failure is invisible to review and to every local check: the file is valid YAML and the script is valid shell. Verified with a scan for empty expressions across every run block in the file — one before, none after — and by running the step's script with credentials set, which passes the guard and gets a 401 from the real registry. That is the right answer for an invented password, and it means the endpoint is reachable and the path through this step is sound. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
jaap-janandClaude Opus 5
|
2bc0d4d89f |
Say which credential is missing instead of letting docker guess
The registry secrets are reportedly not arriving, and the job could not have told anybody
which one or why. An unset secret is not an error anywhere upstream: ${{ }} renders a
missing value as an empty string, so docker gets --username "" and replies with something
about credentials — which reads as the registry rejecting a login rather than as a value
that never left the settings page.
Checked before use now, and reported by length rather than by value. Gitea masks known
secret values in logs, but a mask is only as good as the runner's bookkeeping, and a length
answers the only question actually being asked: did anything arrive at all. The message
names the page to look at, and names the neighbouring one too, since Actions Variables and
Actions Secrets sit next to each other and only one of them is readable through the secrets
context.
This does not fix the credentials. It converts a confusing failure into a specific one, so
the next run distinguishes "the secret is empty here" from "the registry refused these" —
two problems with nothing in common that currently look identical.
Verified by running the step's script with both variables set empty, which is the reported
symptom: it names both, points at the settings page and exits 1 before docker is called.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
jaap-janandClaude Opus 5
|
a515a35804 |
Build the image with BuildKit rather than the builder Docker is retiring
"DEPRECATED: The legacy builder is deprecated and will be removed in a future release." Not a failure — the image was built and the job carried on — but a countdown, and one the last commit walked straight into: Alpine's docker-cli package does not carry buildx, so giving the job a working client left it building the old way. Two packages instead of one now. With the plugin present `docker build` routes through BuildKit on its own, which also stops the Dockerfile's independent stages being serialised, so this is slightly faster as well as not deprecated. buildx is wanted rather than required, and the difference is deliberate. Missing it costs a warning and a slower build; the image is still correct. So each install branch ends in `|| true` and the check afterwards reports instead of exiting — a distribution with no package for it should not be able to turn a release into a red build over a plugin. The comment above the build step said this job needed "no buildx plugin", which was true when the build was the only thing being weighed and is not true now. It says what is actually wanted, and what is still not: no QEMU, no builder instance to create and tear down, no third-party action to re-pin. Verified in Alpine containers with the socket mounted, in all three states this can be in: nothing installed, the client present and buildx missing — which is exactly what produced the warning — and buildx unavailable with no package manager to fix it, which warns and exits 0. The API image builds through BuildKit with no deprecation notice. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
jaap-janandClaude Opus 5
|
5ddbca49d3 |
Give the image job a docker client to go with the daemon it already had
Exit 127, `docker: command not found`, from the build step of the image job. The daemon was never the problem and never missing: Testcontainers speaks to /var/run/docker.sock from a .NET library, so every integration suite in the build job had been starting PostgreSQL, Keycloak and an sshd on this runner while `docker` was not a command on it at all. Having a socket and having a client are two different things to have, and this runner had one. It failed late for the same reason it was easy to miss. Node, git, the SDK and the tags all came up fine, so the job looked healthy right until the line that actually needed the binary. The client only. There is a daemon answering on that socket already — installing an engine would start a second one beside the one in use, which is a worse outcome than the error. Verified by running this step's own script in an Alpine container with the socket mounted: it installs docker-cli, the client then reports server 29.6.2 across the socket, and the API image builds to completion from inside that container with the repository as its context. Which is as close to the runner as this can be checked without being it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
jaap-janandClaude Opus 5
|
208aca1191 |
Make a failing test run say what went wrong
Two suites fail on the runner and pass everywhere else, and every attempt to work out why has been an inference from a filename. The runner prints the path of a log written to a disk nobody has a shell on, and the log is where the exception type, the message and the stack all live — so a red build has been a guess, and the last guess was wrong: 69 layout failures looked like missing fonts and were a missing shared library instead. This prints the log, and three facts about the machine that no log will ever carry: which distribution it is and who the job runs as, whether docker answers, and — the one that matters for the layout suite — ldd against the libSkiaSharp.so the test project carries, filtered to its unresolved rows. A managed TypeInitializationException on SKImageInfo is a symptom several missing libraries share; ldd names the library. The fontconfig step ahead of this exits early when ldconfig already reports one, so if that is present and Skia still will not load, the answer is a different dependency and this is what says which. head rather than tail on the log, which is the whole trick. A suite that fails wholesale writes one stack per test and they are the same stack; the first explains it and the last two hundred lines are that sentence repeated. if: failure() and exit 0, so it runs only on a red build and reports without becoming a second failure on top of the first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
jaap-janandClaude Opus 5
|
43d76d0f2d |
Let the suite run on Linux, and fix the three things that stopped it
The pipeline finally reached the tests and found four failures. None was the pipeline's, and only one of the four was a test being fussy about a platform rather than telling the truth about one. The local pane's roots bar was the real bug. LocalDirectory.Roots built it from DriveInfo.GetDrives on every platform, and its own summary — "the drives on Windows, and the root elsewhere" — had been describing an intention rather than the code for as long as nobody ran it off Windows. On Unix that call answers with every mount the kernel holds: /proc, /sys/fs/bpf, one per installed snap, /run/user/1000/doc, some forty on an ordinary laptop. The transfers screen draws a button per root, so the bar ran to about five thousand pixels inside an eight-hundred pixel window. Anybody running the Linux build has been looking at that. Filtering GetDrives is not the fix and the comment now says why at length, because it is the obvious thing to try: DriveType answers Fixed for / and /home and equally for every squashfs snap, for efivarfs and for tracefs, while /boot/efi comes back Removable, and DriveFormat would need a hand-kept list of every virtual filesystem Linux might grow. So Unix now names what somebody would want instead of subtracting what they would not — the root, their home, and whatever is mounted under /run/media/<user>, /media, /mnt or /Volumes. Anything else is still reachable by navigating from /, which is what the pane is for. Windows is untouched. ClientPathsTests looked for "odoSSH" in the profile directory. ClientPaths spells it DodoSSH on Windows and dodossh on Unix deliberately, one per platform convention, and that substring was clever enough to survive either spelling of the leading D while still only ever matching one of them. Now OrdinalIgnoreCase. WhyTheWindowItselfIsNeverShown asserted a COMException with HResult RPC_E_CHANGED_MODE, which is WebView2 refusing an MTA thread — a Win32 component raising a COM error. On Linux the adapter is a different implementation with no apartment to disagree about, so showing the window works and Should.Throw catches nothing. Skipped there rather than loosened to accept both outcomes: the assertion is the documentation in that test, and one that passed everywhere would have stopped recording the constraint it exists to record. The fourth was CI's alone, and the diagnosis is the useful part. All 69 layout tests failed on the runner while 6 failed here, which looked like missing fonts and was not: Avalonia's headless renderer is Skia, libSkiaSharp.so links against libfontconfig, and without it the suite dies in HeadlessUnitTestSession with a TypeInitializationException on SKImageInfo naming none of its actual subjects. The job installs the one library now. Verified in a container where fc-list returns zero and the suite passes regardless, because the application carries Inter itself — fonts were never the problem, only the thing that would have looked for them. The whole solution now passes on Linux: 19 suites, 1295 tests, 0 failures, 4 skipped, the end-to-end Testcontainers suite included. README and platform-flags.md said testing was Windows-only, which CI now contradicts on every push, so both say what is true instead and the two findings are written down where the next person will look for them. macOS is still untested and now says so on its own rather than hiding inside "not Windows". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
jaap-janandClaude Opus 5
|
a6af93148b |
Give the runner a node before asking it to run an action
Every job died on its first line: "Cannot find: node in PATH", from actions/checkout. act_runner executes each `uses:` action with node inside the job container, and the image this runner is configured with has none — so nothing in the pipeline had run yet, including the tests the image job gates on. A `run:` step is shell rather than node, so one placed ahead of the first action can fix the job it is in. It installs via apt-get, apk or dnf, whichever is there, and says plainly what to do when none of them is. git goes in alongside, named in the step rather than smuggled into it: checkout shells out to git the moment node has loaded it, so an image thin enough to lack one usually lacks the other, and finding that out separately costs another round trip through CI. The version is warned about, not enforced. Distributions pin nodejs to whatever shipped with the release — Ubuntu 24.04 still serves 18, past end of life and older than these actions declare — but act_runner hands an action whichever node is on PATH regardless of what it asked for, and it generally works. A warning is the right weight for something that explains a later inexplicable failure without being one. Repeated verbatim in all three jobs. It cannot be a local composite action, since that needs the checkout it exists to unblock, and YAML anchors that would deduplicate it are rejected by GitHub's parser. Byte-identical across the three so a diff shows drift. This is still a workaround. The fix is one line of the runner's own config.yaml pointing container.image at an image that ships node, as Gitea's default catthehacker/ubuntu:act-latest does; the step then costs a version check and nothing else. Kept regardless, because a pipeline that silently depends on a runner being configured correctly elsewhere fails confusingly when it is not. Verified by running the step's own script in ubuntu:24.04 and alpine:3.20, which have neither, and node:20-bookworm, which has both: installs where needed, no-ops where not, and warns only on the node 18 that Ubuntu gives. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
jaap-janandClaude Opus 5
|
8a568117df |
Give the API an image, and unbreak the restore that had to run first
registry-docker.dodotech.cloud/dodotech/dodossh-api, built and pushed by a third ci job
that needs the first. Gating on the tests costs a few minutes on every main commit and buys
the only thing worth having here: an image is not an artefact somebody inspects before
using it, so a red commit must not be able to produce one. Pull requests build the image
and stop, which is where a broken Dockerfile should be found.
Tags are :sha-<short> on every build, :main on main, and for a v* tag :1.2.3, :1.2 and
:latest — the last two only when the version has no prerelease suffix, since v1.3.0-rc1
sorts above v1.2.9 and would otherwise walk :latest onto somebody's server. Only sha- is
immutable, and it is the one to pin a deployment to.
No docker/* actions. The build is single-architecture, so it needs the daemon this runner
already has for the Testcontainers suites and nothing else — no buildx, no QEMU, and no
third-party action whose SHA has to be audited and re-pinned. Step outputs and secrets
reach the shell through env rather than ${{ }} interpolation, because a git tag may contain
a semicolon and interpolation is textual substitution performed before the shell parses the
line.
The image is chiseled: no shell, no package manager, uid 1654. Affordable because
Directory.Build.props already sets InvariantGlobalization, so the ICU and tzdata a normal
base carries are exactly what this product decided not to use. The cost is stated in the
Dockerfile rather than hidden — there is no HEALTHCHECK, because there is nothing to run
one with, and /healthz/ready is anonymous precisely so the orchestrator can ask instead.
Nothing migrates the schema from inside the container either; readiness fails while a
migration is pending and names it, which is the design.
And the restore that all of this depends on did not work.
|
||
|
jaap-jan
|
81e7e6d939 |
Write down what the phone found, and stop it rotting
docs/android-port.md was an audit of work not started; it now says what is built. Three of its statements needed correcting rather than extending, and they are marked where they sit: the Android version question is settled and was never as open as it looked, because Avalonia.Controls.WebView ships only a net10.0-android36.0 assembly and nothing lower can resolve it; cleartext to loopback has to be permitted explicitly, which the audit missed entirely; and the spike produced a structural change it did not anticipate, in DodoSSH.Client.Shell. A CI job of its own, because the head is deliberately not in DodoSSH.slnx and a project outside the solution is a project nobody notices breaking. It packages as well as builds: a native library with no Android ABI and an assembly that will not dex are both invisible to a compile, and both are exactly what this head is exposed to. The README says plainly that signing in is not built, that a fingerprint re-enrolment destroys the device key, that a notification appears while a shell is open, and that none of it has run on a device. |
||
|
jaap-jan
|
66271faaae |
Update .github/workflows/ci.yml
ci / build and test (push) Failing after 16s
|
||
|
jaap-jan
|
9c3edb078e |
Update .github/workflows/ci.yml
ci / build and test (push) Canceled after 0s
|
||
|
jaap-jan
|
f0002b683c |
Update .github/workflows/ci.yml
ci / build and test (push) Canceled after 0s
|
||
|
jaap-jan
|
34304b989b |
Make the end-to-end suite self-contained with Testcontainers
It needed a hand-started stack and an opt-in flag, so it ran on one machine and never in CI. It now brings up PostgreSQL, Keycloak and an OpenSSH server itself, applies the committed migrations and starts the API as a child process, which makes it part of the ordinary test run at ~25s. The API runs as a process rather than through WebApplicationFactory. The client builds its own HttpClient for a URL the user typed, so there is no seam to hand a test handler through without inventing one that exists only for tests — and a test host would replace the entry point, Kestrel and the content root, so it would never prove that Program.cs composes or that the committed appsettings is found and layered in the documented order. Running out of the API's own output directory is what makes its configuration real. The suite still consumes what ships: the realm file from deploy/keycloak, the EF migrations, the API's own appsettings. Only Oidc:Authority is overridden, because the container's port is assigned at start. Falsified by reintroducing the wildcard-port redirect URI the realm once had — Keycloak rejects the authorization request and the suite fails at sign-in, which is what proves the committed file is the one imported. Skipping the migration step likewise fails, and the failure names the pending migration. A fresh Keycloak per run also sidesteps the --import-realm trap: editing the realm file and rerunning now always tests the edit. DodoDbContextFactory gains a Create(connectionString) so the fixture and dotnet ef place the migrations history table in exactly one place. If they disagreed the API would report every migration pending, which is how the readiness gate catches it. |
||
|
jaap-jan
|
3a81f3c90b |
Restructure into src/tests and add build foundation (M0)
Moves the scaffold to src/DodoSSH.Api and establishes the repo conventions the rest
of the milestones build on.
Structure:
- src/{Contracts,Crypto,Domain,Infrastructure,Api}, tests/{Contracts,Crypto,Domain}.Tests
- DodoSSH.slnx rewritten with src/ and tests/ solution folders
Build:
- Directory.Build.props centralises TFM, nullable, deterministic builds and
TreatWarningsAsErrors; Directory.Packages.props pins every version centrally
- packages.lock.json committed so CI restores in locked mode
- NuGet.config clears machine-level sources, which both fixes NU1507 under central
package management and makes restore reproducible off this machine
- Microsoft.OpenApi pinned to 2.11.0: ASP.NET Core 10.0.10 resolves 2.0.0, which is
covered by GHSA-v5pm-xwqc-g5wc (high, patched in 2.7.5)
Analyzers:
- AnalysisLevel is Recommended, not All. With warnings-as-errors, All turns opinionated
naming rules into build breaks and trains people to blanket-suppress.
- BannedSymbols.txt bans DateTime.UtcNow (TimeProvider), Guid.NewGuid (CreateVersion7),
sync-over-async, MD5/SHA1, PBKDF2 and SecureString
- CA1711/CA1724 disabled: both are .NET Framework CAS-era naming rules
- PublicApiAnalyzers on Contracts only, since that assembly is the client's real contract
API:
- weather-forecast template removed
- UseHttpsRedirection removed; TLS terminates at the reverse proxy and redirecting
behind one causes loops
- /healthz/{live,ready,startup}. Liveness deliberately checks no dependencies so a
transient database outage cannot restart the container and kill live SSH sessions.
Notes:
- No coverage collector yet. Microsoft.Testing.Extensions.CodeCoverage pulls an MTP 1.x
MSBuild extension that throws TypeLoadException against the MTP 2.3.x xunit.v3 brings.
Coverage gates are an M3 concern; revisit with an MTP 2.x-aligned version then.
Verified: dotnet build (0 warnings), 17 tests pass, format check clean, API serves
health and OpenAPI endpoints.
|