]> git.apps.os.sepia.ceph.com Git - ceph.git/commitdiff
doc/dev: fix broken "make check" link
authorKefu Chai <kchai@redhat.com>
Fri, 4 Sep 2020 16:21:13 +0000 (00:21 +0800)
committerKefu Chai <kchai@redhat.com>
Sat, 5 Sep 2020 01:46:57 +0000 (09:46 +0800)
Signed-off-by: Kefu Chai <kchai@redhat.com>
doc/dev/developer_guide/basic-workflow.rst
doc/dev/developer_guide/tests-unit-tests.rst

index 177ae76a575d2eac32a3701eea176f965c635617..a21569da66fa01d8fdd0c6152f06eacfc86b1d23 100644 (file)
@@ -209,9 +209,9 @@ When your PR hits GitHub, the Ceph project's `Continuous Integration (CI)
 infrastructure will test it automatically. At the time of this writing
 (March 2016), the automated CI testing included a test to check that the
 commits in the PR are properly signed (see :ref:`submitting-patches`) and a
-`make check`_ test.
+:ref:`make-check` test.
 
-The latter, `make check`_, builds the PR and runs it through a battery of
+The latter, :ref:`make-check`, builds the PR and runs it through a battery of
 tests. These tests run on machines operated by the Ceph Continuous
 Integration (CI) team. When the tests complete, the result will be shown
 on GitHub in the pull request itself.
@@ -222,7 +222,7 @@ Refer to the chapters on testing for details.
 Notes on PR make check test
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The GitHub `make check`_ test is driven by a Jenkins instance.
+The GitHub :ref:`make-check` test is driven by a Jenkins instance.
 
 Jenkins merges the PR branch into the latest version of the base branch before
 starting the build, so you don't have to rebase the PR to pick up any fixes.
@@ -232,14 +232,14 @@ comment should contain the string "test this please". Since a human subscribed
 to the PR might interpret that as a request for him or her to test the PR,
 it's good to write the request as "Jenkins, test this please".
 
-The `make check`_ log is the place to go if there is a failure and you're not
-sure what caused it. To reach it, first click on "details" (next to the `make
-check`_ test in the PR) to get into the Jenkins web GUI, and then click on
+The :ref:`make-check` log is the place to go if there is a failure and you're not
+sure what caused it. To reach it, first click on "details" (next to the :ref:`make-check`
+test in the PR) to get into the Jenkins web GUI, and then click on
 "Console Output" (on the left).
 
 Jenkins is set up to grep the log for strings known to have been associated
-with `make check`_ failures in the past. However, there is no guarantee that
-the strings are associated with any given `make check`_ failure. You have to
+with :ref:`make-check` failures in the past. However, there is no guarantee that
+the strings are associated with any given :ref:`make-check` failure. You have to
 dig into the log to be sure.
 
 Integration tests AKA ceph-qa-suite
@@ -354,6 +354,3 @@ the **ptl-tool** have the following form::
              client: move client_lock to _unmount()
              client: add timer_lock support
      Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
-
-
-.. _make check:
index 315811e69676591e9b3889ae7285824dbf9f4c23..fdaa1b85a9fe4159a7808051a4756722577eb6dc 100644 (file)
@@ -7,6 +7,8 @@ tests", but rather tests that can be run easily on a single build machine
 after compiling Ceph from source, whereas integration tests require packages
 and multi-machine clusters to run.
 
+.. _make-check:
+
 What does "make check" mean?
 ----------------------------