ci(deps): fix git push during yarn.lock deduplication for Dependabot PRs [actions testing PR]

[agilgur5]

Fixes argoproj#12234 (comment), argoproj#12891 (comment)

Motivation

• actions/checkout runs git checkout on a specific commit SHA, meaning there is no "branch" by default, it's on a detached HEAD
  • so without a branch specified, git push would error out

Modifications

• specify a branch for git push using GH Actions env vars

  • note that $GITHUB_HEAD_REF should exist for PRs, and dependabot makes PRs (vs. direct pushes)
  • use origin as the remote name which is the default and also was mentioned in the error message

• add permissions.contents: write to allow for this GHA job to push

• add fetch-depth to actions/checkout so that it doesn't fail to push due to not having fetched (i.e. not knowing the state of the branch being pushed to)

• also add if git diff --quiet -- ui/yarn.lock check to short-circuit the logic if there are no changes to yarn.lock (i.e. no deduplication necessary)

  • this should also be less buggy as the later code will only execute when strictly necessary now (basically, when not needed, returns to the previous behavior prior to ci: Apply yarn-deduplicate to dependabot tasks argoproj/argo-workflows#12234)

Verification

I tested the short-circuit logic locally:

1. With no changes, exits properly:

   ❯ bash
   bash-5.1$ if ! git diff --exit-code -- ui/yarn.lock ; then
               exit 0
             fi
   exit
   ❯

2. With changes, does not exit:

   ❯ bash
   bash-5.1$ if ! git diff --exit-code -- ui/yarn.lock ; then
               exit 0
             fi
   bash-5.1$

Otherwise using this very PR in my own fork for testing purposes

[agilgur5]

As can be seen in this PR and per argoproj#12234 (comment), checks don't run on commits made by GH Actions (in order to prevent an infinite loop, see GH docs). That means that the git push from this script will never pass branch protections and so will never be mergeable as a result.

As such, I will not be making a PR for this upstream and will instead follow-up upstream with a revert of argoproj#12234 entirely, since it is not workable. EDIT: reverted in argoproj#12892

Tbh, I'm not really sure how to get around these limitations, it would be great if dependabot automatically deduplicated itself per dependabot/dependabot-core#5830. Otherwise we might be stuck with manual deduplication necessary 😕