Update releasing docs to new release workflow

As we take into use the new release workflow (committing release note to
main triggers release actions), update the releasing doc accordingly.

Signed-off-by: Huy Mai <[email protected]>

.gitignore

@@ -32,7 +32,6 @@ minikube.kubeconfig
 
 # Example and binary output directory
 out
-releasenotes
 
 # vscode
 .vscode

docs/releasing.md

@@ -59,76 +59,69 @@ CAPM3 uses [semantic versioning](https://semver.org).
 
 ### Repository setup
 
-Clone the repository:
+- Clone the repository:
 `git clone [email protected]:metal3-io/cluster-api-provider-metal3`
 
-or if using existing repository, verify your intended remote is set to
-`metal3-io`: `git remote -v`. For this document, we assume it is `origin`.
-
-- If creating a new minor branch, identify the commit you wish to create the
-  branch from, and create a branch `release-1.x`:
-  `git checkout <sha> -b release-1.x` and push it to remote:
-  `git push origin release-1.x` to create it
-- If creating a new patch release, use existing branch `release-1.x`:
-  `git checkout origin/release-1.x`
-
-### Tags
-
-First we create a primary release tag, that triggers release note creation and
-image building processes.
-
-- Create a signed, annotated tag with: `git tag -s -a v1.x.y -m v1.x.y`
-- Push the tags to the GitHub repository: `git push origin v1.x.y`
-
-This triggers two things:
-
-- GitHub action workflow for automated release process creates a draft release
-  in GitHub repository with correct content, comparing the pushed tag to
-  previous tag. Running actions are visible on the
-  [Actions](https://github.com/metal3-io/cluster-api-provider-metal3/actions)
-  page, and draft release will be visible on top of the
-  [Releases](https://github.com/metal3-io/cluster-api-provider-metal3/releases)
-  page.
-- GH action `build-images-action` starts building release image with the release
-  tag in Jenkins, and it gets pushed to Quay. Make sure the release tag is
-  visible in
-  [Quay tags page](https://quay.io/repository/metal3-io/cluster-api-provider-metal3?tab=tags).
-  If the release tag build is not visible, check if the action has failed and
-  retrigger as necessary.
+or if using existing repository, make sure origin is set to the fork and
+upstream is set to `metal3-io`. Verify if your remote is set properly or not
+by using following command `git remote -v`.
 
-We also need to create one or more tags for the Go modules ecosystem:
+- Fetch the remote (`metal3-io`): `git fetch upstream`
+This makes sure that all the tags are accessible.
 
-- For any subdirectory with `go.mod` in it (excluding `hack/tools` and
-  `hack/fake-apiserver`), create another Git tag with directory prefix, ie.
-  `git tag api/v1.x.y` and `git tag test/v1.x.y`. This enables the
-  tags to be used as a Go module version for any downstream users.
+### Creating Release Notes
 
-  **NOTE**: Do not create annotated tags (`-a`, or implicitly via `-m` or `-s`)
-  for Go modules. Release notes expects only the main tag to be annotated,
-  otherwise it might create incorrect release notes. Push both of the tags to
-  `origin`.
+- Switch to the main branch: `git checkout main`
 
-### Release notes
+- Create a new branch for the release notes**:
+  `git checkout -b release-notes-1.x.x origin/main`
 
-Next step is to clean up the release note manually. Release note has been
-generated by the `release` action, do not click the `Generate release notes`
-button. In case there is issue with release action, you may rerun it via
-`Actions` tab, or you can `make release-notes` to get a markdown file with
-the release content to be inserted.
+- Generate the release notes: `RELEASE_TAG=v1.x.x make release-notes`
+   - Replace `v1.x.x` with the new release tag you're creating.
+   - This command generates the release notes here
+     `releasenotes/<RELEASE_TAG>.md` .
 
-- If release is not a beta or release candidate, check for duplicates, reverts,
-  and incorrect classifications of PRs, and whatever release creation tagged to
-  be manually checked.
+- Next step is to clean up the release note manually.
+   - If release is not a beta or release candidate, check for duplicates,
+     reverts, and incorrect classifications of PRs, and whatever release
+     creation tagged to be manually checked.
    - For any superseded PRs (like same dependency uplifted multiple times, or
-     commit revertions) that provide no value to the release, move them to
+     commit reversions) that provide no value to the release, move them to
      Superseded section. This way the changes are acknowledged to be part of the
      release, but not overwhelming the important changes contained by the
      release.
-- If the release you're making is not a new major release, new minor release,
-  or a new patch release from the latest release branch, uncheck the box for
-  latest release.
-- If it is a release candidate (RC) or a beta release, tick pre-release box.
-- Save the release note as a draft, and have others review it.
+
+- Commit your changes, push the new branch and create a pull request:
+IMPORTANT_NOTE:
+   - The commit and PR title should be 🚀 Release v1.x.y:
+      -`git commit -S -s -m ":rocket: Release v1.x.x"`
+      -`git push -u origin release-notes-1.x.x`
+   - Important! The commit should only contain the release notes file, nothing
+     else, otherwise automation will not work.
+
+- Ask maintainers and release team members to review your pull request.
+
+Once PR is merged following Github actions are triggered:
+
+- Github action `Create Release` runs following jobs:
+   - Github job `push_release_tags` will create and push the tags. This action
+     will also create release branch if its missing and release is `rc` or
+     minor.
+   - Github job `create draft release` creates draft release. Don't publish the
+     release until release tag is visible in. Runningactions are visible on the
+     [Actions](https://github.com/metal3-io/ip-address-manager/actions)
+     page, and draft release will be visible on top of the
+     [Releases](https://github.com/metal3-io/ip-address-manager/releases). If
+     the release you're making is not a new major release, new minor release,
+     or a new patch release from the latest release branch, uncheck the box for
+     latest release. If it is a release candidate (RC) or a beta release,
+     tick pre-release box.
+- Github action `build-images-action` is triggered once tags are pushed from
+  above action. This action builds release image with the release tag in
+  Jenkins, and it gets pushed to Quay. Make sure the release tag is visible in
+  [Quay tags page](https://quay.io/repository/metal3-io/ip-address-manager?tab=tags).
+  If the release tag build is not visible, check if the action has failed and
+  retrigger as necessary.
 
 ### Release artifacts