fix release action

.github/actions/github-actions/release-action/action.yml

@@ -136,15 +136,15 @@ runs:
           branch_name=$(echo $info | jq -r '.branch_name')
           action_path=$(echo $info | jq -r '.action_path')
           release_type=$(echo $info | jq -r '.release_type')
-          if ! git show-ref --quiet refs/heads/$version; then
-            if ! git show-ref --quiet origin/$version; then
-              git checkout -b ${{ inputs.base_branch }} origin/${{ inputs.base_branch }}
+          if ! git rev-parse --quiet --verify $version; then
+            if ! git ls-remote --heads origin $version | grep -q $version; then
+              git checkout ${{ inputs.base_branch }}
               git pull
               git checkout -b $version
-              git push origin -u $version
+              git push -u origin $version
             else
               echo "Version branch $version exists remotely, checking out"
-              git checkout -b $version origin/$version
+              git checkout $version
               git pull
             fi
           else
@@ -161,7 +161,7 @@ runs:
           git checkout origin/${{ inputs.main_branch }} -- $action_path
           git add .
           git commit -m "[$release_type] $version for $action_path"
-          git push origin $branch_name
+          git push -u origin $branch_name
         done
 
     - name: Create pull requests

README.md

@@ -12,13 +12,13 @@ Pull Request plays a significant part in day-to-day development, and it is essen
 
 At UPSIDER, we have a few internal repositories set up with a monorepo structure, with many types of code in a single repository. This comes with its own pros and cons, but one difficulty is how we end up with various CI jobs, which only run for changes that touch relevant files. With GitHub's branch protection, there is no way to specify "Ensure Go build and test pass _if and only if_ Go code is updated", or "Ensure E2E tests are run and successful _if and only if_ frontend code is updated". This is due to the GitHub branch protection design to specify a list of jobs to pass, which is only driven by the target branch name, regardless of change details. Because of this limitation, we would either need to run all the CI jobs for any Pull Requests, or do not set any limitation based on the CI status. <sup><sub><sup>(\*1)</sup></sub></sup>
 
-**Merge Gatekeeper** was created to provide more control for merges. By placing Merge Gatekeeper to run for all PRs, it can check all other CI jobs that get kicked off, and ensure all the jobs are completed successfully. If there is any job that has failed, Merge Gatekeeper will fail as well. This allows merge protection based on Merge Gatekeeper, which can effectively ensure any CI failure will block merge. All you need is the Merge Gatekeeper as one of the PR based GitHub Action, and set the branch protection rule as shown below:
+**Merge Gatekeeper** was created to provide more control for merges. By placing Merge Gatekeeper to run for all PRs, it can check all other CI jobs that get kicked off, and ensure all the jobs are completed successfully. If there is any job that has failed, Merge Gatekeeper will fail as well. This allows merge protection based on Merge Gatekeeper, which can effectively ensure any CI failure will block merge. All you need is the Merge Gatekeeper as one of the PR based GitHub Action, and set the branch protection rule as shown below.
 
 ![Branch protection example](/assets/images/branch-protection-example.png)
 
-We are looking to add a few more features, such as extra signoff from non-coder, label based check etc.
+We are looking to add a few more features, such as extra signoff from non-coder, label based check, etc.
 
-<sup><sub>NOTE:  
+<sup><sub>NOTES:  
 <sup>(\*1)</sup> There are some other hacks, such as using an empty job with the same name to override the status, but those solutions do not provide the flexible control we are after.</sub></sup>
 
 <!-- == imptr: background / end == -->