I've been knee-deep in GitHub Actions workflows this week, building out a new CI/CD pipeline for a client's monorepo, and I noticed something interesting in the latest updates. GitHub has quietly but significantly expanded the native Actions annotations you can generate from within a workflow run. Specifically, the `echo "::error file=app.js,line=10,col=15::Something went wrong"` syntax now officially supports `warning`, `notice`, and `error` annotations that render directly on the Pull Request files view.
This immediately made me think of plugins like `reviewdog`, `super-linter`, and `eslint-action`. Their primary value proposition, beyond just running the linter, has been to take the output and post it as review comments or annotations. Now that GitHub provides a native, first-party path for this, I'm doing a deep dive to see if the plugin ecosystem still holds an edge.
Here’s a quick comparison of the native method versus a typical plugin approach:
**Native GitHub Annotations (via workflow commands):**
```yaml
- name: Run ESLint and annotate
run: |
eslint --format json src/ > eslint_results.json
cat eslint_results.json | jq -r '.[] | "::warning file=(.filePath),line=(.line),col=(.column)::(.message) [(.ruleId)]"' >> $GITHUB_ENV
```
**Traditional Plugin Approach (using `reviewdog/action-eslint`):**
```yaml
- name: Run reviewdog with ESLint
uses: reviewdog/action-eslint@v1
with:
reporter: github-pr-review
level: warning
```
The native approach gives you direct control and eliminates a third-party dependency, which simplifies your `yaml` file. However, after some testing, I've found the plugins still bring considerable advantages:
* **Multi-reporter support:** Plugins like `reviewdog` can output to GitHub Checks, PR reviews, or even Slack/Datadog, not just file annotations.
* **Advanced filtering & Deduplication:** They often include logic to filter out known noise, group similar issues, and avoid flooding the PR with identical comments.
* **Easier Setup for Complex Tools:** For linters/formatters that don't have a simple JSON or standard output, the plugin authors have already done the parsing work. You just feed the tool's stdout into the action.
* **Consistency Across CI Environments:** If you ever need to port a workflow to GitLab or another runner, a well-designed plugin can abstract the CI-specific annotation logic.
So, my current take is this: for simple, single-purpose linting where you only need GitHub file annotations, the native method is now a perfectly valid and lean option. But for teams that need richer feedback, use multiple linters, want PR review comments, or operate in a multi-CI environment, the dedicated plugins still provide significant workflow efficiency.
What's everyone else's experience? Have you started migrating any of your linting workflows to use native annotations, or are the plugins too feature-rich to give up?
api first
api first
Your deep dive is hitting on the right questions. The main edge of plugins like `reviewdog` isn't just annotation generation; it's the abstraction layer for parsing diverse linter outputs and the ability to post as persistent PR comments, not just ephemeral workflow annotations. Native commands are fantastic for inline run feedback, but they disappear after the run. For teams that rely on permanent, threaded comment histories for tracking recurring issues, that's a critical limitation.
The plugin ecosystem also standardizes the "run linter, parse output, report" pattern across dozens of linters without you having to write and maintain custom jq or awk scripts for each one. If your stack uses five different analysis tools, that's five custom parsing steps you now own.
Where I see native annotations winning is in simplicity for single-linter setups and in combining with plugins: use `reviewdog` with its `github-pr-check` reporter for permanent comments, but fall back to `github-check` or native echo commands for faster feedback within the check run UI itself. It becomes another tool in the matrix.
Totally agreed on the ephemeral nature of native annotations being a dealbreaker for some teams. That's exactly why we still use a plugin for our security scanning - we need those findings to stick around as PR comments for the audit trail.
You're right about the parsing abstraction too. I tried switching our Python and Go linters to native commands last month, and the custom script to unify their outputs was a mess I had to upkeep. It felt like building a worse version of reviewdog myself.
But I've found a nice hybrid: using native `::warning` for fast, in-line feedback during development, then having a separate, final "audit" step that uses the plugin to post the permanent summary comment. It gives devs instant feedback without cluttering the PR history with every single run.
cost first, then scale