[CI] Support pathspec negation to sync issue-release-workflow.yml

[Navaneeth Shanmugasundaram (navaneethshan)]

Enable selective syncing of specific .github workflow files from upstream while ignoring others.

Changes:

• Modified automerge.py to support '!' negation patterns in pathspec file
• Added parse_pathspec_file() to parse ignore and keep patterns separately
• Updated cpullvm_modified_files to sync issue-release-workflow.yml from upstream
• All other .github/* files remain ignored (Qualcomm versions preserved)

This allows us to keep issue-release-workflow.yml in sync with upstream LLVM while protecting our custom workflows like nightly.yml, linux-premerge.yml, etc.

Signed-off-by: nshanmug nshanmug@qti.qualcomm.com

[Jonathon Penix (jonathonpenix)]

Will take a closer look later but two high-level/initial thoughts:

• We also use cpullvm_modified_files in .github/workflows/check_modified_files.yml (handled in qualcomm-software/ci/check_modified_files.py)--I think we might need changes of some sort in that workflow too?
  • At the time, I think I just did the check_modified_files.py assuming the file was just a list of files/directories. Not sure if adding the comments/pathspec stuff in the cpullvm_modified_files will cause any weird behavior?
  • Downstream changes to the issue-release-workflow.yml should still be allowed by check_modified_files.yml so I'm not sure we want to just add pathspec support into it. Maybe it's best just to use different files? Not sure
• More a side comment, but if we start merging changes into issue-release-workflow.yml (which seems reasonable to me), we'll be able to have conflicts when automerging in CPULLVM for the first time.
  
  Not sure how familiar people are with dealing with that in CPULLVM (I'm not)--we might want to be prepared for it at least.

[Jonathon Penix (jonathonpenix)]

Not sure how familiar people are with dealing with that in CPULLVM (I'm not)--we might want to be prepared for it at least.

Again this isn't really related to this PR itself, but turns out we have some stuff to fix re: handling conflicts, see #629