Update release steps in CONTRIBUTING.md

CONTRIBUTING.md

@@ -69,49 +69,44 @@ itself, as needed.
 
 ## Releasing
 
-The following checklist should be followed when creating a release:
+Releases should be created by maintainers only. To create a tag and release, follow the instructions in this section.
 
-- [ ] 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).
-  - [ ] Update NOTICES.txt
+### Pre-requisites
+
+1. Review the git log and ensure the [changelog](CHANGELOG.md) contains all
+   relevant recent changes with references to GitHub issues or PRs, if possible.
+2. Ensure that all documentation that needs to be written has been
+   written by TW, approved by PO/Engineer, and pushed to the forward-facing documentation.
+
+### Update the changelog and notices (if necessary)
+
+1. Update the `CHANGELOG.md` file with the new version and the changes that are included in the release.
+
+1. Update `NOTICES.txt`
     ```sh-session
     go install github.com/google/go-licenses@latest
-    # Verify that dependencies fit into supported licenses types. If there is new dependency having unsupported license,
-    # that license should be included to notices.tpl file in order to get generated in NOTICES.txt.
-    $(go env GOPATH)/bin/go-licenses check ./... --allowed_licenses="MIT,ISC,Apache-2.0,BSD-3-Clause,BSD-2-Clause"
+
+    # Verify that dependencies fit into supported licenses types.
+    # If there is new dependency having unsupported license, that license should be
+    # included to notices.tpl file in order to get generated in NOTICES.txt.
+    $(go env GOPATH)/bin/go-licenses check ./... \
+      --allowed_licenses="MIT,ISC,Apache-2.0,BSD-3-Clause,BSD-2-Clause" \
+      --ignore $(go list std | awk 'NR > 1 { printf(",") } { printf("%s",$0) } END { print "" }')
+
     # If no errors occur, proceed to generate updated NOTICES.txt
-    $(go env GOPATH)/bin/go-licenses report ./... --template notices.tpl > NOTICES.txt --ignore github.com/cyberark/summon
+    $(go env GOPATH)/bin/go-licenses report ./... \
+      --template notices.tpl \
+      --ignore github.com/cyberark/summon \
+      --ignore $(go list std | awk 'NR > 1 { printf(",") } { printf("%s",$0) } END { print "" }') \
+      > NOTICES.txt
     ```
 
-- [ ] 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
-        - Linux:   `dist/goreleaser/summon-linux_linux_amd64_v1`
-        - MacOS:   `dist/goreleaser/summon_darwin_amd64_v1`
-                   `dist/goreleaser/summon-arm_darwin_arm64`
-        - Windows: `dist/goreleaser/summon_windows_amd64_v1`
-
-- [ ] 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, 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:
-    - Linux
-    - Windows
-    - MacOS
+### Release and Promote
+
+* Merging into main/master branches will automatically trigger a release. If successful, this release can be promoted at a later time.
+* Jenkins build parameters can be utilized to promote a successful release or manually trigger aditional releases as needed.
+* Reference the [internal automated release doc](https://github.com/conjurinc/docs/blob/master/reference/infrastructure/automated_releases.md#release-and-promotion-process) for releasing and promoting.
+
 
 ## Troubleshooting
 

test_acceptance

@@ -4,9 +4,6 @@ OUTPUT_DIR="$PWD/output/acceptance"
 
 rm -f "$OUTPUT_DIR/*.xml"
 
-pwd
-ls -la
-
 echo "Running acceptance tests"
 docker build --pull -t summon-acceptance -f Dockerfile.acceptance .