chore: Adjusts release process to run tests against QA before releasi…

…ng (#1812)

* chore: Adjusts release process to run tests against QA before releasing

* adjusting documentation

* removing gpg parameters

* include input validation for version

* allow running qa acceptance tests in pre release

* include guidance in case of failures

.github/workflows/release.yml

@@ -1,16 +1,46 @@
-name: release
+name: 'New Release'
+run-name: 'Release ${{ inputs.version_number }}'
+
 on:
-  push:
-    tags:
-      - 'v*'
-jobs: 
-  goreleaser:
+  workflow_dispatch:
+    inputs:
+      version_number:
+        description: 'Version number (e.g., v1.0.0, v1.0.0-pre, v1.0.0-pre1)'
+        required: true
+      skip_tests:
+        description: 'Skip QA acceptance tests, define value to `true` to explicitly skip'
+
+jobs:
+
+  validate-version-input:
     runs-on: ubuntu-latest
+    steps:
+      - name: Validation of version format
+        run: |
+          echo "${{ inputs.version_number }}" | grep -P '^v\d+\.\d+\.\d+(-pre[A-Za-z0-9-]*)?$'  
+
+    # QA acceptance tests are skipped when explicit input parameter is used
+  run-qa-acceptance-tests:
+    needs: [ validate-version-input ]
+    if: needs.validate-version-input.result == 'success' && inputs.skip_tests != 'true'
+    secrets: inherit
+    uses: ./.github/workflows/acceptance-tests.yml
+    with:
+      atlas_cloud_env: "qa"
+
+  release:
+    runs-on: ubuntu-latest
+    needs: [ validate-version-input, run-qa-acceptance-tests ]
+    if: ${{ always() && needs.validate-version-input.result == 'success' && (needs.run-qa-acceptance-tests.result == 'skipped' || needs.run-qa-acceptance-tests.result == 'success') }}
     steps:
       - name: Checkout
         uses: actions/checkout@v4
       - name: Unshallow
         run: git fetch --prune --unshallow
+      - name: Create release tag
+        uses: rickstaa/action-create-tag@v1.7.2 # will fail if existing tag is present
+        with:
+          tag: ${{ inputs.version_number }}
       - name: Set up Go
         uses: actions/setup-go@v5
         with:

RELEASING.md

@@ -7,20 +7,19 @@
 ## Steps
 
 ### Make sure that the acceptance tests are successful
-Check [workflows/test-suite.yml](https://github.com/mongodb/terraform-provider-mongodbatlas/actions/workflows/test-suite.yml) and see if the latest run of the Test Suite action is successful (it runs every day at midnight UTC time). To complement this check, a manual execution of the Acceptance Test workflow must be run using `qa` ensuring all test groups are successful. 
-If tests are failing, you should investigate the failure before proceeding with the next steps.
+While QA acceptance tests are run in the release process automatically, it is advised to check [workflows/test-suite.yml](https://github.com/mongodb/terraform-provider-mongodbatlas/actions/workflows/test-suite.yml) and see if the latest run of the Test Suite action is successful (it runs every day at midnight UTC time). This can help detect failures before proceeding with the next steps.
 
 ### Pre-release the provider 
 We pre-release the provider to make for testing purpose. **A Pre-release is not published to the Hashicorp Terraform Registry**.
 
-- Create and push the pre-release tag (`vX.Y.Z-pre`) to master
-```bash
-git tag vX.Y.Z-pre
-git push origin vX.Y.Z-pre
-```
+- Using our [Release GitHub Action](https://github.com/mongodb/terraform-provider-mongodbatlas/actions/workflows/release.yml) run a new workflow using `master` and the following inputs:
+  - Version number: vX.Y.Z-pre
+  - Skip QA acceptance tests: Should be left empty. Only used in case failing tests have been encountered in QA and the team agrees the release can still de done, or successful run of QA acceptance tests has already been done with the most recent changes.
 
 - You will see the release in the [GitHub Release page](https://github.com/mongodb/terraform-provider-mongodbatlas/releases) once the [release action](.github/workflows/release.yml) has completed.
 
+**Note**: If a failure is encountered during the go releaser step you must manually delete the created tag and then retry running the action.
+
 ### Create PR updating Changelog and Upgrade Guide
 
 - Create a JIRA ticket and open a PR against the **master** branch. Make any manual adjustments if needed taking into account date format and format parameter names and resources/data source names if they begin with `mongodbatlas`.
@@ -48,7 +47,7 @@ We use a tool called [github changelog generator](https://github.com/github-chan
 - Create a new doc in /website/docs/guides/X.Y.0-upgrade-guide.html. This will contain a summary of the most significant features and breaking changes. Additional information that can be helpful to users can be defined here.
 
 ### Release the provider
-- Follow the same steps in the pre-release but provide the final release tag (example `v1.9.0`). This will trigger the release action that will release the provider to the GitHub Release page. Harshicorp has a process in place that will retrieve the latest release from the GitHub repository and add the binaries to the Hashicorp Terraform Registry.
+- Follow the same steps in the pre-release but provide the final release tag (example `v1.9.0`). Harshicorp has a process in place that will retrieve the latest release from the GitHub repository and add the binaries to the Hashicorp Terraform Registry.
 - **CDKTF Update - Only for major release, i.e. the left most version digit increment (see this [comment](https://github.com/cdktf/cdktf-repository-manager/pull/202#issuecomment-1602562201))**: Once the provider has been released, we need to update the provider version in our CDKTF. Raise a PR against [cdktf/cdktf-repository-manager](https://github.com/cdktf/cdktf-repository-manager).
   - Example PR: [#183](https://github.com/cdktf/cdktf-repository-manager/pull/183)