Carter is framework that is a thin layer of extension methods and functionality over ASP.NET Core allowing code to be more explicit and most importantly more enjoyable.
MIT License
2.05k
stars
172
forks
source link
Publish the `CarterTemplate` package automatically #302
We want to publish the CarterTemplate NuGet package at the same time as the Carter package.
In other words, if we publish a new Carter package, let's say 7.1.2, we want to release a new CarterTemplate package with the same version.
The result can be seen in this run where we published the following packages to feedz:
Carter.6.1.2-pr.302.build.3260679089, and
CarterTemplate.6.1.2-pr.302.build.3260679089, which can create a project that depends on Carter.6.1.2-pr.302.build.3260679089
Considerations
Today, the template project references the Carter NuGet package through a <PackageReference> element.
If we want to publish a new template package, we have to:
Publish a new Carter package
Update the package reference in the template project
Create the NuGet package and publish it
There are several downsides with this approach:
When we make changes to Carter, we don't know if they affect the template project since it's pinned to a specific version. It's only when we want to publish a new version of the template package that we discover potential issues due to API changes.
Updating the package reference, creating the package and publishing it is done manually.
This PR brings some changes to this:
The template project now references the Carter project directly, so that if we make breaking API changes, they'll be picked up by the compiler. The result is that changes to the Carter code and the template code are made at the same time.
Because we can't push a package with a project reference, we swap it for a package reference by using the version computed by MinVer
We can then create the package and publish it, so we always have matching versions of Carter and the template packages.
Detailed walkthrough
There's plenty of changes in this PR, here's my attempt at documenting them.
We do this because of a chicken-and-egg problem: we need to know which version MinVer computes to inject the package reference in the template project before packing it, but as of now the version is only computed in MSBuild.
Special MinVer version for PRs
I faced an issue where several different commits in my PR resulted in the same computed MinVer versions.
It's an expected behaviour as per https://github.com/adamralph/minver/issues/225.
The Template project is not included in the VS solution, so a top-level dotnet build doesn't do anything with it.
I'm not sure whether it's intentional or not, happy to hear your thoughts.
Using PowerShell
I'm more comfortable with PowerShell than with Bash, which is why I implemented the "swap project reference with package reference" and "override MinVer version" with PS.
I have no strong feeling about this, happy for it to be in Bash, but it might be quicker for someone who knows Bash to do it.
Did you make it all the way down here? If so, thanks 🙏
mderriey
commented
1 year ago
Related to #298. Discussed in https://github.com/CarterCommunity/Carter/pull/299#issuecomment-1257956828
Goal
We want to publish the
CarterTemplateNuGet package at the same time as theCarterpackage. In other words, if we publish a newCarterpackage, let's say 7.1.2, we want to release a newCarterTemplatepackage with the same version.The result can be seen in this run where we published the following packages to feedz:
Carter.6.1.2-pr.302.build.3260679089, andCarterTemplate.6.1.2-pr.302.build.3260679089, which can create a project that depends onCarter.6.1.2-pr.302.build.3260679089Considerations
Today, the template project references the
CarterNuGet package through a<PackageReference>element. If we want to publish a new template package, we have to:There are several downsides with this approach:
This PR brings some changes to this:
Detailed walkthrough
There's plenty of changes in this PR, here's my attempt at documenting them.
MinVer version computed outside of MSBuild
We now compute the MinVer version outside of MSBuild with the MinVer CLI, see https://github.com/CarterCommunity/Carter/pull/302/files#diff-ac55abaaeaf67fb06efd5a2233f5a5f9ea20e835e7c502ff05c1bf2b952f1825R27-R31
We do this because of a chicken-and-egg problem: we need to know which version MinVer computes to inject the package reference in the template project before packing it, but as of now the version is only computed in MSBuild.
Special MinVer version for PRs
I faced an issue where several different commits in my PR resulted in the same computed MinVer versions. It's an expected behaviour as per https://github.com/adamralph/minver/issues/225.
To avoid this, we override the MinVer version with a unique prerelease tag that contains both the PR number and the GitHub Actions run id, see https://github.com/CarterCommunity/Carter/pull/302/files#diff-ac55abaaeaf67fb06efd5a2233f5a5f9ea20e835e7c502ff05c1bf2b952f1825R32-R46.
An example of this is
6.1.2-pr.302.build.562312354.Explicitly packing the
TemplateprojectSee https://github.com/CarterCommunity/Carter/pull/302/files#diff-ac55abaaeaf67fb06efd5a2233f5a5f9ea20e835e7c502ff05c1bf2b952f1825R83-R91
The
Templateproject is not included in the VS solution, so a top-leveldotnet builddoesn't do anything with it. I'm not sure whether it's intentional or not, happy to hear your thoughts.Using PowerShell
I'm more comfortable with PowerShell than with Bash, which is why I implemented the "swap project reference with package reference" and "override MinVer version" with PS. I have no strong feeling about this, happy for it to be in Bash, but it might be quicker for someone who knows Bash to do it.
Did you make it all the way down here? If so, thanks 🙏