-
Notifications
You must be signed in to change notification settings - Fork 483
Drop AppVeyor in favor of GitHub Actions #700
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Maybe someone know - what is "Castle.Core.Tests.WeakNamed"? What is the purpose of that? cc @stakx |
|
Sorry, I currently don't have sufficient capacity to look into migrating away from Appveyor if I also want to look at actually improving DynamicProxy. I'd rather spend some of my time there at the moment. Getting rid of Appveyor will be a good thing... but hopefully it can wait a little longer. Leaving this PR open to be reviewed at a later time (or by someone else).
DynamicProxy has to be able to deal with types both from strong-named ("signed") and non-strong-named ("unsigned") assemblies. Depending on whether a type to be proxied comes from one or the other, DynamicProxy needs to do slightly different things. Therefore we need both strong-named and non-strong-named assemblies in our test suite to cover all those cases. The |
|
sad. As I See appveyor image doesn't have .NET 10 for now., This is blocked for this |
@Romfos, note that the .NET 10 SDK can be installed before the AppVeyor CI run commences: 4f624b0. (Relevant AppVeyor documentation for that is here.) The tradeoff being that the AppVeyor builds become even slower. (To be honest, I'm getting around to your point of view: it'll be good to be rid of it ASAP. That being said, see my comment in #699 (comment). Let's probably do this for the next release after 6.0.0.) |
|
ok, rebased cc @jonorossi |
|
FYI, I've also contacted jonorossi regarding the NuGet API key in GitHub Actions config. Let's proceed once that is set up. |
|
@Romfos, I'm marking this PR as a "draft" to prevent accidental merging. I want to make sure the NuGet publishing is fully set up before this lands on |
Changes:
How to use:

If you want to publish directly to nuget owner of this repo should set NUGET_API_KEY to the repo secrets and check "publish to nuget" during release build