Repository navigation
Replace AppVeyor with GitHub Actions & NuGet.org Trusted Publishing #739
Description
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
Activity
304NotModified commentedon Mar 9, 2026
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 commentedon Mar 9, 2026
See also #700.
304NotModified commentedon Mar 9, 2026
@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:
URL: https://www.nuget.org/account/trustedpublishing
Create:
Settings:
304NotModified commentedon Mar 9, 2026
@stakx, @zvirja, @Romfos my proposal:
and it's fixed forever!
stakx commentedon Mar 9, 2026
@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:
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 commentedon Mar 9, 2026
@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 commentedon Mar 9, 2026
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 commentedon Mar 9, 2026
Sounds reasonable!
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 commentedon Mar 10, 2026
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.
Jappinen commentedon Mar 13, 2026
I ran into an unfortunate combination here when updating our projects to .NET 10:
6.0 fixes the problem but I'd have much less explaining to do if some mysterious reference to Appveyor wouldn't appear in the configs 😄.
Anyway thanks guys for looking into this, really appreciate it.
stakx commentedon Mar 13, 2026
@Jappinen, I do not understand what you are trying to say. Why would there be "some mysterious reference to AppVeyor in the configs"? What configs? What reference? Once AppVeyor has built and pushed the Castle.Core NuGet packages, it is out of the picture and shouldn't matter at all to downstream consumers. (Otherwise you would have had that issue with prevoius versions already; it is not like we only just started using AppVeyor for CI recently...)
Jappinen commentedon Mar 14, 2026
I meant my local nuget.config, adding an extra source referencing the AppVeyor preview feed was the easiest way to get the 6.0 Castle.Core binary but that is bound to raise some eyebrows at the office so official release from nuget.org would be preferable.
stakx commentedon Mar 14, 2026
@Jappinen, that is the plan (and usual practice) regardless of whether we'll release via AppVeyor or GitHub Actions.
Jappinen commentedon Mar 15, 2026
Yes and it sounded like one of those would be pretty much ready to go right now and the other would take some(?) time to finalize.
I just wanted to point out that there's at least one version conflict out in the wild and whether that affects which way you decide to go. I probably could have phrased my original message better, sorry for the confusion.