Improving CI

[sebastienros]

I'd like to help with migrating the CI to GH actions. That would make things easier to maintain: updated VMs, version management, people can contribute, and tests would run faster. (Just saw you couldn't even use a newer C#).

If you agree I would need some requirements, like what tests to run on every build (not all projects pass right now). What assets to publish, what scripts to run.

I personally like to have a script for PRs, one for the main branch, and one for deployment. I trigger the deployment on release tags (when creating a release on GH it triggers the pipeline and published to NuGet).

Example: https://github.com/sebastienros/fluid/tree/main/.github/workflows

[dadhi]

@sebastienros Hi, thanks for the help!

I need to think a bit about that.
Because at the end, I need to fully understand the new CI workflow myself to manage it efficiently and fix if needed.

For now, a couple of things about the current CI setup:

Yes, I know that the current AppVeyor is late to update non-Windows images with latest .NET. There is LatestSupportedNet MSBuild property to control the .NET versions.

Regarding the tests. FEC does not use Test runners. Instead, there are 2 CLI apps FastExpressionCompiler.TestRunner and FastExpressionCompiler.TestRunner.Net472. The test methods are called as normal methods, and Program.cs contains calls to all of them for both FEC and FEC.LightExpression.

It was done to gain full control over what is called and how, avoid exceptions breaking down the NUnit TestRunner with no message or a stack trace, and it helps me with Debugging the tests selectively from any IDE. Normally. I am working in VSCode.
Btw, Rider often breaks in the FEC debugging session with obscure internal exceptions not related to the FEC itself.

Regarding the performance - it is as good as it can be because there is no TestRunner runtime involved. I think the latest MS Testing platform promises similar implementation. But for now I am in control.
To run all tests, I call b.bat or bt.bat (for the latest NET only). Here is how fast it is on my old XPS 15 i9-8950HK:

[sebastienros]

Thanks. Here is how the workflow looks like for master branch builds and PRs (same workflow). It runs in both ubuntu and windows, net472 only on windows. Uses your two runners.

https://github.com/sebastienros/FastExpressionCompiler/actions/runs/12383227725

This workflow could already be merged and appveyor would still work such that you can build some confidence into it. No pressure though if you don't like it.

I created the publish workflow too but it's failing right now, will spend more time another day, you can still check it too. I believe it would be nice to refactor the projects/nuspecs to make it easier to maintain, too many pieces IMO, for instance everything should be a csproj, no need for nuspec files and include a nuget.exe because of that. Also with a Directory.Build.props for the ".src" packages to centralize the common settings. Right now the publish workflow would just store the packages as artifacts to be able to see what is generated and evaluate the final solution. Again you don't have to be ok with that in the end if that looks more complicated from your perspective, because it shouldn't be.

[dadhi]

@sebastienros Thank you for the work!
I will review it and get back to you.

[jogibear9988]

I also use the gh release publish workflow. I like it, cause you have a direct connection whats published to nuget
I converted most of my projects from appveyor to gh actions. Beleave me, its easier and faster.

[dadhi]

@sebastienros Hi, If you're still on it, please open the PR with the GH Actions.
I would accept unfinished publishing as well, and will fix it when I have time.
Let the AppVeyor and GHA coexist, and when it's time, I will sunset whatever is more shore to support.
Thank you.

[sebastienros]

Will do. I also spent some time on the nuspecs but it went nowhere so will try the more direct approach of just converting to workflows and skip the improvements for later. I was hoping it would be easy to use csprojs for source-only packages but I was wrong.