Repository navigation
Tags: dAppCore/build
Tags
fix(wails3): drive the stack with the wails3 CLI, not a Taskfile targ… …et (#82) Task (taskfile.dev) is its own build orchestrator and no part of Wails. Threading a Taskfile target name through this action put another project's tool in the Wails stack's vocabulary, and made the caller name an internal detail — `darwin:package` — that Wails already has a verb for. The premise in the old description was wrong: "there is no `wails build` invocation to compose". There is. `wails3 build` and `wails3 package` are both real, and internally they route through the project's own build description with GOOS passed in, so the CLI already does the dispatch this action was reaching past it to do by hand. The input is now `wails3-command`, taking `build` or `package` and nothing else — an unknown verb fails here, naming the caller, rather than reaching wails3 as a subcommand it does not have. That also drops the step installing the Task binary: wails3 runs the build through its own embedded runner, so nothing here needs task on PATH. The contract check gains the case that let this ship broken. A composite action referencing ${{ inputs.X }} it does not itself declare gets the empty string, silently — and the forwarding check could not see it, because it only asks whether a name a file declares is passed on. Forwarding an input the file never declared satisfies it while passing nothing, which is how the previous attempt at this repaired one hop of the chain, reported sound, and stayed severed at the next.
fix(wails3): drive the stack with the wails3 CLI, not a Taskfile targ… …et (#82) Task (taskfile.dev) is its own build orchestrator and no part of Wails. Threading a Taskfile target name through this action put another project's tool in the Wails stack's vocabulary, and made the caller name an internal detail — `darwin:package` — that Wails already has a verb for. The premise in the old description was wrong: "there is no `wails build` invocation to compose". There is. `wails3 build` and `wails3 package` are both real, and internally they route through the project's own build description with GOOS passed in, so the CLI already does the dispatch this action was reaching past it to do by hand. The input is now `wails3-command`, taking `build` or `package` and nothing else — an unknown verb fails here, naming the caller, rather than reaching wails3 as a subcommand it does not have. That also drops the step installing the Task binary: wails3 runs the build through its own embedded runner, so nothing here needs task on PATH. The contract check gains the case that let this ship broken. A composite action referencing ${{ inputs.X }} it does not itself declare gets the empty string, silently — and the forwarding check could not see it, because it only asks whether a name a file declares is passed on. Forwarding an input the file never declared satisfies it while passing nothing, which is how the previous attempt at this repaired one hop of the chain, reported sound, and stayed severed at the next.
fix(wails3): forward `task`, and report inputs no caller can reach (#81) The v3 stack runs the project's own Taskfile target rather than composing a command, so which target runs is the entire configuration. The root action never declared `task` and the orchestrator never forwarded it, so every v3 build ran <os>:build no matter what the caller asked for — and a caller that asked got no error, because Actions ignores a `with:` key the action does not declare. lthn/desktop asked for darwin:package, got darwin:build, and its next step failed on a bundle that was never created. macOS and Windows both went red; the release published nothing. The asymmetry report could not have caught it. It compares a callee's callers against each other, so an input *no* caller wires reads as unanimous agreement rather than as a dead option — and that is the worse case, because the option is documented on the callee and unreachable through the caller. Those are now their own section: 79 of them across the repo, most deliberate (a wrapper choosing not to expose a knob), and the counter is in the default output so the number moving is visible.
fix(wails3): forward `task`, and report inputs no caller can reach (#81) The v3 stack runs the project's own Taskfile target rather than composing a command, so which target runs is the entire configuration. The root action never declared `task` and the orchestrator never forwarded it, so every v3 build ran <os>:build no matter what the caller asked for — and a caller that asked got no error, because Actions ignores a `with:` key the action does not declare. lthn/desktop asked for darwin:package, got darwin:build, and its next step failed on a bundle that was never created. macOS and Windows both went red; the release published nothing. The asymmetry report could not have caught it. It compares a callee's callers against each other, so an input *no* caller wires reads as unanimous agreement rather than as a dead option — and that is the worse case, because the option is documented on the callee and unreachable through the caller. Those are now their own section: 79 of them across the repo, most deliberate (a wrapper choosing not to expose a knob), and the counter is in the default output so the number moving is visible.
v4.14.0 — the Deno stack can produce a .deb deb, deb-maintainer and deb-description reached the root action, the orchestrator and the Go stack, but the Deno stack never declared them, so a Deno caller setting deb: true got a green build and no .deb. The contract check now also records which callers of a callee wire an input and which do not, behind --asymmetries.
fix(deno): let the Deno stack produce a .deb (#80) `deb`, `deb-maintainer` and `deb-description` reach the root action and the orchestrator, and the Go stack declares them and hands them to package. The Deno stack never declared them, so the chain dead-ended there: a Deno caller could set `deb: true`, watch the build go green and get no .deb. dAppCore/ts asked for one and never got one. The contract check added alongside the passthrough fixes could not catch this. It looks for an input both a caller and its callee declare, and not declaring an input is precisely how a stack says it does not offer that option — so an input that was never declared reads the same as one deliberately withheld. So the check now also records, for each callee input, which callers wire it and which do not, behind `--asymmetries`. Most of what it lists is correct (wails3 does not take wails2's options), which is why it is opt-in and never fails: on every run it would only teach people to skip the output. It is the tool for wiring a new stack, or for working out why an option appears to do nothing.
v4.13.0 — forward the inputs the callees actually consume Seven inputs were declared on a caller, consumed by its callee, and never joined up. entry never reached the danet adapter, so every Danet build compiled run.ts regardless of what was asked for; build-tags never reached wails2; test never reached cpp; and notarize, dmg, sign-sparkle and the two macOS app fields never reached sign. The contract tests now check for the whole class.
fix(actions): forward the inputs the callees actually consume (#79) * fix(actions): forward the inputs the callees actually consume Seven inputs were declared on a caller, consumed by its callee, and never joined up between the two. A caller could set them and watch nothing happen — the manifest validates, the job goes green, and the option is simply ignored. entry deno stack -> danet adapter (pinned every Danet build to run.ts) build-tags orchestrator -> wails2 test orchestrator -> cpp notarize wails2 -> sign dmg wails2 -> sign sign-sparkle wails2 -> sign sign-macos-app-email, sign-macos-app-team-id wails2 -> sign Two of them needed more than a wire. The danet adapter defaults `entry` to run.ts, and an empty value overrides a default rather than falling back to it, so the convention is named at the call site. And `test` means two different things at the two ends — a tri-state Go policy above, a plain ctest gate below — so forwarding `auto` verbatim would have read as not-'true' and switched ctest off for every C++ build; the tri-state is mapped rather than passed. The contract tests now check for this whole class: an input both sides declare and the caller does not forward. That is what found the other six. Co-Authored-By: Virgil <virgil@lethean.io> * fix(ci): build the wails2 self-test for the runner's own architecture The job asked an amd64 runner to compile linux/arm64. Wails v2 on Linux is cgo against webkit2gtk, so that hands arm64 assembly to the x86 assembler: gcc_arm64.S:30: Error: no such instruction: `stp x29,x30,[sp,' It has failed on every run since it was added, which is why this workflow has no green run in its history. Cross-compiling it properly would need an arm64 toolchain and arm64 webkit headers, and would then be testing the cross-toolchain rather than the action. Co-Authored-By: Virgil <virgil@lethean.io>
feat(deno): pass entry and permissions through the root action (#78) The deno stack accepts both, but neither reached it from dAppCore/build@v4, so anything needing more than the default --allow-net --allow-read --allow-env had to call the stack directly. permissions is the one that matters. A compiled server that writes config or spawns a process fails at runtime under the default, and the failure comes from inside the binary rather than from the build. entry is usually unnecessary — the build step probes run.ts, main.ts, mod.ts, src/main.ts and app.ts — but a project outside that set had no way to say so through the root action. All 35 action manifests pass the contract check.
PreviousNext