feat: add post-release check workflow [ED-25263]

[Svitlana-Dykun]

Summary

• Adds a dispatchable Post-Release Check workflow that verifies GitHub releases, changelog on main, wordpress.org SVN/Stable tag, and zip version headers for published Core (and optional Pro).
• Upgrade-path smoke (same idea as Core plugin-upgrade-test.yml): install current wordpress.org Elementor, import a heading page, --force install the released zip, then Playwright for frontend + create/edit canvas.
• PRs that touch this workflow/actions also run it against current wordpress.org Core so the pipeline is exercised before a real GA.

https://elementor.atlassian.net/browse/ED-25263

Test plan

• Open this PR and confirm Post-Release Check runs (verify + upgrade smoke) against current wordpress.org Core.
• After merge, dispatch the workflow with core_version=4.2.2 (Pro empty) and confirm the job summary checklist is green.
• Optional: dispatch with a Pro version once MAINTAIN_TOKEN can read elementor/elementor-pro releases.

Made with Cursor

✨ PR Description

1. Problem & Context

Post-release verification workflow needed: verify GitHub releases exist, changelogs updated on main/wordpress.org, and zip version headers match. Enables automated quality gates before announcing GA.

2. What Changed (Where)

Component	Purpose
actions/post-release-verify/	Core verification logic: GitHub API, changelog parsing, zip inspection, summary rendering
actions/post-release-smoke/	Playwright-based editor smoke tests post-upgrade from wordpress.org current
packages/editor-github-actions-utils/	Shared utilities: changelog/version parsing, plugin header extraction
.github/workflows/post-release-check.yml	Orchestration: resolves versions, runs verify, uploads zips, triggers smoke tests
stubs/upgrade-templates/	Test fixture: heading template for smoke test import

3. How It Works

Entry: Workflow triggered manually (core/pro versions) or on PR to detect current wordpress.org version.

Verify phase:

1. Fetch GitHub release → validate tag and zip asset exists
2. Fetch main branch changelog files → parse section for version
3. Fetch wordpress.org SVN readme → validate Stable tag and changelog (404 → skip, not fail)
4. Download and extract zips → verify Version header, PHP constants, readme tags match input

Smoke phase (if verify passes and zips available):

1. Start wp-env with current wordpress.org Elementor
2. Import heading template, upgrade to released zip, reactivate
3. Playwright: verify plugin versions on admin screen, existing content renders, editor loads on new/existing pages

Output: Job summary with check results (pass/fail/warn/skip), changelog excerpts, zip paths for downstream use.

4. Risks

• wordpress.org lag: SVN tag may not exist immediately post-release; handled via 404 → skip (not fail), fallback to GitHub zip.
• Private Pro releases: Requires PAT with repo scope; documented input notes token requirements.
• Playwright environment: wp-env and Chromium must be available; standard Actions runner, low risk.
• Timeout brittleness: Smoke tests use fixed timeouts (5s short, 30s long, 60s editor); could flake on slow CI runners — mitigated by single-worker, no-retry model.

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Description using Guidelines Learn how}

[wiz-9a149474ff]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	7  2
Sensitive Data	-
Secrets	-
IaC Misconfigurations	-
SAST Findings	14
Software Management Findings	-
Total	21  2

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try the Wiz Code extension for VS Code, JetBrains, or Visual Studio.