Change references of ci.adoptopenjdk.net to ci.adoptium.net

Contributing.md

@@ -104,7 +104,7 @@ You can skip `-f` in `git push` if you've never pushed your branch before.
 
 8. We would like to encourage you to open a pull request early and use `Create draft pull request` option. This allows others to check the PR, get early feedback, and helps create a better end product.
 
-9. If you have been given access to run test jobs in our Jenkins server, run [Grinder](https://ci.adoptopenjdk.net/job/Grinder/) to validate your PR. Your can find recordings about how to use Grinder in AQA Lightning Talk Series: https://github.com/eclipse-openj9/openj9/wiki/AQA-Lightning-Talk-Series.  If you do not have access, the reviewers of your PR will run some tests.  Reviewers may ask you to run extra tests depending on what changes you have made in your PR.
+9. If you have been given access to run test jobs in our Jenkins server, run [Grinder](https://ci.adoptium.net/job/Grinder/) to validate your PR. Your can find recordings about how to use Grinder in AQA Lightning Talk Series: https://github.com/eclipse-openj9/openj9/wiki/AQA-Lightning-Talk-Series.  If you do not have access, the reviewers of your PR will run some tests.  Reviewers may ask you to run extra tests depending on what changes you have made in your PR.
 
 10. Ensure all related Grinder jobs pass and provide the Grinder links in the PR comment. Your changes must also pass the auto PR builds that will be applied to your pull request.
 

README.md

@@ -40,7 +40,7 @@ For nightly and release builds, there are test jobs running as part of the Adopt
 
 #### Test 'Inventory'
 
-The directory structure in this aqa-tests repository is meant to reflect the different types of test we run (and pull from lots of other locations).  The diagrams below show the test make target for each of the types, along with in-plan, upcoming additions (denoted by dotted line grey boxes). The provided links jump to test jobs in Jenkins (ci.adoptopenjdk.net).
+The directory structure in this aqa-tests repository is meant to reflect the different types of test we run (and pull from lots of other locations).  The diagrams below show the test make target for each of the types, along with in-plan, upcoming additions (denoted by dotted line grey boxes). The provided links jump to test jobs in Jenkins (ci.adoptium.net).
 
 ```mermaid
 graph TD
@@ -65,17 +65,17 @@ graph TD
 
 --- 
 
-##### [openjdk](https://ci.adoptopenjdk.net/view/Test_openjdk/) tests - OpenJDK regression tests 
+##### [openjdk](https://ci.adoptium.net/view/Test_openjdk/) tests - OpenJDK regression tests 
 Tests from OpenJDK
 
 --- 
 
-##### [system](https://ci.adoptopenjdk.net/view/Test_system/) tests - System and load tests 
+##### [system](https://ci.adoptium.net/view/Test_system/) tests - System and load tests 
 Tests from the adoptium/aqa-systemtest repo
 
 --- 
 
-##### [external](https://ci.adoptopenjdk.net/view/Test_external/) tests - 3rd party application tests
+##### [external](https://ci.adoptium.net/view/Test_external/) tests - 3rd party application tests
 Test suites from a variety of applications, along with microprofile TCKs, run in Docker containers
 
 ```mermaid
@@ -103,7 +103,7 @@ graph TD
 
 --- 
 
-##### [perf](https://ci.adoptopenjdk.net/view/Test_perf/) tests - Performance benchmark suites 
+##### [perf](https://ci.adoptium.net/view/Test_perf/) tests - Performance benchmark suites 
 Performance benchmark tests (both full suites and microbenches) from different open-source projects such as Acme-Air and adoptium/bumblebench
 
 ```mermaid
@@ -118,7 +118,7 @@ graph TD
 
 --- 
 
-##### [functional](https://ci.adoptopenjdk.net/view/Test_functional/) tests - Unit and functional tests
+##### [functional](https://ci.adoptium.net/view/Test_functional/) tests - Unit and functional tests
 Functional tests not originating from the openjdk regression suite, that include locale/language tests and a subset of implementation agnostic tests from the openj9 project.
 
 --- 
@@ -154,6 +154,6 @@ The test infrastructure in this repository allows us to lightly yoke a great var
 You can:
 - browse through the [aqa-tests issues list](https://github.com/adoptium/aqa-tests/issues), select one, add a comment to claim it and ask questions
 - browse through the [aqa-systemtest issues](https://github.com/adoptium/aqa-systemtest/issues) or [stf issues](https://github.com/adoptium/stf/issues), claim one with a comment and dig right in
-- triage live test jobs at [ci.adoptopenjdk.net](https://ci.adoptopenjdk.net), check out the [triage doc](https://github.com/adoptium/aqa-tests/blob/master/doc/Triage.md) for guidance
+- triage live test jobs at [ci.adoptium.net](https://ci.adoptium.net), check out the [triage doc](https://github.com/adoptium/aqa-tests/blob/master/doc/Triage.md) for guidance
   - if you would like to regularly triage test jobs, you can optionally 'sign up for duty' via the [triage rotas](https://github.com/adoptium/aqa-tests/wiki/AdoptOpenJDK-Test-Triage-Rotas)
 - ask questions in the [#testing channel](https://adoptium.slack.com/archives/C5219G28G) 

doc/RunAqa.md

@@ -11,7 +11,7 @@ run aqa --sdk_resource nightly --build_list openjdk --target sanity.openjdk --jd
 
 ## Arguments
 
-Most arguments are similar to their [Jenkins Grinder](https://ci.adoptopenjdk.net/job/Grinder) counterparts.
+Most arguments are similar to their [Jenkins Grinder](https://ci.adoptium.net/job/Grinder) counterparts.
 
 All arguments allow more than one parameter. The parameters of each argument will be used to create a matrix job that will test every combination of the parameters.
 

jck/jtrunner/config/default/jcktest.properties

@@ -7,7 +7,7 @@
 # The tests default to using 'default' as the config name.  If another name is used it must be
 # supplied to the test at run time - see openjdk.test.jck/docs/README.md for more details.
 
-testhost1name=ci.adoptopenjdk.net
+testhost1name=ci.adoptium.net
 testhost1ip=78.47.239.97
 testhost2name=hg.openjdk.java.net
 testhost2ip=137.254.56.63

perf/README.md

@@ -14,7 +14,7 @@ See the License for the specific language governing permissions and
 
 # Adoptium Performance Testing
 
-We are in the process of adding more microbenchmarks (both bumblebench and jmh formats) and full open-source benchmarks to this directory. New perftest jobs are added to the [Test_perf](https://ci.adoptopenjdk.net/view/Test_perf/) view.  While we will run these benchmarks regularly at adoptium, the intention is to make it easy for developers to run performance testing locally.  
+We are in the process of adding more microbenchmarks (both bumblebench and jmh formats) and full open-source benchmarks to this directory. New perftest jobs are added to the [Test_perf](https://ci.adoptium.net/view/Test_perf/) view.  While we will run these benchmarks regularly at adoptium, the intention is to make it easy for developers to run performance testing locally.  
 
 You can follow the [same manual testing instructions](https://github.com/adoptium/aqa-tests/blob/master/doc/userGuide.md#local-testing-via-make-targets-on-the-commandline) to run these tests, as you do for all of the other tests we run.  The top-level make target for tests contained in this directory (aqa-tests/perf) is "perf".  So, once you compile test material, running "make perf" will run all of the testcases defined in playlist.xml files in this directory and its subdirectories.  Each unique benchmark is housed in a 
 subdirectory and given a meaningful name.  Once the reorganization of this directory is complete, the directory structure will look like: