chore: fix: event trigger label conflict

[ddevsr]

Description
Based on https://github.com/actions/labeler#permissions and https://github.com/prince-chrismc/label-merge-conflicts-action#faq---how-do-i-fix-resource-not-accessible-by-integration must using event pull_request_target

In order to add labels to pull requests, the GitHub labeler action requires write permissions on the pull-request. However, when the action runs on a pull request from a forked repository, GitHub only grants read access tokens for pull_request events, at most. If you encounter an Error: HttpError: Resource not accessible by integration, it's likely due to these permission constraints. To resolve this issue, you can modify the on: section of your workflow to use pull_request_target instead of pull_request (see example above). This change allows the action to have write access, because pull_request_target alters the context of the action and safely grants additional permissions.

Follow-up #7928

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[kenjis]

using the (potentially dangerous) event pull_request_target
https://github.com/prince-chrismc/label-merge-conflicts-action#faq---how-do-i-fix-resource-not-accessible-by-integration

GitHub workflows can be triggered through a wide variety of repository events. This includes events related to incoming pull requests (PR). There exists a potentially dangerous misuse of the pull_request_target workflow trigger that may lead to malicious PR authors (i.e. attackers) being able to obtain repository write permissions or stealing repository secrets.
TL;DR: Combining pull_request_target workflow trigger with an explicit checkout of an untrusted PR is a dangerous practice that may lead to repository compromise.
https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

Are you sure that this PR is safe?
pull_request_target is dangerous.

[paulbalandan]

I would not advocate to use pull_request_target as it makes the PR vulnerable.

[kenjis]

If we use pull_request_target, and If the secrets of this repository were to be obtained by an attacker through PR, it would be a major security incident.

[datamweb]

Anyway, the Member adds the label stale. I think similar to smart commenting safely.

[ddevsr]

I admit that pull_request_target is dangerous. I will use sample from @datamweb, labeling manually but commenting with automation

[paulbalandan]

@ddevsr can you try putting the permissions inside the specific job instead of outside? also change the token to ${{ secrets.GITHUB_TOKEN }}. although they're the same

[ddevsr]

@kenjis @paulbalandan @datamweb I already change to implement smart commenting codeigniter4/shield#812

[ddevsr]

@paulbalandan @kenjis I tested with result Resource not accessible by integration again

https://github.com/codeigniter4/CodeIgniter4/actions/runs/6193689315/job/16815562654?pr=7936

[paulbalandan]

try add contents: write permission

[ddevsr]

https://github.com/codeigniter4/CodeIgniter4/actions/runs/6193902891/job/16816111260?pr=7936

Setup job still permission PullRequests: read

[kenjis]

Because you sent the PR from your repository.
This workflow does not work if it is merged.

[ddevsr]

https://github.com/orgs/community/discussions/63736

Give permissions above if conditions.

@kenjis Oh, okay

[kenjis]

Now let's merge and test.

[kenjis]

Should be?

on:
  pull_request:
    types:
      - labeled