Expose New Relic's vale linter action and styles as a public GitHub Action

[kaylareopelle]

Is your feature request related to a problem? Please describe

As a New Relic agent engineer, I would like the docs written within my repo to match the corresponding docs on the docs-website so that customers can read consistent content.

I attempted to add the vale-linter to the newrelic-ruby-agent's repo. During this process, I realized there's a lot of configuration in the docs-website in both .github/styles/* and the vale.ini files. I abandoned this attempt once I realized I needed to keep these styles in sync, which seemed very error-prone.

The Ruby agent writes release notes in our repository at the file CHANGELOG.md, and copies/pastes the content into a new .mdx file within a release notes directory on the docs-website.

Our current process is:

• write the CHANGELOG as we merge PRs
• review the CHANGELOG before release
• copy the content
• paste it into a new .mdx file in the docs-website repo within the release notes directory
• CI build fails with vale linter suggestions
• Address those suggestions and get the linter to pass on the docs-website
• Copy/paste the changes back into the Ruby agent's CHANGELOG.md as a new PR

Rather than receiving edits only when starting a release, I'd like to get these recommendations as we go.

Describe the solution you'd like

I'd like the docs team to expose the vale linter action with the styles in the .github/styles directory as a GitHub action in a separate repo so that I can include it in my repository's workflow.

I think the vale.ini file could be set on a per-repo basis (since we don't have .mdx files or the same file paths that need reviewing). If there's a way to include the content that would remain consistent outside this repo, that'd be awesome. The less copy/paste/checking I need to do to keep our styles in sync with the docs-website, the better!

However, the vale.ini file would probably be a little different for the Ruby agent. We'd want to check .md files and a few select .rb files that generate content for other docs pages.

Describe why this important to you

• I like the suggestions vale makes and want to receive them for all the content we write in our repo
• Backfilling content takes time, I'd rather get things right the first time
• Backfilling content is error-prone; without having synced actions, we'll likely have docs-website release notes that look different from the release notes on our repo. Customers look at both sources. I want to give them a consistent experience

Additional context

There may be more agent teams interested in an action like this. Happy to help gather interest.

[github-actions]

Hi @kaylareopelle 👋

Thank you for filing an issue! We'll triage your issue and let you know if we have questions, and then route it to the appropriate team so we can get it solved.

[rhetoric101]

@kaylareopelle our docs developers will chat with you about this in the meeting they've scheduled with you.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be automatically closed if no further activity occurs. Thank you for your contributions.

[kaylareopelle]

Our release process has changed a bit, we now use a GitHub bot to create our release notes, so we're no longer backporting changes from the docs website to our repo's changelog. I think this would still be helpful, but I've been fine without it, so feel free to close.

[kaylareopelle]

The Ruby agent team encountered a problem today when our automated release notes PR CI failed the Vale linter job. There might be some more significant issues with the Vale linter job because it included results from many files not changed as part of this PR.

If, one day in the future, Vale linter offenses block PR merges, having access to the linter and styles through a public GitHub action would be immensely helpful so that we can catch the issues the linter finds while we're writing our changelog and not after the automated PR is opened.

[paperclypse]

@roadlittledawn This one's been hanging out for a while. I wanted to make sure you saw it again.