Not secure

See PoC: https://github.com/Inverle/gha-testing/pull/2

Reasons:

1. contents: read wouldn't work, meaning you have to downgrade security by setting contents: write instead (there isn't a permission for allowing writing only to a PR)
2. github-script isn't safer than calling a bash script, because it's just a node process with a INPUT_GITHUB-TOKEN environment variable passed which contains the GITHUB_TOKEN
   specifically: /home/runner/actions-runner/cached/externals/node24/bin/node /home/runner/work/_actions/actions/github-script/v8/dist/index.js
3. and other steps are also just another bash/node process in the context of the runner user which can read each others environment variables via /proc/XXX/environ

https://github.com/actions/github-script/blob/ed597411d8f924073f98dfc5c65a23a2325f34cd/action.yml#L13
https://github.com/actions/github-script/blob/ed597411d8f924073f98dfc5c65a23a2325f34cd/action.yml#L38-L40

Get PR details and security doesn't seem to be improving security either,

There are probably 2 approaches for doing this safely then:

• Restricting the command only to owners and members of the repo (and checking PR contents before running the command) - easier
• Running the checkout step and make fix-all command in a container then copying the changed files over back to the host, then making a commit (still hard to get this right, not sure if possible)

I was hopping to be able to find the right permissions to have something simpler, but maybe a GitHub Bot would actually be needed

but maybe a GitHub Bot would actually be needed

this way?
https://docs.github.com/en/apps/creating-github-apps

Yes, a bit like Dependabot

I don't know, just as a user isn't it nicer to double check the automated changes before committing? Or do people completely ignore GH sending emails saying the action failed?

Also there's a big risk it'd cause me conflicts. I have to say I'm not fond of some annoying automated bot or action at all really, but maybe that's just me.

The idea would still be to react on /fix-all, not to be automatic.
For users using the edit button of the Web interface to translate something of propose a fix, having to run something locally is an order of magnitude more challenging. We offer a Dev Container in the Web browser, but that is still more complicated than fixing things directly from the comment thread.

We could also reconsider how this readme with i18n is working, as it creates almost systematic merge conflicts and test failures.

For that specifically I'd just update it automatically after a commit on edge, triggered by having touched a file in the translations folder.

Although that could result in many more commits, so possibly never mind.

For that specifically I'd just update it automatically after a commit on edge, triggered by having touched a file in the translations folder.

So to refine that idea, a "cron" job[1] that runs every three days or less that checks for example git log -1 --format="%ct" -- app/i18n/ vs the README. Or maybe something even simpler would suffice. It doesn't matter, the point is that if app/i18n/ is newer than README.md, update the README with the new status (IF it actually results in a file change of course).

[1] It uses the same syntax anyway.

For that specifically I'd just update it automatically after a commit on edge, triggered by having touched a file in the translations folder.

So to refine that idea, a "cron" job[1] that runs every three days or less that checks for example git log -1 --format="%ct" -- app/i18n/ vs the README. Or maybe something even simpler would suffice. It doesn't matter, the point is that if app/i18n/ is newer than README.md, update the README with the new status (IF it actually results in a file change of course).

[1] It uses the same syntax anyway.

Yes, that could be fine. See example:

• https://github.com/FreshRSS/Extensions/blob/master/.github/workflows/generate.yml