Skip to content

Implement Central Package Management - #6

Merged
CharliePoole merged 3 commits into
mainfrom
issue-5
Aug 15, 2026
Merged

Implement Central Package Management#6
CharliePoole merged 3 commits into
mainfrom
issue-5

Conversation

@CharliePoole

Copy link
Copy Markdown
Member

Fixes #5

@CharliePoole
CharliePoole force-pushed the issue-5 branch 4 times, most recently from 4c46912 to 15d6834 Compare August 13, 2026 16:47
@CharliePoole

CharliePoole commented Aug 13, 2026

Copy link
Copy Markdown
Member Author

@manfred-brands Some notes for reviewing this PR...

  1. This is the first engine-related repo using central package management and the workflow will serve as a model for all the others.
  2. This turned out to be more complicated than I would have thought. Locally, it worked easily, but I got lots of failures in CI before I hit on the solution... i.e. using the cake-action and listing packages beforehand.
  3. It relies on beta.4.8 recipe changes, i.e. the last commit in NUnit.Cake.Recipe, in case you need to look there. I've been maintaining this manually rather than through CI. (That will change soon)

@devlead Can you suggest any alternatives to my workaround using dotnet list package?

@manfred-brands manfred-brands left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't tell what you mean by it not building with the the dotnet list package command as I don't see failed builds where you don't have this.

One change request to ensure dotnet cake and cake-action will use the same version of cake.

- name: 🔨 Build, Test, Package and Publish (Cake script decides)
run: dotnet cake --target=ContinuousIntegration --configuration=Release #--verbosity=diagnostic
#run: dotnet cake --target=ContinuousIntegration --configuration=Release #--verbosity=diagnostic
uses: cake-build/cake-action@v3

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switch to cake-action from dotnet-cake could result in differences between CI and local builds as they could use different versions of cake.
You can fix that by adding:

cake-version: tool-manifest

This should pick the version out of the .config/dotnet-tools.json

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. It's currently working the same because we are using the latest version but that may not always be the case.

uses: cake-build/cake-action@v3
with:
target: ContinuousIntegration
configuration: Release

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't find this in cake-action/README
The example shown uses:

   arguments: |
        name: value
        configuration: Release

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. However, I'm dropping use of cake-action anyway.

run: dotnet tool restore

# For reasons I don't understand, the Cake script doesn't work in a workflow
# unless they are restored before the script runs, which this command does.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you elaborate on what packages are not restored?
Does it work when you call dotnet cake but not with the cake-action?

If cake's add-ins are not restoring, Gemini suggest to the below to the cake-action step:

env:
      # Directs Cake/NuGet to cache packages properly in the runner workspace
      NUGET_PACKAGES: ${{ github.workspace }}/.nuget/packages

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had the same failures using dotnet cake directly as with cake-action. I added the extra step after switching to cake-action so I'll retry with dotnet cake plus the extra step since that's much simpler.

We're using two addins, Cake.Git and Cake.MinVer, but neither of them seems to be causing a problem. I can try that, however.

@CharliePoole

Copy link
Copy Markdown
Member Author

Sorry... I prematurely deleted the failing workflow runs. Here's one that I re-created: https://github.com/nunit/nunit.engine.api/actions/runs/31771447194/workflow

You can see that none of my feeds listed for central package management are used and virtually none of my dependencies are found.

@CharliePoole

CharliePoole commented Aug 14, 2026

Copy link
Copy Markdown
Member Author

Next steps...

If I can make it work by going back to direct use of dotnet cake I'll do that. I'd prefer to have it run exactly the same way in CI as on the desktop. UPDATE: This works, so I'm going that way.

If I have to use cake-action I'll add the cake-version argument as you suggest.

I'll give you a chance to look at the failing run and see if you come up with any ideas.

FWIW, there's lots of chatter online that suggests GitHub workflows don't fully support central package management.

@manfred-brands

Copy link
Copy Markdown
Member

FWIW, there's lots of chatter online that suggests GitHub workflows don't fully support central package management.

We use it for most of our repositories and never had a problem, but we are not using cake but just plain dotnet build

@manfred-brands

Copy link
Copy Markdown
Member

I'll give you a chance to look at the failing run and see if you come up with any ideas.

I have one, in your NUnit.Cake.Recipe BuildTasks.cake you explicitly set the NuGetRestoreSettings sources.
Instead of setting sources, I think you need to reference the NUnit.Config file using the ConfigFile property.

The build log passes a single source to Nuget:

Executing task: Restore
Executing: "D:/a/nunit.engine.api/nunit.engine.api/tools/NuGet.CommandLine.7.0.1/tools/NuGet.exe" restore "D:/a/nunit.engine.api/nunit.engine.api/NUnit.Engine.Api.slnx" -Source "https://www.nuget.org/api/v2;https://www.myget.org/F/nunit/api/v2" -NonInteractive

I also think that instead of using the NuGetRestore task (which calls nuget.exe) you mitght want to update to DotNetRestore which calls dotnet restore

@CharliePoole

Copy link
Copy Markdown
Member Author

I think you're right... It may be better, in fact, to try to get rid of all calls calls to the NuGetXxxxx methods as well as direct calls to MSBuild. I'll work on it tomorrow...

@CharliePoole

Copy link
Copy Markdown
Member Author

@manfred-brands Good call!

Switching to DotNetRestore did the job as you can see in build #84. For that test I overwrote the operation of the Restore target in build.cake using one of the extensibility methods. I'll do a few more experiments with some other calls and then create a new version of the recipe that doesn't need to be overwritten.

@CharliePoole
CharliePoole merged commit dd0c79e into main Aug 15, 2026
3 checks passed
@CharliePoole
CharliePoole deleted the issue-5 branch August 15, 2026 09:08
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.

Use Central Package Management in build

2 participants