Publish a GitHub Action that validates dotagent manifests in CI
- Dominant language
- Rust
- Stars
- 3
- Forks
- 1
- Avg merge
- 4h 50m
- Merged PRs (30d)
- 1
Description
As more people adopt dotagent and version their agents in git (the dotfiles use-case), CI needs to catch manifest mistakes before they hit production. Today the only way to validate is to install dotagent locally and run `dotagent doctor`.
A reusable GitHub Action would let anyone validate manifests on every PR without setting up Rust.
## Proposal
Publish a GitHub Action at `avelino/dotagent-validate-action` (or as a sub-action of this repo) that:
1. Downloads the latest released dotagent binary (or a pinned version).
2. Runs `dotagent doctor` against the repo's agents.
3. Surfaces errors and warnings as GitHub annotations on the PR.
Usage:
```yaml
- uses: avelino/dotagent/validate-action@v1
with:
root: ./agents
version: latest
fail-on: error # error | warning
```
## Acceptance criteria
- [ ] Action lives in `.github/actions/validate/` (or a sibling repo, implementer's call).
- [ ] Pinned to a release version by default; `latest` is opt-in.
- [ ] Cross-platform: works on `ubuntu-latest` and `macos-latest` runners.
- [ ] Errors become PR annotations on the relevant manifest line where possible.
- [ ] Documented in [`README.md`](README.md) Install section.
- [ ] Smoke-tested with a dummy bad manifest in a workflow.
## Where to start
- `crates/dotagent/src/commands/mod.rs::doctor` — already produces structured output.
- GitHub's [problem matcher format](https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md) for surfacing errors as annotations.
## Non-goals
- Auto-fix mode. Validation only.
- Running agents in CI. Just static manifest checks + plugin discovery.
Contributor guide
Research direction
Start with crates/dotagent/src/commands/mod.rs::doctor to understand its structured output, then review GitHub's problem matcher format. Implement the action in .github/actions/validate/ or a sibling repository, covering pinned versions, cross-platform runners, annotations, and the root and fail-on inputs. Document it in README.md and smoke-test it with a workflow using a dummy bad manifest.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, rust
- Domain
- ci-cd, devops
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100