Use commit hash for dependabot-auto-approve action

[Marenz]

Summary

• Add GitHub workflow to automatically approve and merge Dependabot PRs
• Uses merge method for clean commit history

[Copilot]

Pull Request Overview

Adds a GitHub Actions workflow to automatically approve and merge Dependabot pull requests.

• Introduces a workflow triggered on pull_request events with a job gated to Dependabot actor.
• Uses an external action to auto-approve and merge using the merge method.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The workflow is missing a permissions block; by default GITHUB_TOKEN has read-only contents permission and cannot approve or merge PRs. Add explicit permissions (either at the workflow root or under the job) such as: permissions: contents: write pull-requests: write to enable the action to approve and merge Dependabot PRs.

[florian-wagner-frequenz]

Nit: VSCode does it's thing of swallowing the trailing newline, which technically makes non POSIX compliant files.
But I guess that ship has passed.

[florian-wagner-frequenz]

This doesn't seem to be a github (the company) owned action.
Would it make sense to vendor this to prevent supply chain attacks? The underlying repo looks quite new (september 9th) and has exactly one developer (ad) who seems to have coded it in a single day.

I am not sure what our stance is here, but I'd argue for having less external dependencies, especially if they're this small.

[Marenz]

It's a fair point @llucax ^

[llucax]

Yeah, we need to get this cleaned up, we can vendor or use hashes instead of versions, this way we also ensure we are now powned via supply chain attacks inadvertently, and it is supported by dependabot, so it will probably rot less.

BTW, in the floss org we don't allow using any random third party action, we have an allow list. We should probably do the same for -io, I didn't do it because there were too many projects already when I arrived and didn't know what the impact could be.

Now maybe it would be easy to tell AI to craft a quick script to get a list of all used actions

[florian-wagner-frequenz]

I agree that vendoring or hashing is a viable step. That said, I'd also argue for reviewing the code in question either way. It's not too much and we should ensure that we don't pin to an obviously vulnerable/malicious version.

[Marenz]

we can just fork it into -floss and manually keep sync if need be, that way we can also easily introduce a feature we want: regex filter based on PR title. Would you create the repo luca? I don't have the perms for -floss

[florian-wagner-frequenz]

So I took the time to review the code.
Good news: I don't think it has any obvious security vulnerabilities (but then, I'm not a bash red-teamer).

That said, I would advocate for two changes once we vendor it:

1. Condense the steps. Currently there is a lot of superfluous steps, which introduces quite some line noise for very little benefit (as an example Create Label and Add label should probably be merged). Making those changes will make maintenance easier in the future
2. Don't throw away error information. Currently all invocations of gh cli are made with 2>/dev/null and then provide "helpful" guesses what could be the error.

Compare:

$ gh auth status --help
Display active account and authentication state on each known GitHub host.
 
For each host, the authentication state of each known account is tested and any issues are included in the output.
Each host section will indicate the active account, which will be used when targeting that host. If an account on any host (or only the one given via `--hostname`) has authentication issues, the command will exit with 1 and output to stderr.

[Marenz]

We just forked it for doing changes like that :)
I will look into a PR-title regex feature soon. I think I have a branch already, but I need to review / test it .

[Marenz]

Updated to use our own fork an the full tag v1.3.0

[llucax]

Updated to use our own fork an the full tag v1.3.0

Not trying to be a PITA, but I would still favor using hashes as tags can still be hacked if a repo is taken over. The convention in GA Actions is to use the hash and put the tag as a comment, not sure if it is necessary for dependabot to work but it is still good "documentation" anyway if we go with hashes.

[Marenz]

using hash for v1.3.2 now

[llucax]

Still missing some config compared to the version in repo-config, but maybe just wait to get the update from there?

[Marenz]

but maybe just wait to get the update from there?

I did update it with the script ;) seems to need more work

[daniel-zullo-frequenz]

The auto-dependabot action has been recently added as part of the migration to repo-config v0.14.0