Pull request checks
When you raise a pull request (PR) with the opentelemetry.io repository a set of checks are executed. The PR checks verify that:
- You have signed the CLA
- Your PR successfully deploys through Netlify
- Your changes are compliant with our style guide
Note
If any of the PR checks fails, try to
fix content issues first by running
npm run fix:all locally.
You can also add the comment /fix:all to your PR. This will trigger the
OpenTelemetry Bot to run that command on your behalf and update the PR. Make
sure that you pull those changes locally.
Only if your issues persist, read below what the different checks do and how you can recover from a failed state.
Easy CLA
This check fails if you haven’t signed the CLA.
Netlify deployment
If the Netlify build fails, select Details for more information.
GitHub PR checks
To make sure that contributions follow our style guide we have implemented a set of checks that verify style guide rules and fail if they find any issues.
The following list describes current checks and what you can do to fix related errors:
TEXT linter
This check verifies that OpenTelemetry-specific terms and words are used consistently across the site.
If any issues are found, annotations are added to your files in the
files changed view of your PR. Fix those to turn the check green. As an
alternative, you can run npm run check:text -- --fix locally to fix most
issues. Run npm run check:text again and manually fix the remaining issues.
MARKDOWN linter
This check verifies that standards and consistency for Markdown files are enforced.
If any issues are found, run npm run fix:format to fix most issues. For more
complex issues, run npm run check:markdown and apply the suggested changes.
SPELLING check
This check verifies that all words are spelled correctly.
CSPELL check
This check will verify that all words in your cSpell ignore list are normalized.
If this check fails, run npm run fix:dict locally and push the changes in a
new commit.
FILENAME check
This check verifies that all files are formatted by prettier.
If this check fails, run npm run fix:format locally and push the changes in a
new commit.
FILE FORMAT
This check verifies that all file names are in kebab-case.
If this check fails, run npm run fix:filenames locally and push the changes in
a new commit.
BUILD and CHECK LINKS
This check builds the website and verifies that all links are valid.
To check links locally, run npm run check:links. This command also updates the
reference cache. Push any changes to the refcache in a new commit.
Fix 404s
You need to fix the URLs reported as invalid (HTTP status 404), by the link checker.
Handling valid external links
The link checker will sometimes get an HTTP status other than 200 (success) by servers that block checkers. Such servers will often return an HTTP status in the 400 range other than 404, such as 401, 403, or 406, which are the most common. Some servers, link LinkedIn, report 999.
If you have manually validated an external link that the checker isn’t getting a
success status for, you can add the following query parameter to your URL to
have the link checker ignore it: ?no-link-check. For example,
https:/some-example.org?no-link-check will be ignored by the link checker.
Maintainers can run the following script immediately after having run the link checker to have Puppeteer attempt to validate links with non-success statuses
./scripts/double-check-refcache-400s.mjs -f --max-num-to-update 99
This script also validates URL fragments, which the link checker doesn’t do.
WARNINGS in build log?
If this check fails, review the BUILD and CHECK LINKS log, under the
npm run log:check:links step, for any other potential issues. Ask maintainers
for help, if you are unsure how to recover.
Feedback
Was this page helpful?
Thank you. Your feedback is appreciated!
Please let us know how we can improve this page. Your feedback is appreciated!