Release build workflow

[dtchepak]

Added a release build on tag.

Example: https://github.com/dtchepak/NSubstitute/actions/runs/8864632563 (with minor tweak to build-on-push for testing).

[304NotModified]

Example: https://github.com/dtchepak/NSubstitute/actions/runs/8864632563 (with minor tweak to build-on-push for testing).

Package looks good, expect this is still 5.1.x

[304NotModified]

LGTM, needs only the NuGet push and correct version number.

If you like to test that, you could do that by pushing to https://int.nugettest.org/ AFAIK

[304NotModified]

Maybe the name "Package and documentation" would describe this flow better.

(could be also Packages and documentation)

[dtchepak]

Renamed to "Build release packages and documentation".

[dtchepak]

Example: https://github.com/dtchepak/NSubstitute/actions/runs/8864632563 (with minor tweak to build-on-push for testing).

Package looks good, expect this is still 5.1.x

Oh nice catch! Just double-checked the code and I think it's all good, it's just I hadn't pushed the 5.2 tag to my fork (so it used the previous 5.1 tag).

Have made the suggested changes. Sample: https://github.com/dtchepak/NSubstitute/actions/runs/8877342178

Once it's merged i'll push 5.2.1 and release that.

[304NotModified]

Once it's merged i'll push 5.2.1 and release that.

are there any (code) changes between 5.2.1 and 5.2? Otherwise I suggest to re-define the 5.2 tag

[Romfos]

I propose to use dotnet pack for packaging instead of custom tool and use tool only for documentation

- name: Pack
  run: dotnet pack -c Release -p:Version=${{ inputs.Version }} -o "bin/Release/NSubstitute" NSubstitute\NSubstitute.csproj

- name: Validate and build documentation
  run: dotnet run build/build.fsproj -- -t Documentation

[Romfos]

also as I see we have following fragment in csproj

  <PropertyGroup Condition="'$(CI)' == 'True'">
    <!--Deterministic Build and Source Link settings -->
    <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
    <EmbedUntrackedSources>true</EmbedUntrackedSources>
    <IncludeSymbols>true</IncludeSymbols>
    <SymbolPackageFormat>snupkg</SymbolPackageFormat>
  </PropertyGroup>

maybe also make sense to add /p:CI=True or remove this condition from PropertyGroup (probably better to remove)
but I'm not an expert in snupkg and don't know how it works

[304NotModified]

You can't do ContinuousIntegrationBuild locally and those settings are needed for deterministic packages/source link. Therefore the check on CI

[dtchepak]

I don't disagree with this, but do you have an outline of the pros and cons of switching?

The current FAKE-based build sorts out our versioning so I don't think it's as straightforward as switching directly (given constraint that I'd like to make version based on repo contents rather than an input).

Maybe can defer until larger build changes are done? (as per #797 (comment))

[Romfos]

Yes, 100% it could be changed later.

My private opinion:
dotent cli is a default way to interact with .NET projects like build\restore\pack\publish. From my point of view, make sense to use default approach for default problems. Just no need to reinvent the wheel. Fake and fsharp is just additional complexity.

[Romfos]

You can remove .NET 7 sdk from this list

[304NotModified]

.NET 7 is still used here.

NSubstitute/tests/NSubstitute.Acceptance.Specs/NSubstitute.Acceptance.Specs.csproj

Line 4 in 19b38fd

<TargetFrameworks>net8.0;net7.0;net6.0;net462</TargetFrameworks>

Removing this is a breaking change I guess

[Romfos]

no, we don't need to run test for packing. we use for tests another pipeline

[304NotModified]

Good one :)

[dtchepak]

Current targets have test as dependency so will still run. Can do this if we switch to dotnet pack

[304NotModified]

Current targets have test as dependency so will still run. Can do this if we switch to dotnet pack

Maybe that's indeed better, but IMO is not that important. I don't mind the .NET 7 here

[dtchepak]

@alexandrnikitin @zvirja : do either of you have time to take a quick look at this? 🙇