misc: Update documentation and links for GitHub

This changes mentions of googlesource and Gerrit to instead
link to the gem5 GitHub repository, and updates the documentation
to reflect the GitHub review process.

Change-Id: I5dc1d9fcf6b96f9e5116802f938b7e3bb5b09567
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/71878
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>

CONTRIBUTING.md

@@ -14,12 +14,12 @@ several reasons to do this:
  * You will have the satisfaction of contributing back to the community.
 
 The main method for contributing code to gem5 is via our code review website:
-https://gem5-review.googlesource.com/. This documents describes the details of
+https://github.com/gem5/gem5/pulls/. This documents describes the details of
 how to create code changes, upload your changes, have your changes
 reviewed, and finally push your changes to gem5. More information can be found
 from the following sources:
  * http://gem5.org/contributing
- * https://gerrit-review.googlesource.com/Documentation/index.html
+ * https://docs.github.com/en/pull-requests
  * https://git-scm.com/book
 
 
@@ -277,9 +277,7 @@ In github, to submit a review request, you can simply push your git commits to
 a special named branch. For more information on git push see
 https://git-scm.com/docs/git-push.
 
-There are three ways to push your changes to gerrit.
-
-Push change to gerrit review
+Push changes to GitHub
 ----------------------------
 1. Fork the gem5 repository on GitHub from https://github.com/gem5/gem5/.
 2. Create a new branch in your forked repository for your feature or bug fix.
@@ -296,35 +294,7 @@ By default, contributions to gem5 should be made on the develop branch. The
 stable branch is maintained as a stable release branch (i.e., it can be pulled
 to obtain the latest official release of gem5). Creation of additional branches
 is generally discouraged due to their tendency to bloat git repositories with
-abandoned code. However, the creation of new branches is permitted for
-development of a specific feature or improvement if one or more of the
-following criteria are met:
-
-1. The feature/improvement is likely to be of a large size, consisting of many
-commits, with little logic in these commits being contributed separately.
-2. The feature/improvement will be developed over a long period of time.
-3. There is sufficient reason that a feature/improvement should not be part
-of the next gem5 release (e.g., the change should be held within a feature
-branch until ready for the next release, at which point it will be merged
-into the develop branch).
-
-If a branch is required it can only be created by a project maintainer.
-Therefore, if a gem5 contributor desires a separate branch for their work, they
-should request one from the maintainer of the component the work relates to
-(see MAINTAINERS for the list of maintainers and the components they are
-responsible for). **The maintainer shall use their discretion to determine
-whether the creation of a branch is necessary**. If approved, the maintainer
-shall create the branch which the contributor may then use.
-
-Development on a branch within Gerrit functions in exactly the same way as
-contributing to the develop branch. When contributors to a branch are
-satisfied, they should create a merge commit into the develop branch. The
-maintainer should then be notified that the branch they created can now be
-deleted.
-
-**Abandonment of changes within branches may result in these branches being
-removed from the repository. All branches within a repo should be under active
-development.**
+abandoned code.
 
 Reviewing patches
 =================
@@ -332,7 +302,7 @@ Reviewing patches
 Reviewing patches is done on our github instance at
 https://github.com/gem5/gem5/pulls/.
 
-After logging in with your Google account, you will be able to comment, review,
+After logging in with your GitHub account, you will be able to comment, review,
 and push your own patches as well as review others' patches. All gem5 users are
 encouraged to review patches. The only requirement to review patches is to be
 polite and respectful of others.

TESTING.md

@@ -18,8 +18,8 @@ To build and run all the unit tests:
 scons build/ALL/unittests.opt
 ```
 
-All unit tests should be run prior to posting a patch to
-https://gem5-review.googlesource.com
+All unit tests should be run prior to creating a pull request at
+https://github.com/gem5/gem5/pulls/
 
 To compile and run just one set of tests (e.g. those declared within
 `src/base/bitunion.test.cc`):
@@ -60,8 +60,8 @@ cd tests
 ./main.py run
 ```
 
-The above is the *minumum* you should run before posting a patch to
-https://gem5-review.googlesource.com
+The above is the *minumum* you should run before posting a pull request to
+https://github.com/gem5/gem5/pulls/
 
 ## Running tests from multiple directories
 
@@ -260,3 +260,42 @@ suites in parallel, supply the `-t <number-tests>` flag to the run command.
 For example, to run up to three test suites at the same time::
 
     ./main.py run --skip-build -t 3
