OPS-60 Removed old create/update release since we now have genereate jira release

Author: ToreMerkely

.github/workflows/create-release.yml

@@ -1,4 +1,4 @@
-name: Generate release candidate
+name: Generate Jira release
 
 on:
   workflow_dispatch:

.github/workflows/generate-jira-release.yml

@@ -6,12 +6,6 @@ deploy_to_staging:
 generate_jira_release:
 	gh workflow run generate-jira-release.yml --ref main
 
-create_release_candidate:
-	gh workflow run generate-jira-release.yml --ref main
-
-update_release_candidate:
-	gh workflow run generate-jira-release.yml --ref main
-
 check_release_to_prod:
 	gh workflow run release-to-prod.yml --ref main
 

.github/workflows/update-release.yml

@@ -102,9 +102,9 @@ but in this simulated setup we only update some git tags.
 ## Release to production
 When a developer thinks that what is currently running in staging should be released
 to production they  create a **release candidate**. The developers can trigger the
-**Create release candidate** GitHub action by running:
+**Generate Jira release** GitHub action by running:
 ```
-make create_release_candidate
+make generate_jira_release
 ```
 This job does the following:
 - Use Kosli to find out what software that is currently running on staging and
@@ -123,9 +123,9 @@ developers.
 
 After the developers has added a fix and deployed it to staging they update the
 **release candidate**. The developers can trigger the
-**Update release candidate** GitHub action by running:
+**Generate Jira release** GitHub action by running:
 ```
-make update_release_candidate
+make generate_jira_release
 ```
 
 When all approvers have set the approval to `APPROVED` the software can be deployed
@@ -252,7 +252,7 @@ The SW is now running in staging
   https://app.kosli.com/kosli-public/environments/jira-integration-example-staging/snapshots/
 
 Create a release candidate
-  make create_release_candidate
+  make generate_jira_release
 
 Show the customer the new release
   https://kosli-team.atlassian.net/projects/OPS?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page
@@ -290,7 +290,7 @@ Go back to the Jira board and make a new Jira issue: Improve frontend
 Now we have the new fix for frontend running in staging. The backend SW is the same as before.
 
 Update the Jira release so we also include the new Jira issue
-  make update_release_candidate
+  make generate_jira_release
 
 Show the release (you must reload the page) to show that the new Jira issue is in the list
 

Makefile

@@ -92,7 +92,7 @@ main()
     make deploy_to_staging; wait_for_github_actions
     make report_all_envs > /dev/null; wait_for_github_actions
     echo; echo "*** Make a release candidate for SW now running in staging with Jira issue ${JIRA_KEY_1}"
-    make create_release_candidate; wait_for_github_actions
+    make generate_jira_release; wait_for_github_actions
 
     echo; echo "*** We assume the product owner found a bug and wanted a new version of the backend"
 
@@ -112,7 +112,7 @@ main()
     make report_all_envs > /dev/null; wait_for_github_actions
     echo; echo "*** Update the release candidate for SW now running in staging."
     echo "*** This will add the second JIRA-KEY ($JIRA_KEY_2) to the Jira release"
-    make update_release_candidate; wait_for_github_actions
+    make generate_jira_release; wait_for_github_actions
     echo; echo "*** Check if current release candidate has been approved and can be released. This shall fail!"
     make check_release_to_prod; wait_for_github_actions
 

README.md

@@ -61,7 +61,7 @@ main()
     make deploy_to_staging; wait_for_github_actions
     make report_all_envs > /dev/null; wait_for_github_actions
     echo; echo "*** Make a release candidate for SW now running in staging"
-    make create_release_candidate; wait_for_github_actions
+    make generate_jira_release; wait_for_github_actions
 
     echo; echo "*** Go to url:"
     echo "https://kosli-team.atlassian.net/projects/OPS?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page"