fix broken links

CLIMADA-project · Dec 8, 2023 · ec058fb · ec058fb
1 parent 1e7e9b4
commit ec058fb
Show file tree

Hide file tree

Showing 4 changed files with 26 additions and 18 deletions.
diff --git a/doc/guide/Guide_Git_Development.ipynb b/doc/guide/Guide_Git_Development.ipynb
@@ -232,7 +232,7 @@
    "source": [
     "- So for this a `release-*` branch is created from `develop`. We'll all be notified repeatedly when the deadline is to  submit (and then to review) pull requests so that you can be included in a release.\n",
     "- The core developer team (mostly Emanuel) will then make sure tests, bugfixes, documentation and compatibility requirements are met, merging any fixes back into `develop`.\n",
-    "- On release day, the release branch is merged into `main`, the commit is tagged as a release and the release notes are published on the GitHub at https://github.com/CLIMADA-project/climada_python/releases"
+    "- On release day, the release branch is merged into `main`, the commit is tagged as a release and the release notes are published on the GitHub at <https://github.com/CLIMADA-project/climada_python/releases>"
    ]
   },
   {
@@ -405,7 +405,7 @@
     "    git commit -m \"new functionality of .. implemented\"\n",
     "    \n",
     "### Make unit and integration tests on your code, preferably during development\n",
-    "see [Guide on unit and integration tests](../guide/Guide_Continuous_Integration_and_Testing.ipynb)\n"
+    "see [Guide on unit and integration tests](../guide/Guide_Testing.ipynb)\n"
    ]
   },
   {
@@ -476,7 +476,7 @@
     "- Tutorial (if a complete new feature)\n",
     "- Updated dependencies (if need be)\n",
     "- Added your name to the AUTHORS file\n",
-    "- Added an entry to the ``CHANGELOG.md`` file. See https://keepachangelog.com for information on how this shoud look like.\n",
+    "- Added an entry to the ``CHANGELOG.md`` file. See <https://keepachangelog.com> for information on how this shoud look like.\n",
     "- (Advanced, optional) interactively rebase/squash recent commits that _aren't yet on GitHub_.\n"
    ]
   },
@@ -532,7 +532,7 @@
     "   git push\n",
     "   ```\n",
     "\n",
-    "6) Check all the tests pass on the WCR Jenkins server (https://ied-wcr-jenkins.ethz.ch). See Emanuel's presentation for how to do this! You should regularly be pushing your code and checking this!"
+    "6) Check all the tests pass on the WCR Jenkins server (<https://ied-wcr-jenkins.ethz.ch>). See Emanuel's presentation for how to do this! You should regularly be pushing your code and checking this!"
    ]
   },
   {
@@ -588,7 +588,9 @@
     "11) Once everyone reviewing has said they're satisfied with the code you can merge the pull request using the GitHub interface.\\\n",
     "    Delete the branch once it's merged, there's no reason to keep it. (Also try not to re-use that branch name later.)\n",
     "    \n",
-    "12) Update the `develop` branch on your local machine."
+    "12) Update the `develop` branch on your local machine.\n",
+    "\n",
+    "Also see the [**Reviewer Guide**](../guide/Guide_Review.ipynb) and [**Reviewer Checklist**](../guide/Guide_Review.ipynb#reviewer_checklist)!"
    ]
   },
   {
@@ -659,7 +661,7 @@
    "source": [
     "### Commit message syntax guidelines\n",
     "\n",
-    "Basic syntax guidelines taken from here https://chris.beams.io/posts/git-commit/ (on 17.06.2020)\n",
+    "Basic syntax guidelines taken from here <https://chris.beams.io/posts/git-commit/> (on 17.06.2020)\n",
     "\n",
     "-  Limit the subject line to 50 characters\n",
     "-  Capitalize the subject line\n",
@@ -672,7 +674,7 @@
     "   do it directly with the git command)\n",
     "-  Put the name of the function/class/module/file that was edited\n",
     "-  When fixing an issue, add the reference gh-ISSUENUMBER to the commit message \n",
-    "   e.g. “fixes gh-40.” or “Closes gh-40.” For more infos see here https://docs.github.com/en/enterprise/2.16/user/github/managing-your-work-on-github/closing-issues-using-keywords#about-issue-references."
+    "   e.g. “fixes gh-40.” or “Closes gh-40.” For more infos see here <https://docs.github.com/en/enterprise/2.16/user/github/managing-your-work-on-github/closing-issues-using-keywords#about-issue-references>."
    ]
   },
   {
@@ -843,7 +845,7 @@
    "metadata": {},
    "source": [
     "![Git and Github logos](img/xkcd_git.png)\\\n",
-    "https://xkcd.com/1597/"
+    "<https://xkcd.com/1597/>"
    ]
   }
  ],

diff --git a/doc/guide/Guide_Review.ipynb b/doc/guide/Guide_Review.ipynb
@@ -14,7 +14,7 @@
     "## How to review a pull request\n",
     "\n",
     "- Be friendly\n",
-    "- Read and follow the [**Reviewer Checklist**](../guide/Guide_Reviewer_Checklist.ipynb)\n",
+    "- Read and follow the [**Reviewer Checklist**](#reviewer-checklist)\n",
     "- Decide how much time you can spare and the detail you can work in. Tell the author!\n",
     "- Use the comment/chat functionality within GitHub's pull requests - it's useful to have an archive of discussions and the decisions made.\n",
     "- Fix the big things first! If there are more important issues, not every style guide has to be stuck to,\\\n",
