Fix CI - #640
Conversation
|
@copilot Try to fix the CPP build error |
|
@Happypig375 I've opened a new pull request, #641, to work on those changes. Once the pull request is ready, I'll request review from you. |
|
@copilot It seems that AngouriMath.CPP.Exporting isn't generating native binaries to be copied over to AngouriMath.CPP.Importing in the CI. What happened? |
|
@Happypig375 I've opened a new pull request, #642, to work on those changes. Once the pull request is ready, I'll request review from you. |
|
@WhiteBlackGoose Why are some of these projects not in the solution? |
|
The C++ projects aren't really worth maintaining IMO, I don't think anybody uses those unironically. If some .net projects aren't in the solution, it's probably unintentional. At some point I stopped using VS so I didn't need the solution file any more. Feel free to add them |
|
Also I recommend using squash and merge so you get one commit per PR instead of keeping all temporary commits in main |
|
I have no idea how including more projects in the solution fixes C++ Test CI but sure I guess |
|
@WhiteBlackGoose push another preview to nuget please |
Both triggers in Benchmark.yml filtered on "./Sources/AngouriMath/AngouriMath", which is not a path in this tree. The kernel is Sources/AngouriMath/ and its project file is Sources/AngouriMath/AngouriMath.csproj; there is no nested AngouriMath directory, and the pattern has no wildcard, so it could only ever match that one literal non-existent path. The workflow last ran on 2026-01-02T14:24Z. The filter was re-added in f51c7e0 at 14:26Z -- two minutes later. The January runs happened during the #640 CI work while the filter was temporarily absent, which is why the history looks alive up to that point and then stops dead. Ninety-eight PRs have merged since without being benchmarked, so a PR could regress Simplify by any factor with CI entirely green. Two paths added beyond the kernel. A change to the benchmark harness is worth benchmarking, and so is a change to this file -- the second of those is also what lets a fix to these filters demonstrate that it fires, rather than being reasoned about, which is what the issue asks for. The leading "./" was wrong as well, path filters being globs matched against repository-root-relative paths, though it made no difference while the target did not exist either way. workflow_dispatch added so the benchmark can be run against a branch on demand, which it could not be before. The list is written out twice rather than shared through a YAML anchor: anchors are not a supported part of the workflow syntax, and a benchmark that fails to parse is worse than the one being fixed. The file parses, and Sources/Tests/DotnetBenchmark builds clean on .NET 10 with both benchmark names in Program.cs still resolving. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
No description provided.