xalvarez / prevent-file-change-action Goto Github PK

Is your feature request related to a problem? Please describe.
trustedAuthors input is only mentioned in the README but the document doesn't explain what this input is used for or what its format is.

Describe the solution you'd like
There's a brief explanation about what this input does and that its expected format is a comma separated list.

Describe alternatives you've considered
Perhaps there would be a more elegant way to document all inputs in a table but as there are only two inputs, that might be unnecessary.

Hi @xalvarez ,

this is just another tiny request, but not feature wise but for documentation.
I wanted to introduce your action to more repositories.

As you need a GITHUB_TOKEN for the workflow, it would be nice to build trust by documenting which exact permissions are required: https://docs.github.com/en/actions/security-guides/automatic-token-authentication

According to my check the only place where it is used is to read the list of all files changed in the PR:
https://github.com/xalvarez/prevent-file-change-action/blob/main/src/github-service.ts#L16
And probably the line to fail the job:
https://github.com/xalvarez/prevent-file-change-action/blob/main/src/main.ts#L29

The default permissive permission set is rather dangerous:
https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

So my request is: can you document the which permissions are exactly required for the Github token?

E.g.

permissions:
  contents: read
  pull-requests: read

And include those in the example in the README?

Is your feature request related to a problem? Please describe.
Using dependabot groups allows merging version bumps faster.

Describe the solution you'd like
There's a dependent group for npm, covering development dependencies only and minor and patch updates only.

Is your feature request related to a problem? Please describe.
Currently the action only trust PR authors. This means if somebody else commits to the PR even with trustedAuthors it will still fail the job.

so if user1 created PR but user2 commits to the affected file in his PR (and is trusted) the job fails
Would be easy to implement also trustedCommiter to this action?
So if commit inside of PR was created by this trustedCommiter it will not fail?

Describe the solution you'd like
It would be nice if we could specify also trustedCommiters

Describe alternatives you've considered
Creating separate action that will do check for modified files, who performed commit and then check if it is fine

Is your feature request related to a problem? Please describe.
This action runs on Node.js 20 and that isn't documented anywhere. That's relevant piece of information for contributors.

Describe the solution you'd like
The README mentions that in order to work on this project one requires Node.js 20. Perhaps one could mention that the Action itself runs on Node.js 20, if that's not too verbose.

Is your feature request related to a problem? Please describe.

When trying to run the workflow on push event, it gives the error saying only pull_request is supported.

Describe the solution you'd like

Can you also allow running it on push? Since a push event will also have changed files.

Describe alternatives you've considered

Additional context

Hi,

I was thinking about using your action to prevent someone from adding changed *.lock (eg. from yarn, packages, composer) to PRs. This should prevent that someone sneaks in new packages not updated by the core maintainer.

BUT: when I would now configure your action to fail on *.lock I wouldn't be able myself to create new PRs with updated dependencies. Or dependabot for example.

Not sure if your action was made to cover that use-case, but maybe you would consider to add a feature where certain users are allowed to override the pattern?

Not sure about the wording for the new setting I was thinking about, but I imagined something like that:

- name: Prevent file change
  uses: xalvarez/prevent-file-change-action@v1
  with:
    githubToken: ${{ secrets.GITHUB_TOKEN }}
    pattern: .*.lock
    maintainer: kevinpapst, xalvarez, dependabot

With that setting applied, the 3 users kevinpapst, xalvarez and dependabot would be allowed to pass the pattern rule.

What do you think?

Edit:

Or is there some other way to achieve the same goal with native Github actions features?

P.S: this is not a bug, the label was added automatically.