Skip to content

fix: Remove stray brace breaking CI workflow YAML#8

Merged
Cellcote merged 9 commits into
masterfrom
t3code/9f594549
May 15, 2026
Merged

fix: Remove stray brace breaking CI workflow YAML#8
Cellcote merged 9 commits into
masterfrom
t3code/9f594549

Conversation

@Cellcote
Copy link
Copy Markdown
Owner

Summary

  • The CI workflow had a stray } on runs-on: ubuntu-latest}, making .github/workflows/ci.yaml invalid YAML
  • As a result, GitHub failed to parse the workflow and CI never ran on PRs
  • Removing the } restores the workflow so it triggers on every PR

Test plan

  • Confirm GitHub no longer reports a workflow parse error on this branch
  • Note: this PR itself may not get a CI run, since the base branch (master) still contains the broken workflow. Subsequent PRs opened after merge should trigger CI normally.
  • Optionally: add a branch protection rule on master requiring the "Build" check before merge.

🤖 Generated with Claude Code

Cellcote and others added 5 commits May 15, 2026 18:36
The trailing `}` on `runs-on: ubuntu-latest}` made the workflow file
invalid, preventing CI from running on PRs.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CI restore was failing with NU1902/NU1903/NU1904 audit errors. Bumped
direct NuGet.* references from 6.0.0 to 6.12.1 (fixes GHSA-6qmf-mmc7-6c2p,
GHSA-g3q9-xf95-8hp5, GHSA-68w7-72jg-6qpp) and added direct PackageReference
overrides for vulnerable transitives:

- Microsoft.Build.Tasks.Core -> 17.11.4 (GHSA-h4j7-5rxr-p4wc)
- System.Drawing.Common -> 8.0.10 (GHSA-rxg9-xrhp-64gj)
- System.Security.Cryptography.Xml -> 8.0.2 (GHSA-vh55-786g-wjwj)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Initial bump still hit fresh advisories on the picked versions. Updated to
versions verified clean on NuGet.org:

- Microsoft.Build.Tasks.Core 17.11.4 -> 17.14.28
- NuGet.Frameworks/ProjectModel/Versioning 6.12.1 -> 6.14.3
- System.Security.Cryptography.Xml 8.0.2 -> 9.0.16

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
NuGet 6.14.x marks the parameterless `NuGetFrameworkFullComparer()`
constructor as obsolete and adds nullable annotations to
`FrameworkReducer.GetNearest`. Switch to `.Instance` and throw when no
compatible framework is found.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
.editorconfig sets `insert_final_newline = false`. The file was added
on master with a trailing newline that fails StyleCop SA1518 under
build.cake's `TreatAllWarningsAs.Error`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Buildalyzer sometimes returns an IAnalyzerResult with a null
TargetFramework (intermediate design-time builds). NuGet 6.0.0 silently
returned the unsupported framework when given null, but 6.14.x throws
`ArgumentNullException`. Skip null/whitespace candidates before parsing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Cellcote and others added 3 commits May 15, 2026 19:03
csproj `<ProjectReference Include="..\Foo\Foo.csproj"/>` paths use
Windows-style backslashes. On Linux/macOS `Path.GetFileName` does not
treat `\` as a path separator and returns the whole string, so the
dependency graph never matched these references. As a result Bar appeared
as a leaf alongside Foo, sorted alphabetically first, and Foo ended up
nested under Bar instead of analyzed at the top level — breaking the
solution/slnx verified expectations on Linux CI.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
slnx files store project paths with Windows-style backslashes (e.g.
`Foo\Foo.csproj`). On Linux those weren't normalized before being joined
to the solution directory, so projects ended up with names like
`Bar\Bar`, and cache lookups against the csproj-normalized
`Foo.csproj` filename missed — re-analyzing each leaf under its
dependents.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The expectation was stale on two counts:
1. It still reflected slnx-declaration order instead of the topological
   order introduced later.
2. It was missing the `Packages that can be removed from FSharp` section
   that's produced now that FSharp.fsproj is in the slnx fixture and
   participates in the analysis.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@Cellcote Cellcote merged commit abdfc37 into master May 15, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant