Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
kaylareopelle opened this issue Feb 21, 2023 · 6 comments
Labels
eng issues related to site functionality that requires engineering enhancement New feature or request

Comments

@kaylareopelle
Copy link
Contributor

kaylareopelle commented Feb 21, 2023

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.

@kaylareopelle kaylareopelle added eng issues related to site functionality that requires engineering enhancement New feature or request labels Feb 21, 2023
@github-actions
Copy link

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
Copy link
Contributor

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

@stale
Copy link

stale bot commented Jun 18, 2023

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.

@stale stale bot added the stale label Jun 18, 2023
@kaylareopelle
Copy link
Contributor Author

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.

@stale stale bot removed the stale label Jun 21, 2023
@kaylareopelle
Copy link
Contributor Author

kaylareopelle commented Oct 30, 2023

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
eng issues related to site functionality that requires engineering enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants