elastic / elastic/ai-github-actions
[product-manager-impersonator] Backwards-compat rename map lint
- Dominant language
- Python
- Stars
- 11
- Forks
- 16
- Avg merge
- 22h 9m
- Merged PRs (30d)
- 31
Description
## Feature Idea
**Summary:** Add a focused lint check that validates deprecated lockfile rename mappings (script + generated files + upgrade docs) stay in sync to prevent avoidable CI drift failures.
## Why a Customer Would Want This
Maintainers and downstream users depend on old workflow names continuing to work while migrating. When rename mappings or generated compat copies drift, CI fails late and users get confusing breakage.
## Rough Implementation Sketch
- Add `scripts/check-backwards-compat.py` (or similar) that reads the mapping in `scripts/backwards-compat.sh` and validates each old/new pair has a real target lockfile.
- Verify each generated deprecated lockfile contains the expected deprecation header and old→new mapping string.
- Verify `docs/upgrading.md` rename bullets match the same mapping source.
- Wire the check into `make lint` and CI so drift fails with a targeted error before generic dirty-tree failures.
## Why It Won't Be That Hard
The mapping already exists in one script, generation already happens during `make compile`, and CI already runs compile/lint. This is an additive consistency validator over existing files and conventions.
## Evidence
- `scripts/backwards-compat.sh:17-33` defines the authoritative old→new rename arrays.
- `scripts/backwards-compat.sh:49-58` generates deprecated compatibility copies with header text.
- `Makefile:170-183` runs compile and then `./scripts/backwards-compat.sh`.
- `docs/upgrading.md:117-124` duplicates rename mappings in docs (manual drift risk).
- `.github/workflows/ci.yml:46-65` currently catches only generic dirty-tree state after compile, not targeted rename-map drift.
- Prior failure pattern: #517 (stale compat lock copy causing CI failure).
> [!NOTE]
>
> 🔒 Integrity filter blocked 3 items
>
> The following items were blocked because they don't meet the GitHub integrity level.
>
> - [#704](https://github.com/elastic/ai-github-actions/issues/704) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#424](https://github.com/elastic/ai-github-actions/issues/424) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#575](https://github.com/elastic/ai-github-actions/issues/575) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
>
> To allow these resources, lower `min-integrity` in your GitHub frontmatter:
>
> ```yaml
> tools:
> github:
> min-integrity: approved # merged | approved | unapproved | none
> ```
>
>
---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Trigger Product Manager Impersonator](https://github.com/elastic/ai-github-actions/actions/runs/24661728436)
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Contributor guide
Assessment
This issue has not been assessed yet.