Repository navigation
+ record why the tests cannot run on Linux - #13
Conversation
An attempt to add a Linux test leg was parked on a hard blocker and the finding was never kept: the test project depends on FrameworkExtensions.System.Drawing, which carries a FrameworkReference on Microsoft.WindowsDesktop.App.WindowsForms. That framework does not exist off Windows, so the build fails with NETSDK1073 before a test runs. Six ways round it were tried and each is recorded with what it produced -- retargeting to net8.0, multi-targeting, conditional package inclusion, NoPlatformCheck, excluding the framework reference through MSBuild, and dropping the package outright, which costs 33 compilation errors in BitmapExtensions. The workflow change that came with it is deliberately not taken: it does not work, and a CI leg that cannot pass is worse than none. What is worth keeping is the six dead ends, so the next person does not walk them again.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 85dac21927
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ## Current State | ||
|
|
||
| The test project remains at `net8.0-windows` target framework. The GitHub Actions CI workflow includes a test job, but it will **not succeed** until the Windows Forms dependency is resolved. |
There was a problem hiding this comment.
State that only the proposed Linux CI leg fails
This incorrectly reports the existing PR gate as unable to succeed. The reviewed .github/workflows/ci.yml passes the test project to the shared workflow and explicitly selects runs-on: windows-latest at lines 18–21, where the Windows Forms framework is available; the blocker applies only to a proposed Linux test leg. As written, maintainers are told that the active Windows CI job is permanently broken, so clarify that the current job runs on Windows while a Linux variant cannot run.
Useful? React with 👍 / 👎.
| This would require: | ||
| - Identifying all APIs used from the package | ||
| - Finding/creating cross-platform equivalents | ||
| - Refactoring ~30+ ditherer files |
There was a problem hiding this comment.
Recalculate the replacement scope from current sources
For anyone estimating Option 2, this describes a source layout that is not present in the reviewed tree. A repo-wide search at the parent commit finds no ditherer implementation files and only seven .Lock() call sites; the ditherers and quantizers live in the upstream dependency, while this repository consumes its registries and interfaces primarily from CLI/Options.cs and SingleImageHiColorGifConverter.cs. Consequently, replacing the package is not a refactor of “~30+ ditherer files” in this repository, and the document should inventory the actual consumed API surface instead.
Useful? React with 👍 / 👎.
A branch has been sitting unmerged since August that tried to add a Linux test leg and was parked on
a hard blocker. The attempt cannot land — but the finding is worth keeping, and it was about to be
deleted along with the branch.
The test project depends on
FrameworkExtensions.System.Drawing, which carries aFrameworkReferenceon
Microsoft.WindowsDesktop.App.WindowsForms. That framework does not exist off Windows, so thebuild fails with
NETSDK1073before a test runs.Six ways round it were tried, each recorded with what it produced: retargeting to
net8.0,multi-targeting, conditional package inclusion,
NoPlatformCheck, excluding the framework referencethrough MSBuild, and removing the package outright — which costs 33 compilation errors in
BitmapExtensions.The workflow change that came with the original branch is deliberately not taken. It does not
work, and a CI leg that cannot pass is worse than none.