@@ -40,7 +40,7 @@
     "- Review all the changes in the pull request. Read what it's supposed to do, check it does that, and make sure the logic is sound.\n",
     "- Check that the code follows the CLIMADA style guidelines \n",
     "- [CLIMADA coding conventions](../guide/Guide_CLIMADA_conventions.ipynb) \n",
-     "- [Python Dos and Don't](../guide/Guide_PythonDos-n-Donts.ipynb) \n",
+    "- [Python Dos and Don't](../guide/Guide_PythonDos-n-Donts.ipynb) \n",
     " - [Python performance tips and best practice for CLIMADA developers](../guide/Guide_Py_Performance.ipynb)  \n",
     "- If the code is implementing an algorithm it should be referenced in the documentation. Check it's implemented correctly.\n",
     "- Try to think of edge cases and ways the code could break. See if there's appropriate error handling in cases where the function might behave unexpectedly.\n",
@@ -56,6 +56,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "<a id='reviewer_checklist'></a>\n",
+    "\n",
     "## Reviewer Checklist\n",
     "\n",
     "-  The code must be readable without extra effort from your part. The\n",

diff --git a/doc/guide/Guide_Testing.ipynb b/doc/guide/Guide_Testing.ipynb
@@ -20,7 +20,7 @@
     "Writing tests is work. As a matter of facts, it can be a _lot_ of work, depending on the program often more than writing the original code.\\\n",
     "Luckily, it essentially follows always the same basic procedure and a there are a lot of tools and frameworks available to facilitate this work.\n",
     "\n",
-    "In CLIMADA we use the Python in-built _test runner_ [unittest](https://docs.python.org/3/library/unittest.html) for execution of the tests and the [Jenkins](https://www.jenkins.io/) framework for _continuous integration_, i.e., automated test execution and code analysis."
+    "In CLIMADA we use the Python in-built _test runner_ [pytest](https://docs.pytest.org/en/7.1.x/index.html) for execution of the tests."
    ]
   },
   {
@@ -94,7 +94,7 @@
     "\n",
     "Unit tests are meant to check the correctness of program units, i.e., single methods or functions, they are supposed to be fast, simple and easy to write.\n",
     "\n",
-    "##### Developer guidelines:\n",
+    "#### Developer guidelines:\n",
     "\n",
     "- __Each module in CLIMADA has a counter part containing unit tests.__\\\n",
     "  _Naming suggestion:_ `climada.x.y` &rarr; `climada.x.test.test_y`\n",
@@ -114,7 +114,7 @@
     "  _The motivation to combine more than one method in a test is usually creation of test data. Try to provide test data by other means. Define them on the spot (within the code of the test module) or create a file in a test data directory that can be read during the test. If this is too tedious, at least move the data acquisition part to the constructor of the test class._\n",
     "  \n",
     "- __Do not use external resources in unit tests.__ \\\n",
-    "  _Methods depending on external resources can be skipped from unit tests. See [Dealing with External Resources](#TestExtern)._"
+    "  _Methods depending on external resources can be skipped from unit tests._"
    ]
   },
   {
@@ -127,7 +127,7 @@
     "Integration tests are meant to check the correctness of interaction between units of a module or a package.\\\n",
     "As a general rule, more work is required to write integration tests than to write unit tests and they have longer runtime.\n",
     "\n",
-    "##### Developer guidelines:\n",
+    "#### Developer guidelines:\n",
     "\n",
     "- __Write integration tests for all intended use cases__.\n",
     "\n",
@@ -208,7 +208,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "##### Developer guideline:\n",
+    "#### Developer guideline:\n",
     "\n",
     "- When introducing a new external resource, add a test method in `test_data_api.py`."
    ]
@@ -255,7 +255,10 @@
     "```\n",
     "make integ_test\n",
     "```\n",
-    "It lasts about 15 minutes and runs extensive integration tests, during which also data from external resources is read. An open internet connection is required for a successful test run."
+    "It lasts about 15 minutes and runs extensive integration tests, during which also data from external resources is read. An open internet connection is required for a successful test run. \n",
+    "\n",
+    "#### Note: \n",
+    "Executing `make unit_test` and `make integ_tests` provides local coverage reports as HTML pages at coverage/index.html"
    ]
   }
  ],

diff --git a/doc/guide/install.rst b/doc/guide/install.rst
@@ -244,7 +244,7 @@ On macOS and on Linux it is pre-installed. On Windows, it can easily be installe
 
    mamba install -n climada_env make
 
-Instructions for running the test scripts can be found in the :doc:`Testing and CI Guide <Guide_Continuous_Integration_and_Testing>`.
+Instructions for running the test scripts can be found in the :doc:`Testing Guide <Guide_Testing>`.
 
 Install CLIMADA Petals (Optional)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -311,7 +311,8 @@ It is easy to get confused by all the different softwares and their uses so here
 +------------------------------------------------------+----------------+---------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+
 | Continuous Integration (CI) server                   | Jenkins        | - automatically checks code changes in GitHub repositories, e.g. when you create a pull request for the develop branch                            | CLIMADA developers         |
 |                                                      |                | - performs static code analysis using pylint                                                                                                      |                            |
-|                                                      |                | - you don't need to do any installations, this runs automatically (see: :doc:`GitHub Actions CI <github-actions>`)                                |                            |
+|                                                      |                | - you don't need to do any installations, this runs automatically                                                                                 |                            |
+|                                                      |                | - see: :doc: `Continuous Integration and GitHub Actions <Guide_continuous_integration_GitHub_actions>`)                                           |                            |
 +------------------------------------------------------+----------------+---------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+
 
 JupyterLab