Migrate MyGet script to GH actions

[supergibbs]

Description

Migrate MyGet script to GitHub Actions to automatically build/publish the Bootstrap NuGet package when a release is created

Needs NuGetAPIKey to be added to repo secrets (I can provide or @mdo can create API key)

Rules for action to run:

• Must be twbs/bootstrap, won't run on forks
• Only triggered by a GitHub Release event
• Release tag must begin with a v (this matches all current releases)

Risks

Due to how NuGet works, if a version is accidentally published, there is no way to update it. If there is an issue, it can be delisted but a version change is required. In those cases, it would need to be manually fixed and add a build to it.

Example:
Release v5.3.8 is accidentally created on GitHub and deploys to NuGet. Release is deleted and recreated as v5.3.8 but the NuGet action fails

To fix, the 5.3.8 NuGet package should be delisted and manually republished as 5.3.8+a or some other +build to change the version.

I am guessing this is true with other package systems so if others are automated, better to just release 5.3.9 and mark 5.3.8 as deprecated.

Motivation & Context

Streamline publishing of NuGet package

Type of changes

Just CI/CD changes in GitHub Actions, no change to Bootstrap itself

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (non-breaking change)
• Breaking change (fix or feature that would change existing functionality)

Checklist

• I have read the contributing guidelines
• My code follows the code style of the project (using npm run lint)
• My change introduces changes to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

Live previews

My testing on my fork
https://github.com/supergibbs/bootstrap/actions

Related issues

Was discussed with @mdo on #41358

[julien-deramond]

This is really cool @supergibbs 🥳
Just one comment which is more a question :)

[julien-deramond]

I'm not exactly sure how NuGet versioning works, so I wanted to mention this. If we create a v6.0.0-alpha1 version, it will trigger the workflow and produce v6.0.0-alpha1 NuGet packages.

Do you know if NuGet treats that as the latest version?

If it does, maybe startsWith isn't enough: we might need to check that the version matches exactly vX.Y.Z without extra characters 🤷

[supergibbs]

Technically it does, in the sense when browsing nuget.org it will let you know there is newer version 6.0.0-alpha1 if viewing 5.3.7. Example, here is the latest stable EntityFrameworkCore and there is a message about a newer one that is prerelease (10.0.0-preview.5.25277.114).

When installing though, the default is the latest (by SemVer) that is not a prerelease version. You can get the latest, including prerelease by adding -prerelease or a specific -version 5.3.7.

I noticed NuGet is the only one that doesn't specify a version on the Package Managers section. Should it?

Regarding better version tag validation, I am all for it but don't want to exclude prereleases since we've supported them in the past.

[julien-deramond]

When installing though, the default is the latest (by SemVer) that is not a prerelease version.

NuGet is smarter than npm then 😄 From what I remember, in npm, you have to be explicit if you don’t want a version to be tagged as latest, even if it’s a pre-release like 2.0.0-beta.1. npm doesn’t care about the version name; it uses the latest tag by default unless you override it.

I noticed NuGet is the only one that doesn't specify a version on the Package Managers section. Should it?

When running npm install bootstrap, you get the latest (so currently the 5.3.7) and still we're specifying the version in the docs by saying npm install bootstrap@5.3.7. We could do the same for NuGet, yes :)