Closed jnm2 closed 4 years ago
Yeah I've thought about putting it in for all 3 of my NuGet repositories. I'm unfortunately going on vacation the next two weeks so it would be September before I get to it at the earliest.
Great! I'm submitting PRs and stuff but as far as I know there's no need to get any of this done soon, so please enjoy your vacation first!
@buvinghausen I'm interested in setting up Azure Pipelines build. It would look something like https://github.com/buvinghausen/TaskTupleAwaiter/pull/12/files#diff-fec826feae04e51c0d94076385408bdc.
Here's the (more complex) build I set up for NUnit: https://nunit.visualstudio.com/NUnit/_build/results?buildId=1299
If you like the idea, I need your help. I can't set up the webhooks between Azure Pipelines and GitHub since I'm not added as a repo owner.
Can you email me your email address (my address is in https://github.com/jnm2) so that I can add you as an admin at the https://dev.azure.com/AsyncBridge Azure DevOps organization?
Once you're an admin at https://dev.azure.com/AsyncBridge, can I either show you how to set up the build definition, or can you make me a repo owner long enough to set it up myself?
If both are outside your comfort zone, we can stick with AppVeyor. 👍
@buvinghausen We're also having issues with the AppVeyor build. The commits in master that built so far all have failures, and on top of that there is a new failure for #16 because it adds a second .sln file to the repo.
There's no appveyor.yml and my GitHub account doesn't have permission to do anything with https://ci.appveyor.com/project/buvinghausen/tasktupleawaiter. What do you think, should we disable AppVeyor and set up Azure Pipelines? Or do you want to get AppVeyor working again instead of Pipelines? I'll need your help either way.
@jnm2 I just set it all up via GitHub actions now all you have to do is create a release and tag it correctly and it will get pushed up to NuGet for you including the symbols.
You have two failing tests ConfigureAwaitTrueUsesSynchronizationContext & NonConfiguredAwaitUsesSynchronizationContext they both only fail on .NET Core App 3.0 and 3.1 but work on 2.x and lower.
Great! GitHub actions is awesome, isn't it?
I'll work on the test failures next. Since .NET Core 3.0 and 2.0 are not supported by Microsoft, do you see any reason to continue running tests on those versions? 2.1 and 3.1 are the only versions currently supported. Also, should we test against .NET 5 preview 7? It would require you to install the preview 7 SDK in order to open the solution.
Yeah it's definitely nice to have everything all rolled up into the UI here and easy to monitor.
As far as the test executions I'm fine whittling it down to just the supported platforms I was just running it against everything because we could... As far as .NET 5 goes I was just going to wait until it was released to add it but if you're feeling up to it feel free to take a stab at it.
I think this takes care of everything except the AppVeyor issue: https://github.com/buvinghausen/TaskTupleAwaiter/pull/18
I just deleted the appveyor project entirely...
Cool, I guess that wraps things up. Thanks for getting CI set up!
Np sorry it took me so long to get around to haha. Side note you may want to make sure you can generate an NuGet API key and then replace the nuget_api_token secret with your key and make sure the publish step chains off the release with your key. That way you can still do a release when/if my key gets stale.
Let me know if you do it and run into any issues.
@buvinghausen, what do you think about adding an AppVeyor run to check PRs? It would consist (more or less) of files like these:
https://github.com/OmerMor/AsyncBridge/blob/master/appveyor.yml https://github.com/OmerMor/AsyncBridge/blob/master/build.cake
The above example is extra-complicated because it's uploading test coverage analysis to codecov.io for nice in-PR displays like
https://github.com/OmerMor/AsyncBridge/pull/15#issuecomment-384284278
with a link to coverage diff browsing like https://codecov.io/gh/OmerMor/AsyncBridge/pull/15/diff. We could do that here too, or just the minimum necessary to be up and running with AppVeyor.