chore: Define check in release process ensuring migration guide is defined in a major version

[AgustinBettati]

Description

Link to any related issue(s): CLOUDP-244149

If we ever forget to define the migration guide for a major version (vX.Y.0) the release process will stop automatically. This is already stated in our docs.

Testing

• Release of minor does not check for upgrade guide: https://github.com/AgustinBettati/terraform-provider-mongodbatlas/actions/runs/8738232136
• Release of major version missing upgrade guide: https://github.com/AgustinBettati/terraform-provider-mongodbatlas/actions/runs/8740057703
• Release of major version using existing tag that defined guide: https://github.com/AgustinBettati/terraform-provider-mongodbatlas/actions/runs/8740162743

Type of change:

• Bug fix (non-breaking change which fixes an issue). Please, add the "bug" label to the PR.
• New feature (non-breaking change which adds functionality). Please, add the "enhancement" label to the PR. A migration guide must be created or updated if the new feature will go in a major version.
• Breaking change (fix or feature that would cause existing functionality to not work as expected). Please, add the "breaking change" label to the PR. A migration guide must be created or updated.
• This change requires a documentation update
• Documentation fix/enhancement

Required Checklist:

• I have signed the MongoDB CLA
• I have read the contributing guides
• I have checked that this change does not generate any credentials and that they are NOT accidentally logged anywhere.
• I have added tests that prove my fix is effective or that my feature works per HashiCorp requirements
• I have added any necessary documentation (if appropriate)
• I have run make fmt and formatted my code
• If changes include deprecations or removals, I defined an isolated PR with a relevant title as it will be used in the auto-generated changelog.
• If changes include removal or addition of 3rd party GitHub actions, I updated our internal document. Reach out to the APIx Integration slack channel to get access to the internal document.

Further comments

[oarbusi]

should we add the link or do you think it's not necessary?
https://github.com/mongodb/terraform-provider-mongodbatlas/blob/master/RELEASING.md#verify-upgrade-guide-is-defined

[AgustinBettati]

Preferred to keep it more generic so the reference does not breaking moving forward, but no strong opinion

[maastha]

we could add a link to the RELEASE.md instead of the exact section

[lantoli]

knit: similary to validate-inputs i don't know if it would be better to have an update job with both references in doc and changelog header. or maybe it's better as it is now

[AgustinBettati]

Since the commits are being done by calling an external workflow we do not have the possibility of having both in a single job

[lantoli]

"Verify upgrade guide is defined" section in RELEASING.md can be updated or deleted

[lantoli]

knit: look at this PR I was thinking that it might be useful to have a way to know if the release process will probably success without running it, e.g.:

• Having a dryrun mode input param to check if the release could be done without actually doing it
• Having the validates in a different workflow so it can be run without doing the release process

this could help to anticipate and fix problems in the release

[AgustinBettati]

@lantoli responding here:

"Verify upgrade guide is defined" section in RELEASING.md can be updated or deleted

While it can be completely deleted, prefered to keep it as it describes what the upgrade guide must have. In the failure of the job we referencing to the releasing docs for more info.

dryrun mode input param to check if the release could be done without actually doing it

A prerelease would be the most similar to a dry run process. However I doubt we will likely make use of this in a regular release, maybe in case we encounter specific issues and want to do a test run.

[lantoli]

"Verify upgrade guide is defined" section in RELEASING.md can be updated or deleted. While it can be completely deleted, prefered to keep it as it describes what the upgrade guide must have. In the failure of the job we referencing to the releasing docs for more info.

at least i would comment in the doc that there is an automatic check