New build tool

[jchannon]

Our current github action buids and tests for pushes and PRs and on a push it packs and pushes a package to feedz.io.

I would like a manual action that allows us to push successful builds to nuget, this should ask for a version number which tags the repo. The potential issue with that is it might kick off another build so then it gets messy.

As of .NET7 we will have Carter and Carter.ResponseNegotiators.Newtonsoft. The latter will depend on a published version of Carter not a project reference. We will potentially need a script to only build that project and run its tests. If we make changes to both projects we'll want to publish Carter first and then the Carter.ResponseNegotiators.Newtonsoft project, not sure if that can be a queued thing or whether just 2 manual steps and the latter waiting for confirmation that the first has been successful.

[mderriey]

Hey there 👋

Confirmation that I understood well

IIUC, we'd keep the current process in place, but in addition to that, we'd want the ability to "promote" some builds to be pushed to NuGet in an automated fashion but triggered manually.

In other words:

• current workflow: as PRs get merged, new builds are pushed to feedz.io.
• new workflow: when you're satisfied with a build, you want to trigger a new workflow that will push the latest version to NuGet.org. The version that'd be published would be determined by the tag you mentioned.

Questions

I would like a manual action that allows us to push successful builds to nuget

In an ideal world, we'd push the same .nupkg to feedz.io and NuGet.org; However, given the nature of NuGet packages re: versioning, I suspect we'll have to create 2 packages since their versions will differ. Technically they'll be built from the same version of the source, but they won't be the exact same binaries.

Do we agree here?

The potential issue with that is it might kick off another build so then it gets messy.

I suspect we could exclude new tags from running the "open PR / PR merged" workflow.

As of .NET7 we will have Carter and Carter.ResponseNegotiators.Newtonsoft. The latter will depend on a published version of Carter not a project reference.

I can see this in https://github.com/CarterCommunity/Carter/blob/bcb58f593aa36906f41528acfe2b00ae35883036/src/Carter.ResponseNegotiators.Newtonsoft/Carter.ResponseNegotiators.Newtonsoft.csproj.

Out of curiosity, why depend on a published version, and not on the project?

If we make changes to both projects we'll want to publish Carter first and then the Carter.ResponseNegotiators.Newtonsoft project

Does this mean that the <PackageReference> element should be updated automatically to reference the latest version of Carter?

[ritasker]

Would it be worth considering moving the public interfaces to there own SDK project, which could be pushed as a separate Nuget when carter is built. To avoid the complications with the build could the Carter.ResponseNegotiators.Newtonsoft be moved to its own repo which had a dependency on the SDK nuget? Having a SDK package would mean anyone creating extensions wouldn't have to add the whole of Carter via the nuget package or a submodule.

[jchannon]

But then if you change something in Carter which you then have to change the SDK and then the consumers it becomes a bit painful

On Thu, 22 Sep 2022 at 08:16, Richard Tasker @.***> wrote:

Would it be worth considering moving the public interfaces to there own SDK project, which could be pushed as a separate Nuget when carter is built. To avoid the complications with the build could the Carter.ResponseNegotiators.Newtonsoft be moved to its own repo which had a dependency on the SDK nuget? Having a SDK package would mean anyone creating extensions wouldn't have to add the whole of Carter via the nuget package or a submodule.

— Reply to this email directly, view it on GitHub https://github.com/CarterCommunity/Carter/issues/298#issuecomment-1254624644, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAZVJUMHJBUULTS645HVADV7QBVVANCNFSM6AAAAAAQSF7BCE . You are receiving this because you authored the thread.Message ID: @.***>

[mderriey]

@jchannon friendly bump for https://github.com/CarterCommunity/Carter/issues/298#issuecomment-1254123718

[jchannon]

Workflows - you are correct Feedz/Nuget - I think Feedz should only be CI. Nuget can be release and pre-release packages The Newtonsoft package will unlikely ever change whereas we may do releases more often with Carter If we can auto update the package reference that'd be good but we'd have to hope people don't pull the package until Carter is indexed in nuget, 10mins or so

[mderriey]

Feedz/Nuget - I think Feedz should only be CI. Nuget can be release and pre-release packages

OK, so:

1. PR run: push to Feedz
2. PR merged: push prerelease package to NuGet
3. Repo tagged: push release package to NuGet

The Newtonsoft package will unlikely ever change whereas we may do releases more often with Carter

I thought about how we could version 2 packages independently within the same repo with MinVer. Luckily, it's got us covered, see https://github.com/adamralph/minver#can-i-version-multiple-projects-in-a-single-repository-independently. TL; DR: we can have different tag prefixes for different projects, for example main- for Carter and newtonsoft- for the JSON.NET response negotiator.

If we can auto update the package reference that'd be good, but we'd have to hope people don't pull the package until Carter is indexed in nuget, 10mins or so

Maybe we can leave that for later, as a nice-to-have.

I would like a manual action that allows us to push successful builds to nuget, this should ask for a version number which tags the repo.

I thought about that again and figured that we might be able to do things the other way around. What would you think about tagging the repo from the GitHub UI, which would trigger the appropriate workflow (Carter or Newtonsoft)?

I'll play with that idea on a fork.

[mderriey]

@jchannon Feel free to close this one if you consider it done.

I'm happy to create a new issue for the "update Carter package references across multiple repos" one.