ci(): use GitHub actions instead of appveyor & travis

[smolck]

ATM only have the publish workflow ported (next is the testing workflow to replace travis), which should publish to GitHub packages when run, although I need to test it (on my fork). And assuming we don't care about publishing to NuGet and GH packages, then no more dealing with the nuget API key expiring every year, so that's nice.

Some questions on this, I'm assuming we want to run the tests before doing the publishing, right? And when do we want to trigger the workflow? ATM I just have it set to run when triggered manually, but that should be able to be set up to run on pushing a version tag.

[justinmk]

Some questions on this, I'm assuming we want to run the tests before doing the publishing, right?

yes

And when do we want to trigger the workflow? ATM I just have it set to run when triggered manually, but that should be able to be set up to run on pushing a version tag.

Manual is fine for now. Let's just be sure to document the "release steps" similar to here. That makes the surface-area visible, and then we decide whether it makes sense to ever automate these steps.

Explicit is usually better, at least to start with. Implicit triggers like publish-on-tag can be surprising.

[smolck]

Okay, this is ready for review; added the test workflow, the tests are run before the publishing part of the publish workflow, and got the publish workflow to publish a package finally after some trial and error.

Only thing left I guess is documentation on how to publish a package, which is pretty easy, just update the version file in src/NvimClient.API/NvimClient.API.csproj and run the workflow.

I can put the above (formatted in steps) at the bottom of the README, sound good? (Note that the last step is obviously only available for maintainers; I guess that could also be in the README maybe with the steps? not 100% sure . . .)

Also, I'll make a follow-up PR after this swapping out the CI status badges for the new GH actions ones (unless there's a way to do that without merging this first?).

[justinmk]

Only thing left I guess is documentation on how to publish a package, which is pretty easy, just update the version file in src/NvimClient.API/NvimClient.API.csproj and run the workflow.

I can put the above (formatted in steps) at the bottom of the README, sound good?

yes

(Note that the last step is obviously only available for maintainers; I guess that could also be in the README maybe with the steps? not 100% sure . . .)

only maintainers can "release" anyway. Don't need to mention it.

[justinmk]

any idea why --store-password-in-clear-text is needed?

[smolck]

Not 100% sure, but it's the command they say to use here: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-nuget-registry#authenticating-with-github_token-in-github-actions

[justinmk]

the old script ran the generator, do we (plan to) have that in the GHA workflow?

even if it doesn't auto-create a PR or something, it's useful to exercise it I think?

[smolck]

I wondered about this; my thought for leaving it out is this way the file in the published package is the same as the one in the repo, so there aren't any unexpected discrepancies between the two.

Then we can just add another workflow that does update the API and create a PR if we want to automate that.

[smolck]

Before I merge, thoughts on #14 (comment) ?

Also, just a note, once this is merged I'll wait to publish the package until I add the documentation for the public members it's giving warnings about (see here), so that the docs are in the release.