OSOE-769: Trigger validate-pull-request on pull_request_target

[Piedone]

Fixes #304
OSOE-769

[coderabbitai]

Walkthrough

Walkthrough

The modifications across various GitHub Actions workflows and actions aim to enhance automation around pull requests, particularly those originating from forks. By switching triggers from pull_request to pull_request_target, the workflows gain the ability to run without requiring approval for forked repositories. Additionally, updates to actions enhance issue and pull request management by improving title and description handling, and removing unnecessary checks.

Changes

File Path	Change Summary
.github/actions/check-merge-conflict/action.yml	Removed a conditional check to allow the action to run for PRs from forks.
.github/actions/update-github-issue-and-pull-request/action.yml	Updated action description and removed an outdated option.
.github/workflows/validate-pull-request.yml, .github/workflows/validate-submodule-pull-request.yml, .github/workflows/validate-this-pull-request.yml	Changed trigger from pull_request to pull_request_target and updated references for actions to specific versions or branches.
Docs/Workflows/Productivity/ValidatePullRequest.md, Docs/Workflows/Productivity/ValidateSubmodule.md	Documentation updated to reflect the change in trigger event from pull_request to pull_request_target.

Assessment against linked issues

Objective	Addressed	Explanation
Trigger validate-pull-request on pull_request_target (OSOE-769)	✅
Adjust the check-merge-conflict action to support PRs from forks	✅
Use the pull_request_target trigger for better compatibility with forks without needing approval	✅
Update documentation to reflect the change in trigger event	✅

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

---

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit-tests for this file.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit tests for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository from git and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit tests.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• The JSON schema for the configuration file is available here.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

[BenedekFarkas]

Wouldn't these changes prevent our team members from testing their own PRs' changes to the validate(-submodule)-pull-request workflow?

[Piedone]

Yes, for testing those you'd need to change the trigger. There's unfortunately no way around this.

[BenedekFarkas]

OK, I'm trying to picture in my head what the effect of this will be exactly. If all the triggers are updated, including validate-pull-request in OSOCE and validate-this-pull-request in LGHA, then changes made to those can't be tested in a PR at all. Is that right?

For example, if I work on the validate-pull-request reusable workflow, I'd also update the branch references in the workflows that call it, including in OSOCE in LGHA, but this way OSOCE and LGHA will still run on the target (usually default branch).

Can this be circumvented by making changes (with malicious intent to extract a secret/token) by opening a second PR that targets my first one with the bad code?

[Piedone]

Those changes won't be possible to test without doing anything, but will be possible to test after changing the workflow's trigger from pull_request_target to pull_request (and possibly this and this too, but you'll need to change opened here anyway unless you want to open a new PR for every test run).

I guess so, yes, an external actor can open a PR targeting an issue branch that has the pull_request trigger like this. However, just as with PRs today, the workflow there wouldn't run until one of our team members goes there and approves the run.

The point of these changes is to allow running Validate Pull Request right when opening the PR (i.e. without anybody clicking the "Approve and run" button there) even for external contributors. This wouldn't be safely possible with pull_request (since that would run the workflow code in the PR) and thus GitHub doesn't allow it. It is safe though with pull_request_target (since that runs the workflow code of the target branch, but only if the target branch already uses pull_request_target).

[BenedekFarkas]

but only if the target branch already uses pull_request_target

OK, thanks, this was the missing piece for me.