elastic / elastic/ai-github-actions

[product-manager-impersonator] Fail-fast compile mode for workflow generation

Open
#899 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.