DOCS-1627 - Add GitHub Action to enforce weekend merge window

[kimsauce]

Purpose of this pull request

This pull request adds a GitHub Actions workflow that enforces Sumo Logic's merge window policy for the main branch, with two enforcement tiers matching Mark's policy (section 2a/2b).

Merge window policy:

Backend site changes (workflows, config, src/, sidebars.ts, package.json, yarn.lock, etc.):

• Hard block — no merges outside 7:00 am–2:00 pm PT, Monday–Friday
• US-only window (India is not staffed for outage response)
• No merges on weekends or Sumo holidays (USA + Global Quarterly Wellness Days)
• Exceptions for active service incidents or outages only — apply the active-incident label and re-run the check

Docs and release notes (docs/, blog-*, static/img/):

• Soft warning only — check passes and merge is allowed
• Warning shown if outside both India (8:00 am IST+) and US (7:00 am–2:00 pm PT) business hours
• Should generally merge during India or US business hours unless by prior arrangement

Mixed PRs (backend + docs files): backend site change rules apply.

How it works:

• The merge window check in pr.yml runs on every PR push
• Fetches the PR's changed files to determine enforcement tier
• Backend site change window: Mon–Fri, 7:00 am–2:00 pm PT, non-holidays
• Holiday list covers USA and Global Quarterly Wellness Days for 2026–2027; India holidays used for the article warning only. Update annually (see DOCS-1703)
• If the holiday list expires, the check fails loudly until updated

Override (active-incident label):
For active service incidents or outages only. Apply the label to the PR and re-run the merge window check from the PR checks UI.

Impact on existing open PRs:
Once the branch protection rule is updated, all open PRs targeting main will be blocked until the merge window check has run and passed. For PRs with no new commits, the check will show as "Expected" (never run) and GitHub will block the merge. To unblock, push any new commit to the branch.

One-time setup required after merging:

1. Create an active-incident label in the repo (Settings > Labels) — for active service incidents/outages only
2. Add merge window as a required status check in the branch protection rule for main

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

[mafsumo]

Reviewed the implementation against the Docs Site Change Policy. Overall this aligns well — notes below.

What was checked

Area	Result
Site change hard block (after 2:00 pm PT, weekends, holidays)	✅ Matches policy section 2a
Article/docs soft warning (India + US hours)	✅ Matches policy section 2b
active-incident label override for incidents only	✅ Matches policy section 2a.iii
Holiday coverage (US + Global QWDs for PT block; India + Global QWDs for IST warning)	✅ Correct split
Hard fail when holiday list expires	✅ Good safeguard
Mixed PRs (backend + docs files) → backend rules apply	✅ Correct

Two small items to address

1. HOLIDAYS_VALID_THROUGH_YEAR constant vs. holiday set coverage
HOLIDAYS_VALID_THROUGH_YEAR = 2026 causes the expiry check to fire on any date in 2027 — including 2027-01-01, which is already in both holiday sets. That entry is unreachable dead code. Either bump the constant to 2027 (to match the stated "covers 2026–2027" in the PR description), or remove the 2027-01-01 entries from the sets. Either way they should be consistent.

2. static/img/ classified as article-level content
The Confluence policy lists static/ broadly as a mission-critical path under the site change scope. The Action carves out static/img/ specifically and gives it the softer article-level treatment (warning only, no block). Other paths under static/ (non-image files) would still trigger the hard block, so the blast radius is narrow — but it does diverge from the policy text. Worth a quick confirmation that images-only is the intended exception.

---

Re: point 1 (7:00 am PT start time): The policy previously only stated a 2:00 pm cutoff. The Confluence page has been updated to reflect the full merge window: 7:00 am–2:00 pm Pacific, Monday–Friday

Additional notes

Backend site change file paths — @vfalconi for sign-off
We may want to have @vfalconi review the PR's definition of "Backend site changes" (the file path patterns that trigger the hard block) to sign off on that aspect of it.

Testing before going live
The branch protection rule (making merge window a required status check) is a separate one-time step after merge, so there's a natural window to validate first:

