ci: Apply yarn-deduplicate to dependabot tasks

[Yaminyam]

Motivation

For dependabot pr we are currently accepting and merging automatically.
However, there are cases where the yarn-deduplicate operation is not reflected and cannot be merged automatically.
#12183

Modifications

For dependabot pr, run yarn --cwd ui deduplicate and commit and push the changes.

Verification

[terrytangyuan]

cc @agilgur5 to take a look

[Yaminyam]

@agilgur5 What I just realized is that with the current method, the DCO check is expected to fail because the bot commit is not signed.

[Yaminyam]

I think the solution would be to create a bot for signing or create a commit by the maintainer of the repo.

[agilgur5]

However, there are cases where the yarn-deduplicate operation is not reflected and cannot be merged automatically.

Yea I mentioned this in #11728 (comment) and a previous Contributor Meeting (or two).
I thought updating to newer Yarn might fix this but this seems to still be a problem in newer Yarn versions too: yarnpkg/berry#4976.

There's also this Dependabot issue on the topic: dependabot/dependabot-core#5830

For dependabot pr, run yarn --cwd ui deduplicate and commit and push the changes.

Thanks for the contribution! I was thinking of adding something similar after seeing comments in the Dependabot issue pointing to foxglove/studio#4736 (current GHA workflow)

[Yaminyam]

@agilgur5 It's great to hear that this was an issue that was already being addressed.
In the case of the attached pr, it operates as an independently executed workflow.
However, I added logic to the existing workflow to make execution simpler.

And it would be great if you could give us your opinion on how to solve the sign-off problem!

[agilgur5]

I was thinking of adding this to the dependabot-reviewer Workflow instead, so all dependabot things are in one place. That may be slightly more complicated though.

[agilgur5]

This whole block should also have a comment describing it and why it exists

[Yaminyam]

In order for this job to work in dependabot-reviewer, I think it is necessary to run change-files like ci-build workflow to determine whether the ui job is running.
But I think that creates too much complexity.

[agilgur5]

Mmm not so much changed-files as we'd need to run parts of the ui: job itself in order to install Node, NPM, and some deps. It would indeed be simpler to leave here 🤔

[agilgur5]

Sorry for the delay on this one, I had some family medical emergencies pop up in late November that got me really busy.

I just have one tiny change, otherwise LGTM

[agilgur5]

Welp, now the git commit passes with an --allow-empty (per above comment), but the git push line is failing. From failing CI in #12891:

Run git config --global user.name 'github-actions[bot]'
  git config --global user.name 'github-actions[bot]'
  git config --global user.email 'github-actions[bot]@users.noreply.github.com'
  git add ui/yarn.lock
  git commit -s --allow-empty -m 'chore: deduplicate yarn.lock'
  git push
  shell: /usr/bin/bash -e {0}
  env:
    NODE_OPTIONS: --max-old-space-size=4096
[detached HEAD 4ab78f5] chore: deduplicate yarn.lock
fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use

    git push origin HEAD:<name-of-remote-branch>

Error: Process completed with exit code 1[2](https://github.com/argoproj/argo-workflows/actions/runs/8561962725/job/23464600770?pr=12880#step:9:2)8.

It's on a detached HEAD and therefore not on a branch that it can push. I believe this is because actions/checkout checks out the exact commit, and not a branch (which makes sense, it's safer to do that)

[agilgur5]

We should be able to use $GITHUB_HEAD_REF as the branch name (per the docs, it is set for PRs, and dependabot is always a PR), so something like:

Suggested change

	git push
	git push origin HEAD:$GITHUB_HEAD_REF

but honestly this needs some more testing given all the errors so far. I would suggest trying this on a PR on a fork and skipping the dependabot actor check for testing purposes

[agilgur5]

I'm testing this in agilgur5#3. I had to add permissions.contents: write as well (which isn't great, but necessary, with no real workarounds for it).

It's still failing though, because it thinks it has something to fetch from the remote branch, even though it doesn't. So it needs some more work.

Tbh, this is getting complicated enough that it perhaps should be split out into its own independent action

[agilgur5]

It's still failing though, because it thinks it has something to fetch from the remote branch, even though it doesn't.

I fixed this by adding fetch-depth to actions/checkout. It passes now.... but the PR won't merge because the new commit doesn't run any checks, since GH won't run actions on changes from other actions (to avoid an infinite loop), per previous comment.

So this whole approach isn't workable as checks will never run/pass on the final commit, meaning it will never be mergeable due to branch protections.

[agilgur5]

Reverted in #12892