Disable approval for GH actions workflows

[danthe1st]

When some files in a plugin are changed for the first time, the version numbers need to be bumped in the META-INF/MANIFEST.MF (and potentially pom.xml) files.

To make this less annoying, GitHub Actions automatically updates the PR with the version bump and adds a comment.

Something similar is done to tell users when their PR has merge commits.
However, these actions won't be executed for PRs written by first-time contributors to a repository until a committer approves them (and I'd argue that especially the check for merge commits is pretty relevant for first-time contributors).

Because of that, I suggest changing the approval setting for GitHub actions to "Require approval for first-time contributors who are new to GitHub" in most repositories using that action (Settings > Actions > General > Approval for running fork pull request workflows from contributors) - at least in projects where the committers/project leads want that.

I don't think allowing anyone to use GitHub Actions would be much of an issue because anyone who fixed a typo or similar can already do that.

[tfroment]

Hi @danthe1st, thanks for sharing: @HannesWell @opcoach, wdyt?

[HannesWell]

Because of that, I suggest changing the approval setting for GitHub actions to "Require approval for first-time contributors who are new to GitHub" in most repositories using that action (Settings > Actions > General > Approval for running fork pull request workflows from contributors) - at least in projects where the committers/project leads want that.

First of all this has to be decided by the Committers and finally by the Project-Leads of each individual Eclipse project.
And while I understand your rational and agree that the check is probably most valuable for first time contributors I also see the value in it as a simple security feature. For the merge-commit check it shouldn't be a big issue as this workflow doesn't require critical permissions, but as this setting is for all or nothing I would be not be inclined to vote for enabling it.

[danthe1st]

First of all this has to be decided by the Committers and finally by the Project-Leads of each individual Eclipse project.

Yes but I decided to write this here first as I preferred to use one central place for the suggestion.

I also see the value in it as a simple security feature

I am not sure whether this argument works. This limitation does not apply to people who have contributed one and I wouldn't consider them much more trustworthy than people who haven't contributed before. So, even though the workflows have access to credentials, this should be properly protected against by the workflows themselves (assuming both the workflows and GitHub are safe). It shouldn't be possible to make these workflows use the credentials for anything they aren't intended for, right?

That being said, another option might be to somehow use Jenkins but this would also not solve the credential issue.

All in all, I also don't know whether it would be better or not but having this discussion and potentially finding alternative solution (like approving some workflows automatically if e.g. no .github/ and maybe also certain other files (e.g. pom.xml) are modified) would be better than ignoring this.
Keeping it in a way that committers have to approve the workflow might be ok as well if this can happen reasonably fast (within a few days, at least for the initial version) for most projects.