Update release instructions for automation

CONTRIBUTING.md

@@ -38,11 +38,11 @@ Smoke testing is used to verify that the output generated by our `./build` scrip
 functions as expected.
 
 This is done through running the generated binaries against production or custom
-providers and verifying the output manually.  
+providers and verifying the output manually.
 
 ### Generating Mock Providers
 
-For testing purposes, it is often necessary to create a "mock" provider which can verify 
+For testing purposes, it is often necessary to create a "mock" provider which can verify
 input and output. This can be done by creating a script which can be run by Summon and
 placing it in the default path, `/usr/local/lib/summon/`
 
@@ -75,7 +75,7 @@ The following checklist should be followed when creating a release:
 - [ ] Open a PR with the following changes for `main` branch and wait for it to be merged:
   - [ ] Bump release version in [`pkg/summon/version.go`](pkg/summon/version.go).
   - [ ] Bump version in [`CHANGELOG.md`](CHANGELOG.md).
-  
+
 - [ ] Retrieve artifacts generated by jenkins to perform smoke tests
    - Note: You can manually [`Build`](./build) the release. Output is placed in the `dist` folder
    - [ ] Binaries for smoke testing are found in the following directories
@@ -84,28 +84,20 @@ The following checklist should be followed when creating a release:
                    `dist/goreleaser/summon-darwin-arm64`
         - Windows: `dist/goreleaser/summon_windows_amd64`
 
-- [ ] Create a draft release:
-  - [ ] Create an [annotated tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging#_annotated_tags)
-        of the merged commit with the name `v<version>` and push it to the repository.
-        For example: `git tag -a v<version> -m "Release of v<version>"  `
-  - [ ] Using the GitHub UI, create a release using the tag created earlier as the starting point.
-  - [ ] Name the release the same as the tag.
-  - [ ] Include in the release notes all changes from CHANGELOG that are being released.
-    - [ ] Attach the relevant assets to the release, generated previously by `./build`:
-      - [ ] Attach `dist/goreleaser/summon-darwin-a*64.tar.gz` to release.
-      - [ ] Attach `dist/goreleaser/summon-linux-amd64.tar.gz` to release.
-      - [ ] Attach `dist/goreleaser/summon-windows-amd64.tar.gz` to release.
-      - [ ] Attach `dist/goreleaser/summon_v*.rpm` to release.
-      - [ ] Attach `dist/goreleaser/summon_v*.deb` to release.
-      - [ ] Attach `dist/goreleaser/CHANGELOG.md` to release.
-      - [ ] Attach `dist/goreleaser/SHA256SUMS.txt` to the release.
-  - [ ] Publish the release as a "pre-released".
-
+- [ ] Create an [annotated tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging#_annotated_tags)
+      of the merged commit with the name `v<version>` and push it to the
+      repository. For example: `git tag -a v<version> -m "Release of v<version>"`
+      This will automatically create a draft release with artifacts attached.
+
+- [ ] Publish the draft as "pre-released".
+
 - [ ] Update homebrew tools
-  - [ ] In [`cyberark/homebrew-tools`](https://github.com/cyberark/homebrew-tools) repo, update
-        the [`summon.rb` formula](https://github.com/cyberark/homebrew-tools/blob/main/summon.rb#L4-L6) with a PR
-        using the file `dist/goreleaser/summon.rb`.
-
+  - [ ] In [`cyberark/homebrew-tools`](https://github.com/cyberark/homebrew-tools)
+        repo, create a PR to update the [`summon.rb` formula](https://github.com/cyberark/homebrew-tools/blob/main/summon.rb#L4-L6)
+        using the file `dist/goreleaser/summon.rb` retrieved from Jenkins artifacts.
+        Make sure the SHA hashes for the artifacts match the values in the `SHA256SUMS.txt`
+        file attached to the release.
+
 - [ ] Publish the release as a regular release.
 
 - [ ] Perform smoke tests, using this release, on the following platforms:
@@ -114,20 +106,21 @@ The following checklist should be followed when creating a release:
     - MacOS
 
 ## Troubleshooting
+
 The following issues, and their respective solutions, are occasionally encountered when
-using Summon for the first time. 
+using Summon for the first time.
 
 Q:  When I run commands like this,
 ```
 $ summon -p <provider> echo $FOO
 ```
 the variable `FOO` appears to be empty.
-   
-A:  When running Summon directly in a shell, your current shell(not Summon's shell) interprets 
+
+A:  When running Summon directly in a shell, your current shell(not Summon's shell) interprets
     the value of `FOO` before Summon does. To make sure that the variable is correctly
     expanded, you need to wrap your `echo` command with something that understands
-    environment variables passed from summon (like `bash`). 
-    A working example would be: 
+    environment variables passed from summon (like `bash`).
+    A working example would be:
 ```
 $ summon -p <provider> /bin/bash -ec 'echo $FOO'
 bar
@@ -145,9 +138,9 @@ yaml: unmarshal errors:
 OR my output is empty.
 
 A:  In the first case, the `!` is part of history expansion in bash. To use it in this
-    case, the string will need to be enclosed in single quotes. 
-    In the second case, the `echo` statement should also be enclosed in single quotes, to 
-    avoid your current shell interpolating the variable before summon can. 
+    case, the string will need to be enclosed in single quotes.
+    In the second case, the `echo` statement should also be enclosed in single quotes, to
+    avoid your current shell interpolating the variable before summon can.
     A working example would be:
 ```
 $ summon -p <provider> --yaml 'FOO: !var bar' /bin/bash -ec 'echo $FOO'