Replace AppVeyor with GitHub Actions & NuGet.org Trusted Publishing

[304NotModified]

I know I've been mentioning it for years, but it would be great to finally replace AppVeyor with GitHub Actions especially with the new NuGet.org Trusted Publishing.

Originally posted by @jonorossi in #736

Related #497

[304NotModified]

I know I've been mentioning it for years, but it would be great to finally replace AppVeyor with GitHub Actions especially with the new NuGet.org Trusted Publishing.

I've implemented NuGet.org Trusted Publishing recently, that's super easy. I also recently moved (with one package) from appveyor to github actions, needed for Trusted Publishing, that is more difficult (Assembly/package versions etc).

But I could help with that migration of course :) I only need some info on the choices made on appveyor and the process flow of publishing (and maybe also the wishes).

[stakx]

See also #700.

[304NotModified]

@jonorossi could you please setup the trusted publishing for ‎.github/workflows/release.yml‎? See #700. It's super easy in the NuGet site. (Environment could be left empty, owner castleproject). Feel free to contact me if there are any questions. :)

Steps:

1. URL: https://www.nuget.org/account/trustedpublishing

2. Create:

3. Settings:

[304NotModified]

@stakx, @zvirja, @Romfos my proposal:

1. reboot Drop AppVeyor in favor of GitHub Actions #700 - it looks great!
2. I could do a review in depth of the package of that PR
3. setup trusted publishing
4. pre-release 6.0 to nuget.org
5. double check the results in nuget.org

and it's fixed forever!

[stakx]

@jonorossi, as far as I know, you are currently the only one holding all the proverbial keys to the various systems required to set up CI and package publishing. Seeing that you haven't been able to participate here regularly for the past one or two years due to other commitments, may I suggest that at least one more person be given access as well? In particular:

• AppVeyor so the extant CI pipeline there can be stopped & retired once it's no longer needed;
• NuGet in order to renew the API key (which appears to be a todo now recurring yearly);
• GitHub project settings in order to configure secrets & actions.

Given that I am currently the only other active Castle team member apart from yourself, I'm willing to take on (or rather share) the responsibility of managing the above systems... but of course it doesn't have to be me if someone more suitable is available. As long as there's at least someone else so you can take turns when the need arises.

[stakx]

@304NotModified, I like your proposal. I only have one request: let's please not do the CI transition for the 6.0.0 release, but right afterwards instead. I've invested literally weeks of effort into those new features and I would be so happy to see them released without further delay, so they can start being useful to the .NET community.

[304NotModified]

We could also say, if this isn't fixed in 2 weeks, we use the old publishing. :)

Or is there a high priority bugfix in 6.0?

[stakx]

We could also say, if this isn't fixed in 2 weeks, we use the old publishing. :)

Sounds reasonable!

Or is there a high priority bugfix in 6.0?

No, not directly. There's however two other points to be made, I think:

• 6.0.0 does quite a bit of catching up with newer C# language features, while DynamicProxy 5 can barely keep up with C# 7. The longer we wait, the more DynamicProxy (and the mocking libraries built on top of it) loses practical relevancy. (But perhaps that is inevitable anyway, given newer approaches such as Roslyn source generator-based approaches?)

• There's also the question of Castle project members' availability. It's currently down to just Jono and me. This project is in maintenance mode most of the year; I usually take some time for it during the cold months but once the weather gets warmer, I prefer to spend my spare time outdoors. Spring is coming... so perhaps we are a little pressed for time.

[304NotModified]

OK #740 is ready! I'm taking advantage of the momentum :)

I also added some screenshots/steps to #739 (comment)

All tested on my fork (exact same commit!), see the PR for the test results. @Romfos did a great job.

of course I could not verify the last steps, but it the same setup as my own project - see comment in the PR on that file.