DOCS-1627 - Streamline PR checks workflow

[kimsauce]

Purpose of this pull request

Streamlines the Pull Request Checks workflow with several improvements:

• Merge window enforced at merge queue time — removed the if: github.event_name == 'pull_request' guard so the check runs during merge_group events (actual merge time), not just on PR open
• Remove cid-redirects.json from backend change category
• Scope link check and spellcheck to changed files only — both jobs now diff against origin/main and skip entirely when no docs files changed, instead of scanning all of docs/ on every run
• Null-delimited file handling — uses mapfile -d '' and xargs -0 throughout for safe handling of filenames with spaces
• Concurrency group — cancels stale in-progress runs when a new push is made, reducing queue buildup
• fetch-depth: 0 on build checkout — required for git diff in the link check step

Select the type of change

• Minor Changes - Typos, formatting, slight revisions
• Update Content - Revisions, updating sections
• New Content - New features, sections, pages, tutorials
• Site and Tools - .clabot, version updates, maintenance, dependencies, new packages for the site (Docusaurus, Gatsby, React, etc.)

Ticket (if applicable)

https://sumologic.atlassian.net/browse/DOCS-1627

[vfalconisumo]

Hi. Two things I think worth addressing:

1. The active-incident label check is a great idea, but I don't think it will actually bypass the merge-window because it runs after the merge-window check itself. I'd suggest nesting the logic for the override into the conditional used by the merge-window logic (lines 244-250), such that the flow goes:

if !siteBlockedReason, then merge window is open so return

if the context is merge_group, then if label is active_incident, bypass merge-window enforcement. else, enforce merge window

2. Line 21 labels this job as build-and-deploy, but it doesn't actually deploy anything. A clearer name will help prevent confusion if someone has to drop into the repo for support. Maybe change line 21 to run-build-checks?

[kimsauce]

Hi. Two things I think worth addressing:

1. The active-incident label check is a great idea, but I don't think it will actually bypass the merge-window because it runs after the merge-window check itself. I'd suggest nesting the logic for the override into the conditional used by the merge-window logic (lines 244-250), such that the flow goes:

if !siteBlockedReason, then merge window is open so return
if the context is merge_group, then if label is active_incident, bypass merge-window enforcement. else, enforce merge window

2. Line 21 labels this job as build-and-deploy, but it doesn't actually deploy anything. A clearer name will help prevent confusion if someone has to drop into the repo for support. Maybe change line 21 to run-build-checks?

@vfalconisumo Good catches! Can you let me know what you think of the fixes?

Applied changes

[vfalconisumo]

LGTM!