Conversation
Package looks good, expect this is still 5.1.x
|
There was a problem hiding this comment.
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
b1f48e4 to
184ab9d
Compare
- Rename workflow - Split artifact upload into packages and docs
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 |
are there any (code) changes between 5.2.1 and 5.2? Otherwise I suggest to re-define the 5.2 tag |
| bundler-cache: true | ||
|
|
||
| - name: Build package and docs | ||
| run: dotnet run --project 'build/build.fsproj' -- -t All |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
You can't do ContinuousIntegrationBuild locally and those settings are needed for deterministic packages/source link. Therefore the check on CI
There was a problem hiding this comment.
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))
There was a problem hiding this comment.
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.
| with: | ||
| dotnet-version: | | ||
| 6.0.x | ||
| 7.0.x |
There was a problem hiding this comment.
You can remove .NET 7 sdk from this list
There was a problem hiding this comment.
.NET 7 is still used here.
Removing this is a breaking change I guess
There was a problem hiding this comment.
no, we don't need to run test for packing. we use for tests another pipeline
There was a problem hiding this comment.
Current targets have test as dependency so will still run. Can do this if we switch to dotnet pack
There was a problem hiding this comment.
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
|
@alexandrnikitin @zvirja : do either of you have time to take a quick look at this? 🙇 |
|
🥳 |
Added a release build on tag.
Example: https://github.com/dtchepak/NSubstitute/actions/runs/8864632563 (with minor tweak to build-on-push for testing).