-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Repeatable error messages for metric documentation checks #28034
Conversation
…sing documentation error messages are produced in a predictable and repeatable order. This is really helpful when someone is trying to fix multiple issues and wants to make sure a specific issue is fixed before moving one to the next one. Otherwise, the errors are thrown in a random order and every time a new message is presented to the developer making it very confusing if the previous one had been resolved or not.
Pinging @elastic/agent (Team:Agent) |
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
🤖 GitHub commentsTo re-run your PR in the CI, just comment with:
|
This pull request does not have a backport label. Could you fix it @kovyrin? 🙏
NOTE: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix.
* Sort all keys before checking them for documentation to make sure missing documentation error messages are produced in a predictable and repeatable order. This is really helpful when someone is trying to fix multiple issues and wants to make sure a specific issue is fixed before moving one to the next one. Otherwise, the errors are thrown in a random order and every time a new message is presented to the developer making it very confusing if the previous one had been resolved or not. (cherry picked from commit a07837e)
* Sort all keys before checking them for documentation to make sure missing documentation error messages are produced in a predictable and repeatable order. This is really helpful when someone is trying to fix multiple issues and wants to make sure a specific issue is fixed before moving one to the next one. Otherwise, the errors are thrown in a random order and every time a new message is presented to the developer making it very confusing if the previous one had been resolved or not. (cherry picked from commit a07837e)
…28190) * Sort all keys before checking them for documentation to make sure missing documentation error messages are produced in a predictable and repeatable order. This is really helpful when someone is trying to fix multiple issues and wants to make sure a specific issue is fixed before moving one to the next one. Otherwise, the errors are thrown in a random order and every time a new message is presented to the developer making it very confusing if the previous one had been resolved or not. (cherry picked from commit a07837e) Co-authored-by: Oleksiy Kovyrin <[email protected]> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
) * Sort all keys before checking them for documentation to make sure missing documentation error messages are produced in a predictable and repeatable order. This is really helpful when someone is trying to fix multiple issues and wants to make sure a specific issue is fixed before moving one to the next one. Otherwise, the errors are thrown in a random order and every time a new message is presented to the developer making it very confusing if the previous one had been resolved or not.
What does this PR do?
Extracted from a WIP PR: #27549
Sort all keys before checking them for documentation to make sure missing documentation error messages are produced in a predictable and repeatable order.
Why is it important?
This is really helpful when someone is trying to fix multiple issues and wants to make sure a specific issue is fixed before moving one to the next one. Otherwise, the errors are thrown in a random order and every time a new message is presented to the developer making it very confusing if the previous one had been resolved or not.
Checklist
I have made corresponding changes to the documentationI have made corresponding change to the default configuration filesI have added an entry inCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Author's Checklist
How to test this PR locally
fields.yml
file)make update
for the given modulemake update