elastic / elastic/ai-github-actions
[product-manager-impersonator] Fail-fast compile mode for workflow generation
- Dominant language
- Python
- Stars
- 11
- Forks
- 16
- Avg merge
- 22h 9m
- Merged PRs (30d)
- 31
Description
## Feature Idea
**Summary:** Add a strict compile mode so `make compile` fails immediately when `gh-aw compile` fails, instead of continuing and hiding the failure.
## Why a Customer Would Want This
Workflow maintainers depend on `make compile` as the canonical "source → generated lock files" step. If compile errors are ignored, maintainers can see confusing downstream failures or drift and spend extra time debugging what looked like a successful compile run.
## Rough Implementation Sketch
- Add a strict compile path in `Makefile` (either `compile-strict` or default `compile`) that removes the error-ignoring `-` prefix from the `gh-aw compile` invocation.
- Keep current behavior available behind an explicit opt-in (for example `compile-best-effort`) if needed for local experimentation.
- Update CI to use the strict path when verifying generated workflows.
- Add a short docs note in workflow development docs clarifying that compile failures are now hard-fail by default.
## Why It Won't Be That Hard
This is a small, isolated change in existing plumbing: one Makefile target, one CI invocation, and one short docs update. The repo already has an established compile/verify pipeline, so this is mostly tightening failure behavior rather than introducing new architecture.
## Evidence
- `Makefile:170-173` currently runs compile with `-@.bin/gh-aw compile ...`, which explicitly ignores failures.
- `.github/workflows/ci.yml:56-64` relies on `make compile` before checking for dirty generated files.
- `gh-agent-workflows/DEVELOPING.md:146-148` expects maintainers to run `make compile` and verify `0 errors, 0 warnings`.
- `.github/workflows/upgrade-check.md:130` also instructs `make compile` with `0 errors, 0 warnings` as a gate.
> [!NOTE]
>
> 🔒 Integrity filter blocked 4 items
>
> The following items were blocked because they don't meet the GitHub integrity level.
>
> - elastic/ai-github-actions#704 `list_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".
> - [#623](https://github.com/elastic/ai-github-actions/issues/623) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#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".
>
> 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/24185253021)
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Contributor guide
Assessment
This issue has not been assessed yet.