Move build from AppVeyor to GH Actions

[tmenier]

Not an absolute necessity, but having heard only good things about Actions I'm thinking getting everything under the GH umbrella might be a good idea, and 4.0 might be the right time to do it. Adding some automation to the publishing process could be part of this too, or a 2nd phase. But replacing the current AppVeyor build would be a good start.

I welcome help if anyone has experience with this. @kroniak @gitfool Let me know if you have thoughts on this.

Maybe helpful:
https://dusted.codes/github-actions-for-dotnet-core-nuget-packages
https://dev.to/petrsvihlik/lessons-learned-migrating-from-appveyor-to-github-actions-1gh8

[tmenier]

I think this should also determine the fate of #459. I'm no longer convinced that switching to xUnit is worth the effort, and if there's no tangible benefit to it on the build server, I might just close it as a won't-fix.

[gitfool]

I love github actions but came to use it after using many other "pipelines" over the years, so I settled on using cake build a while ago, which works for "local" builds and makes it reasonably portable across such systems. I'm not saying you should use it, just pointing out more options.

Re switching to xUnit, that's entirely independent of the build server. What benefits were you looking for? (I love xUnit, but it's very subjective and it's not perfect to me either, so I bolt on fluent assertions.)

[SeanKilleen]

@tmenier Hi! I'm the lead of the NUnit docs. 👋 Happened to stumble across this.

Just wanted to confirm that the need to move from NUnit --> xUnit should be independent of build server. Pretty confident we could get it to work in any situation and get you over your hurdles. NUnit tests can run on GitHub actions just fine and I'd be happy to help you if you're hitting any snags. Let me know if you saw anything anywhere that seemed to run contrary to this.

With all that said, I'm pro whatever-helps-maintainers and I love xUnit too, so if you need some help porting, I'd be happy to look into it.

[SeanKilleen]

It's not immediately evident what the exact actions are that AppVeyor performs for you. It looks like:

• You run a windows build agent, based on the definition
• You run your build cmd file, which it seems:
  • Builds the Flurl.CodeGen proj in release mode
  • Builds the Flurl.Http project in release mode
• You run your test cmd file, which it seems:
  • Runs the dotnet test command with appropriate options
• Adds *.nupkg to the artifact output.
• Does something with version numbers (unclear based on the appveyor file alone)

Does this project require a windows build agent? E.g. are you doing anything in the build that specifically needs windows?

Otherwise, I think you could likely have a GitHub Action that:

• Runs on ubuntu-latest
• Has build steps that run the build & tests
• Outputs the artifact to GitHub artifacts
• Does something additional TBD depending on version number

If you can clear up a few of those points, I'd be happy to see if i can get this the rest of the way!

I'll create a PR that tries to do the basic GitHub actions. Once that's submitted, you'll likely need to click to allow it to run GitHub actions in that PR, which GitHub does for safety reasons.

[tmenier]

@SeanKilleen Thanks! Crazy timing, just this week I got myself fully up to speed on GH Actions at my day job and have been planning Flurl workflows in the back of my head. I'd like to automate more of the lifecycle process but this is a great start and I'm happy to collaborate with you on it. It might not be until Friday that I'll get all my thoughts fleshed out, but I'll put them here and we can go from there. Thanks again!

[tmenier]

@SeanKilleen I think what you've done is great. I don't see a need for CI/CD actions to be any fancier than this. My release process, on the other hand, is where I want to get fancier. But I think that's a different workflow/different issue entirely. And before even starting that I want to take a fresh look at the process itself and see if it could use any improvements:

#710

@kroniak @gitfool @SeanKilleen I'd be grateful for feedback/insights from any or all of you on #710. Consider it a rough/tentative plan that I'm open to changing or further refining. Thanks!

[tmenier]

@SeanKilleen Thanks again for the helpful start on this. I added my own bits to the process and I think I hit a balance of automated and manual steps that feels about right. Just wanted to share:

1. Push to dev or PR to dev or master triggers a build/test cycle. (The fate of dev is still a little up in the air but I figure I can always change that later.)
2. Push to master (almost always a PR merge) also triggers build/test, and if it detects a version bump, a draft release (Flurl and/or Flurl.Http) is created, pre-populated with tag, generated release notes, etc.
3. I can manually make any tweaks to release notes and click publish when ready.
4. On publish, the package is pushed to nuget.org.

I've used it exactly once but it feels right so far. :)

Thanks again!

[SeanKilleen]

@tmenier very kind of you to follow up! Anything that helps you feel like you can ship as quickly as you want to without sacrificing confidence or enduring headaches is a win in my book. :)

If you ever want to tweak or discuss any aspect of delivery, ping me anytime! I don't mind being nerd-sniped for great OSS projects.