[infra] Update documentation (new coverage screenshots + some cleanup), follow-up #1839).

5 files changed, 8 insertions, 8 deletions

diff --git a/docs/fuzzer_environment.md b/docs/fuzzer_environment.md
index e4c9bfa7..e0e7f2cc 100644
--- a/docs/fuzzer_environment.md
+++ b/docs/fuzzer_environment.md
@@ -6,9 +6,9 @@ Your fuzz targets will be run on a [Google Compute Engine](https://cloud.google.
 
 You should not make any assumptions on the availability of dependent packages 
 in the execution environment. Packages that are installed via
-[Dockerfile](https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md#dockerfile)
+[Dockerfile](new_project_guide.md#dockerfile)
 or built as part of 
-[build.sh](https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md#buildsh)
+[build.sh](new_project_guide.md#buildsh)
 are not available on the bot runtime environment (where the fuzz targets run).
 
 If you need these dependencies in the runtime environment, you can either
@@ -17,7 +17,7 @@ If you need these dependencies in the runtime environment, you can either
 and then link statically against them
 ([example](https://github.com/google/oss-fuzz/blob/master/projects/tor/build.sh#L40))
 - Or build the dependencies statically in
-[build.sh](https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md#buildsh)
+[build.sh](new_project_guide.md#buildsh)
 ([example](https://github.com/google/oss-fuzz/blob/master/projects/ffmpeg/build.sh#L26)).
 
 All build artifacts needed during fuzz target execution should be inside the `$OUT`
diff --git a/docs/ideal_integration.md b/docs/ideal_integration.md
index 6c5a2f1a..d53c469c 100644
--- a/docs/ideal_integration.md
+++ b/docs/ideal_integration.md
@@ -101,11 +101,11 @@ The syntax is described [here](http://libfuzzer.info/#dictionaries).
 
 ## Coverage
 For a fuzz target to be useful, it must have good coverage in the code that it is testing. You can view the coverage
-for your fuzz targets by looking at the [fuzzer stats](https://github.com/google/oss-fuzz/blob/master/docs/clusterfuzz.md#fuzzer-stats) dashboard on ClusterFuzz, as well as
-[coverage reports](https://github.com/google/oss-fuzz/blob/master/docs/clusterfuzz.md#coverage-reports).
+for your fuzz targets by looking at the [fuzzer stats](clusterfuzz.md#fuzzer-stats) dashboard on ClusterFuzz, as well as
+[coverage reports](clusterfuzz.md#coverage-reports).
 
 To generate an aggregated code coverage report for your project, please see
-[code coverage](https://github.com/google/oss-fuzz/blob/master/docs/code_coverage.md)
+[code coverage](code_coverage.md)
 documentation page.
 
 Coverage can often be improved by adding dictionaries, more inputs for seed corpora, and fixing
@@ -114,7 +114,7 @@ timeouts/out-of-memory bugs in your targets.
 ## Performance
 Fuzz targets should also be performant, as high memory usage and/or slow execution speed can slow the down
 the growth of coverage and finding of new bugs. ClusterFuzz provides a
-[performance analyzer](https://github.com/google/oss-fuzz/blob/master/docs/clusterfuzz.md)
+[performance analyzer](clusterfuzz.md)
 for each fuzz target that shows problems that are impacting the performance of the fuzz target.
 
 ## Example
diff --git a/docs/images/freetype_coverage_1.png b/docs/images/freetype_coverage_1.png
index 9ff5af8f..5fcd4e8c 100644
--- a/docs/images/freetype_coverage_1.png
+++ b/docs/images/freetype_coverage_1.png
diff --git a/docs/images/freetype_coverage_2.png b/docs/images/freetype_coverage_2.png
index 7b46a0bf..3448993c 100644
--- a/docs/images/freetype_coverage_2.png
+++ b/docs/images/freetype_coverage_2.png
diff --git a/docs/new_project_guide.md b/docs/new_project_guide.md
index 5782b2cf..fd12c716 100644
--- a/docs/new_project_guide.md
+++ b/docs/new_project_guide.md
@@ -87,7 +87,7 @@ Example: [boringssl](https://github.com/google/oss-fuzz/blob/master/projects/bor
 
 ### help_url
 Link to a custom help URL in bug reports instead of the
-[default OSS-Fuzz guide to reproducing crashes](https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md). This can be useful if you assign
+[default OSS-Fuzz guide to reproducing crashes](reproducing.md). This can be useful if you assign
 bugs to members of your project unfamiliar with OSS-Fuzz or if they should follow a different workflow for
 reproducing and fixing bugs than standard one outlined in the reproducing guide.