1. Merge this PR — the Action will run on every subsequent PR but won't block anything yet
2. Open a test PR that touches a backend file (e.g. a blank line added to package.json) outside the merge window hours — either after 2:00 pm PT on a weekday, or over a weekend
3. Confirm the merge window check appears in the PR's checks UI and shows as failed with the expected message
4. Also test a docs-only PR outside hours to confirm it passes with a warning (not a block)
5. Once both cases check out, add merge window as a required status check in the branch protection rule for main

This way the Action's behavior is verified in production conditions before it can actually block anyone.

— via Claude Code

[kimsauce]

Thanks for the thorough review, @mafsumo!

Fix 1 — HOLIDAYS_VALID_THROUGH_YEAR / dead code
Resolved by removing 2027-01-01 from both PT_HOLIDAYS and IST_HOLIDAYS. The constant stays at 2026, so the expiry check fires cleanly at the start of 2027 with no unreachable entries.

Fix 2 — static/img/ as article-level
The static/img/ exception is intentional. Images are tightly coupled to article PRs (screenshots, diagrams), so blocking them outside the site change window would hold up doc merges unnecessarily. Crucially, image-only changes carry no backend risk — they don't affect routing, config, or build behavior. Other files under static/ (e.g. llms.txt, robots.txt) remain in the hard-block scope.

Backend file path classification — @vfalconi
Agreed that @vfalconi should confirm whether the current pattern list that defines "backend site changes" covers the right paths (and doesn't catch anything it shouldn't). The patterns currently triggering the hard block are everything not matching docs/, blog-*, or static/img/ — so effectively: workflows, config, src/, package.json, sidebars.ts, docusaurus.config.js, static/ non-image files, etc. @vfalconi — does that scope look right to you?

— via Claude Code

[vfalconisumo]

Hi y'all.

I don't see any issues with the patterns in the backend change block.

My read from that section of the check is that hasSiteChange will be true if any files in the PR match the regexes in ARTICLE_PATTERNS. If a PR has anything other than content changes, the PR will be blocked.

One thing did jump out at me:

Crucially, image-only changes carry no backend risk — they don't affect routing, config, or build behavior.

If I recall correctly, a PR that changes only an image will result in a failed workflow because changing the image file does not change the build output. If the build output is the same, the workflow fails because there's "nothing to commit" according to Git.

I could be wrong, but if y'all haven't tested an image-only change with this, it might be worth confirming.

Side note, please make sure to use vfalconisumo when tagging me in a comment or assigning a review. vfalconi is my personal GH account and I'm not guaranteed to see the notification. 😄

[kimsauce]

Hi y'all.

I don't see any issues with the patterns in the backend change block.

My read from that section of the check is that hasSiteChange will be true if any files in the PR match the regexes in ARTICLE_PATTERNS. If a PR has anything other than content changes, the PR will be blocked.

One thing did jump out at me:

Crucially, image-only changes carry no backend risk — they don't affect routing, config, or build behavior.

If I recall correctly, a PR that changes only an image will result in a failed workflow because changing the image file does not change the build output. If the build output is the same, the workflow fails because there's "nothing to commit" according to Git.

I could be wrong, but if y'all haven't tested an image-only change with this, it might be worth confirming.

Side note, please make sure to use vfalconisumo when tagging me in a comment or assigning a review. vfalconi is my personal GH account and I'm not guaranteed to see the notification. 😄

Hi @vfalconisumo, thank you for the feedback, and apologies for the previous tagging error! I’m glad the pattern logic is correct. For your concern about image-only PRs potentially hitting a "nothing to commit" failure - I've opened a test, image-only PR (#6805). Once the merge window GHA is live, I'll put through it to confirm the static/img/ exception works as expected and doesn't cause any build issues. Could you both approve so we can move forward with the test? @mafsumo

[kimsauce]

@vfalconisumo @mafsumo Good news! The image-only PR #6805 merged and the updated screenshots are live on the site, which addresses the concern about image-only PRs causing a "nothing to commit" build failure. Static images are included in Docusaurus's build output, so they do produce a changed build when updated.

So once you've approved this PR, I'll merge this and then run tests to confirm it works.

[vfalconisumo]

@kimsauce That's great!