[errose28]

DRAFT until 2.3.0 is released with initial ZDU support and apache/ozone-site#560 is merged

What changes were proposed in this pull request?

Add a regex based script that inspects git diffs and warns if they contain potentially incompatible changes. When the script is triggered on a PR, it will add a comment if any patterns match potentially incompatible changes. This just a "heads up" and will produce false positives which can be ignored. It has no bearing on the merge-ability or CI status of the PR.

The script is triggered by a github action modeled after the existing label-pr workflow, where PRs are periodically scanned and updated in batches. The script has handling to avoid duplicate comments when either the PR content or the warnings do not change between runs. The workflow can also be triggered manually, with an option to run it against all PRs in the queue, or just those updated within the last 2 hours.

This workflow and the existing label-pr workflow are now triggered in the same spot at the same interval. Currently it seems simpler to have one dispatcher for all periodic scan tasks like this, although we could optionally create one dispatcher per workflow.

Jira Link

HDDS-17252

How was this patch tested?

• Detection shell script:
  • bats test added to test the shell script's output against real commits in the history
  • Manual runs of the script against diffs locally
• Github actions automation: A modified version of this workflow was run against two fake PRs in my fork
  • This one did not get a warning
  • This one did get a warning

[adoroszlai]

Thanks @errose28 for the patch. I'll review in detail, some questions/thoughts up front:

• This approach could be used to set PR CI status from contributor fork (to replace pull_request triggered runs), which does not need to wait for the ZDU specific conditions (2.3.0 release, docs update). Adding a marker to distinguish github-bot comments for various purposes is a great idea.

• As the number of items to check periodically for PRs may increase in the future, the current approach iterating PRs in separate jobs may not scale. Should PRs be iterated once to execute various scripts on each (i.e. should the dispatcher be at the shell-script level instead of in the workflow)? (Edit: I realized labeler is an action, not a script, so this is not applicable to that workflow.)

• We could store state between runs using Apache Infra's Stash action. I think it would help reduce API calls like comments listing.