+
+## Running Tests within GitHub Actions
+
+To run these tests within GitHub Actions, we use the format of running
+tests by directory as shown above in the "Running Tests from Multiple
+Directories" section.  These tests are run within workflow files,
+which can be found in the .github directory of this repository.
+You can learn more about workflows
+[here](https://docs.github.com/en/actions/using-workflows/about-workflows).
+
+Each workflow is made up of individual jobs, where each job is a set
+of tests that is executed on a runner within GitHub.  In each
+workflow, each version of gem5.opt needed is first built, and then
+stored as an artifact for main.py to use.
+
+There are two sets of runners within the gem5 repository: builders and
+runners.  The builders have more resources available to allow for a
+quicker compilation of gem5, while the runners have less, and are
+meant to only run tests.
+
+After the gem5 artifact has been uploaded, a runner can then download
+the versions needed for their tests.  For example, in the daily-tests.yaml,
+in order to run the multi_isa tests, you need artifacts of ARM, RISCV,
+and VEGA_X86.
+
+## Adding Tests to GitHub Actions
+
+In order to add new tests to our GitHub Actions testing infastructure,
+follow the format currently shown in the existing workflows.  If the
+new tests were added to an already existing directory (ex. A very-long
+test in the gem5_library_example_tests), it will automatically be
+included into the weekly testing, since weekly-tests.yaml already
+contains a job for the gem5_library_example_tests.
+
+However, if a new directory is added to the tests, you need to manually
+add a new step to the GitHub workflows.  This would consist of both a
+step to build whatever version of gem5 was required if it wasn't
+already included in the file, as well as a step to run main.py
+in the given directory after downloading the gem5 artifact.

configs/example/gem5_library/arm-hello.py

@@ -80,7 +80,7 @@ board = SimpleBoard(
 board.set_se_binary_workload(
     # The `Resource` class reads the `resources.json` file from the gem5
     # resources repository:
-    # https://gem5.googlesource.com/public/gem5-resource.
+    # https://github.com/gem5/gem5-resources.
     # Any resource specified in this file will be automatically retrieved.
     # At the time of writing, this file is a WIP and does not contain all
     # resources. Jira ticket: https://gem5.atlassian.net/browse/GEM5-1096

configs/example/gem5_library/checkpoints/riscv-hello-save-checkpoint.py

@@ -97,7 +97,7 @@ board = SimpleBoard(
 board.set_se_binary_workload(
     # The `Resource` class reads the `resources.json` file from the gem5
     # resources repository:
-    # https://gem5.googlesource.com/public/gem5-resource.
+    # https://github.com/gem5/gem5-resources.
     # Any resource specified in this file will be automatically retrieved.
     # At the time of writing, this file is a WIP and does not contain all
     # resources. Jira ticket: https://gem5.atlassian.net/browse/GEM5-1096

configs/example/gem5_library/dramsys/arm-hello-dramsys.py

@@ -74,7 +74,7 @@ board = SimpleBoard(
 board.set_se_binary_workload(
     # The `Resource` class reads the `resources.json` file from the gem5
     # resources repository:
-    # https://gem5.googlesource.com/public/gem5-resource.
+    # https://github.com/gem5/gem5-resources.
     # Any resource specified in this file will be automatically retrieved.
     # At the time of writing, this file is a WIP and does not contain all
     # resources. Jira ticket: https://gem5.atlassian.net/browse/GEM5-1096

configs/example/gem5_library/riscv-fs.py

@@ -27,7 +27,7 @@
 """
 This example runs a simple linux boot. It uses the 'riscv-disk-img' resource.
 It is built with the sources in `src/riscv-fs` in [gem5 resources](
-https://gem5.googlesource.com/public/gem5-resources).
+https://github.com/gem5/gem5-resources).
 
 Characteristics
 ---------------

ext/sst/README.md

@@ -78,7 +78,7 @@ the `bbl-busybox-boot-exit` resource, which contains an m5 binary, and
 `m5 exit` will be called upon the booting process reaching the early userspace.
 More information about building a bootloader containing a Linux Kernel and a
 customized workload is available at
-[https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/riscv-boot-exit-nodisk/].
+[https://github.com/gem5/gem5-resources/tree/stable/src/riscv-boot-exit-nodisk].
 
 ## Running an example simulation (Arm)
 

tests/weekly.sh

@@ -94,7 +94,7 @@ rm -rf ${gem5_root}/m5out coAuthorsDBLP.graph 1k_128k.gr result.out
 # Moreover, DNNMark builds a library and thus doesn't have a binary, so we
 # need to build it before we run it.
 # Need to pull this first because HACC's docker requires this path to exist
-git clone https://gem5.googlesource.com/public/gem5-resources \
+git clone https://github.com/gem5/gem5-resources \
     "${gem5_root}/gem5-resources"