feat: Add automated release pipeline for NuGet and GitHub

[Nonanti]

• Add GitHub Actions workflow for automated releases
• Support both manual trigger and tag-based releases
• Publish to NuGet.org, GitHub Package Registry, and GitHub Releases
• Add comprehensive documentation for the release process
• Addresses issue #592

This pipeline will:

1. Build and test all target frameworks
2. Create NuGet packages
3. Publish to NuGet.org (requires NUGET_API_KEY secret)
4. Publish to GitHub Package Registry
5. Create GitHub Release with attached packages

[Nonanti]

✅ Update: Release Pipeline is Working!

Great news! After analyzing the existing test workflows and understanding the build requirements, the release pipeline is now successfully working.

Test Results

• ✅ Successful build: View workflow run
• ✅ NuGet packages created: 14.9 MB artifacts generated
• ✅ All stages passed: Build, test, and package creation

Key Changes Made

1. Fixed MonoMod dependency: Set MonoModCoreVersion to 1.3.0 to use NuGet package instead of private submodule
2. Removed submodule initialization: Avoided permission errors with private MonoMod repository
3. Aligned with existing workflows: Used same build commands as test-build.yml
4. Added proper environment variables: Included DOTNET_NOLOGO, etc. from existing workflows

Pipeline Features

• ✅ Manual workflow dispatch with version input
• ✅ Automatic trigger on version tags (v*.*.*)
• ✅ NuGet.org publishing (requires NUGET_API_KEY secret)
• ✅ GitHub Package Registry publishing
• ✅ GitHub Releases with artifacts
• ✅ Support for prerelease versions

Ready for Production

The pipeline is now ready to use. Once NUGET_API_KEY is added to repository secrets, it will automatically:

1. Build and test the solution
2. Create NuGet packages for all variants
3. Publish to NuGet.org and GitHub Package Registry
4. Create GitHub releases with changelogs

Looking forward to your review! The release process for Harmony can now be fully automated. 🚀

[pardeike]

• [ ] For a automated release, I would prefer the common approach of not working on the main branch. I could simply not allow commiting to main and instead always require PRs. It's professionally anyway. This would simplify the release workflow.
• [ ] Regarding the submodule: I always check it out, regardless if its used or not. Setting the MonoMod.Core version empty will automatically use the current git state of the sub repository. Otherwise it builds with the give nuget version, that's how the current build and test workflows do it and that's how the release workflow should work.
• [ ] Tests need to pass or else we shall not release.
• [ ] Your actions show a successful run on your fork but it has this part: "No files were found with the provided path: Harmony/bin/*.zip. No artifacts will be uploaded." - is that a real thing?
• [ ] "Should the pipeline build all target frameworks or just specific ones for releases?" -> build a three: Lib.Harmony, Lib.Harmony.Thin and Lib.Harmony.Ref - and also upload them to nuget and put them all three zipped in the release page

Automated version management - that's an interesting question. I rather want to define the version in the dev branch somehow... Are there any special build requirements or secrets needed beyond NUGET_API_KEY? No

[Nonanti]

i think its okey

[pardeike]

Can it be that the zip files/packages already exist after building? I think I don’t zip the nuget files but all the artifacts instead. Check against a manual build to see if there is a difference, or I can do that later when I have time. Also, remove comments mentioning me to keep it professional.

[pardeike]

Sorry for getting back to you so late but I had to deal with some illness. I think it would be nice to combine your work with this way to trigger it: https://chatgpt.com/share/68a88bfa-156c-8009-bd0b-ef1bf03898c7

What do you think?

[Nonanti]

@pardeike Thank you for sharing this approach! I really like the tag-driven release strategy.

Key points I understood:

• Use tags (v*) to trigger releases from master
• Version source of truth stays in Directory.Build.props
• Workflow validates tag matches HarmonyVersion
• No extra branches needed

I'll update the PR to implement this approach:

1. Add the release workflow with tag triggers
2. Include version validation from Directory.Build.props
3. Add the helper PowerShell script for tagging

This is indeed much cleaner and safer than branch-based releases. I'll get this updated shortly

[Nonanti]

@pardeike Thank you for the feedback! I've updated the PR with a tag-driven release approach as you suggested.

[Nonanti]

@pardeike tested the workflow on my fork and it works: https://github.com/Nonanti/Harmony/actions/runs/17176979461

everything passed except nuget publish (no api key on my fork obviously). created this test release: https://github.com/Nonanti/Harmony/releases/tag/v2.4.0.2