From 3977a6003c9aad88b6ef00bd5e9e2dad7dd009d1 Mon Sep 17 00:00:00 2001 From: George Adams Date: Mon, 20 Feb 2023 09:43:34 +0000 Subject: [PATCH] Change references of ci.adoptopenjdk.net to ci.adoptium.net --- Contributing.md | 2 +- README.md | 14 +++++++------- doc/RunAqa.md | 2 +- jck/jtrunner/config/default/jcktest.properties | 2 +- perf/README.md | 2 +- 5 files changed, 11 insertions(+), 11 deletions(-) diff --git a/Contributing.md b/Contributing.md index 73df03bff1..7c273608b9 100644 --- a/Contributing.md +++ b/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. diff --git a/README.md b/README.md index 9ff6fbd0ff..cd734c376f 100644 --- a/README.md +++ b/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) diff --git a/doc/RunAqa.md b/doc/RunAqa.md index d2d7382c6c..8770f0707d 100644 --- a/doc/RunAqa.md +++ b/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. diff --git a/jck/jtrunner/config/default/jcktest.properties b/jck/jtrunner/config/default/jcktest.properties index 945111241a..899774c799 100644 --- a/jck/jtrunner/config/default/jcktest.properties +++ b/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 diff --git a/perf/README.md b/perf/README.md index b36c4584b2..524f717545 100644 --- a/perf/README.md +++ b/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: