Debug page to github actions, update links

dev/testing/en/debug.md

@@ -4,7 +4,7 @@ title: Debug Test Failures - Testing - OJS/OMP
 
 # Debug Test Failures
 
-When a test fails it means that a recent change has broken the application. The log files for the tests will will indicate which tests failed and will list all of the commands that were run before the failure occurred.
+When a test fails it means that a recent change has broken the application. The log files for the tests will indicate which tests failed and will list all of the commands that were run before the failure occurred.
 
 In most cases, the server's error log will contain important clues about what went wrong.
 
@@ -16,40 +16,36 @@ When the tests are run from the terminal you will find a screenshot of the brows
 
 ## Debug CI
 
-The [CI tests](./continuous-integration) can be difficult to debug. Travis provides access to its build logs and screenshots of test failures to help.
+The [CI tests](./continuous-integration) can be difficult to debug. GitHub provides access to its build logs and artifacts produced by tests to help. Click **Checks** on a pull request to see the logs from the tests.
 
 <figure class="video_container">
   <video controls="true" allowfullscreen="true">
-    <source src="./travis-log.mp4" type="video/mp4">
+    <source src="./github-log.mp4" type="video/mp4">
   </video>
-  <figcaption>Short video showing how to access log of build results.</figcaption>
+  <figcaption>Short video showing how to access the log of build results.</figcaption>
 </figure>
 
 This provides a log of the entire build process including the logs from the Cypress and PHP Unit tests. Parts of the log, such as the server's error log, are truncated and can only be reached by accessing the raw log.
 
 <figure class="video_container">
   <video controls="true" allowfullscreen="true">
-    <source src="./travis-log-raw.mp4" type="video/mp4">
+    <source src="./github-log-raw.mp4" type="video/mp4">
   </video>
   <figcaption>Short video showing how to access the raw log of build results.</figcaption>
 </figure>
 
 > When viewing the raw log, run a search in your browser for "fatal". This is a quick way to find the source of many -- _but not all_ -- test failures.
 {:.tip}
 
-### Travis debug mode
+### Artifacts
 
-Travis provides a [debug mode](https://docs.travis-ci.com/user/running-build-in-debug-mode/). When enabled it is possible to log into the Travis environment via SSH and explore the tests manually.
+When a test fails, GitHub Actions will create individual artifact downloads that contain screenshots generated by Cypress for each failing test, as well as server logs.
 
-### Screenshots
+![GitHub Actions log with an artifact download URL.](./download-artifacts.png)
 
-Screenshots can be accessed by using the uuencode tool on the Travis VM. To extract the screenshots related to a test failure, follow these steps.
+Download URLs will also be output in the logs for each failing test near the end of a test run.
 
-- When viewing the test output on Travis, click the "Raw Log" button.
-- Save the log to your computer, for example `/tmp/log.txt`.
-- Run `cat /tmp/log.txt | uudecode | tar xvz` to extract the screenshots locally.
-
-> If you are struggling to understand a test failure in Travis, it may be best to run the tests locally where you have more insight into the state of the application.
+> If you are struggling to understand a test failure, it may be best to run the tests locally where you have more insight into the state of the application.
 {:.tip}
 
 ---

dev/testing/en/getting-started.md

@@ -8,7 +8,7 @@ We use [Cypress](https://www.cypress.io/) and [PHPUnit](https://phpunit.de/) to
 
 ## Configure your environment
 
-There are many ways to [configure your environment](https://docs.cypress.io/guides/guides/environment-variables.html#Setting) to run the Cypress tests. We recommend creating a `cypress.env.json` file.
+There are many ways to [configure your environment](https://docs.cypress.io/guides/guides/environment-variables#Setting) to run the Cypress tests. We recommend creating a `cypress.env.json` file.
 
 ```json
 {
@@ -31,7 +31,7 @@ The integration tests will install the software and create test data.
 
 ## Run integration tests
 
-The integration tests will install the software and run a number of tests to add users, make submissions, record editorial decisions and publish articles.
+The integration tests will install the software and run tests to add users, make submissions, record editorial decisions and publish articles.
 
 Before the integration tests are run, update your `config.inc.php` file and set the `installed` flag to `Off`.
 

dev/testing/en/writing-tests.md

@@ -11,7 +11,7 @@ It is often appropriate to add to one of the existing tests rather than create a
 > If you are writing a test which checks a particular part of the editorial workflow, it should be put in `cypress/tests/data`. If you are writing a test for something else, such as statistics or journal settings, it should be put in `cypress/tests/integration`.
 {:.notice}
 
-Read the Cypress documentation to learn how to write your [first test](https://docs.cypress.io/guides/getting-started/writing-your-first-test.html), [organize tests](https://docs.cypress.io/guides/core-concepts/writing-and-organizing-tests.html#Test-Structure), and [interact with buttons and fields](https://docs.cypress.io/guides/core-concepts/interacting-with-elements.html#Actionability).
+Read the Cypress documentation to learn how to write your [first test](https://docs.cypress.io/guides/end-to-end-testing/writing-your-first-end-to-end-test), [organize tests](https://docs.cypress.io/guides/core-concepts/writing-and-organizing-tests#Test-Structure), and [interact with buttons and fields](https://docs.cypress.io/guides/core-concepts/interacting-with-elements#Actionability).
 
 ## Commands