Merge pull request #685 from reportportal/hotfix/release

Hotfix/release

docs/installation-steps/ScalingUpReportPortalAPIService.md

@@ -1,6 +1,6 @@
 # Scaling Up the ReportPortal Service API
 
-Due to the current implementation specifics [Asynchronous Reporting Scheme](/dev-guides/AsynchronousReporting/#scheme), horizontal auto-scaling of the ReportPortal service API is not feasible. However, manual scaling is achievable. This limitation stems from the way RabbitMQ, in conjunction with the API, manages the number of queues on the RabbitMQ side.
+Due to the current implementation specifics [Asynchronous Reporting Scheme](/dev-guides/AsynchronousReporting#scheme), horizontal auto-scaling of the ReportPortal service API is not feasible. However, manual scaling is achievable. This limitation stems from the way RabbitMQ, in conjunction with the API, manages the number of queues on the RabbitMQ side.
 
 Given that ReportPortal can receive a substantial volume of concurrent streams from different project spaces, a mechanism has been implemented. This mechanism determines the number of queues based on the hash of the launch object and distributes them across different queues to increase the likelihood of processing.
 
@@ -14,11 +14,11 @@ To scale your ReportPortal services in Kubernetes, you need to adjust the `repli
 
 1. **Update Replica Count**:
    Change `replicaCount` from `1` to `2` for additional replication.<br />
-   [values.yaml replicaCount](https://github.com/reportportal/kubernetes/blob/develop/values.yaml#L57)
+   [values.yaml replicaCount](https://github.com/reportportal/kubernetes/blob/master/reportportal/values.yaml#L71)
 
 2. **Edit Total Number of Queues**:
    Modify `queues.totalNumber` from `10` to `20` to increase the total available queues.<br />
-   [values.yaml queues.totalNumber](https://github.com/reportportal/kubernetes/blob/develop/values.yaml#L101)
+   [values.yaml queues.totalNumber](https://github.com/reportportal/kubernetes/blob/master/reportportal/values.yaml#L120)
 
    Use the following formula for calculation:<br />
    `perPodNumber = totalNumber / serviceapi.replicaCount`

docs/issues-troubleshooting/IssuesWithJIRABugTrackingSystemHowToResolve.md

@@ -35,23 +35,49 @@ Screen with CAPTCHA should appears
 5. Submit the credentials again
 6. Now try to establish the connection to JIRA on ReportPortal project.
 
-**Fourth**, maybe the connection to the jira instance requires a certificate, in this
-case you need to import the certificate inside the jira container:
-
-1. docker exec -it reportportal_jira_1 ash # go inside shell
-2. cd /usr/lib/jvm/java-1.8-openjdk/jre/lib/security/
-3. wget url://to/your/foo.cert
-4. keytool -importcert -noprompt -file foo.crt -alias "JIRA CERT" -keystore cacerts -storepass abc123 (default password for keystore: changeit)
-5. exit and restart the docker jira
-6. Now try to establish the connection to JIRA on ReportPortal project.
+**Fourth**, the connection to the JIRA instance might require a certificate. If that's the case, the certificate needs to be imported inside the API container. Follow these steps:
+
+```sh
+# 1. Access the shell of the API Docker container
+docker exec -it reportportal_api_1 /bin/sh
+
+# 2. Change the directory to point to the 'security' directory
+cd /usr/lib/jvm/jre/lib/security/
+# Or use this command if the 'security' directory is in another folder:
+# cd /usr/lib/jvm/java-11-amazon-corretto/jre/lib/security/
+
+Note: Replace 'java-11-amazon-corretto' with the version in the latest API Docker image.
+
+# 3. Get the certificate file
+curl -O url://to/your/foo.cert
+
+# 4. Import the certificate
+keytool -importcert -noprompt -file foo.cert -alias "JIRA CERT" -keystore cacerts -storepass abc123 # note: the default password for the keystore is 'changeit'
 
-or
+# 5. Exit the shell and restart the docker API.
+exit
 
-1. docker cp cert.der reportportal_jira_1:/cert.der
-2. docker exec -t -i reportportal_jira_1 ./usr/lib/jvm/java-1.8-openjdk/jre/bin/keytool -import -alias rootcert -keystore /usr/lib/jvm/java-1.8-openjdk/jre/lib/security/cacerts -file /cert.der
-3. exit and restart the docker jira
-4. Now try to establish the connection to JIRA on ReportPortal project.
+# 6. Try to establish the connection to JIRA on the ReportPortal project again.
+```
+Or use this alternative method:
+
+```sh
+# 1. Copy the certificate into the Docker container
+docker cp cert.der reportportal_api_1:/cert.der
+
+# 2. Import the certificate
+docker exec -t -i reportportal_api_1 ./usr/lib/jvm/jre/bin/keytool -import -alias rootcert -keystore /usr/lib/jvm/jre/lib/security/cacerts -file /cert.der
+# If the 'jre' folder is inside another folder, use the following command instead:
+# docker exec -t -i reportportal_api_1 ./usr/lib/jvm/java-11-amazon-corretto/jre/bin/keytool -import -alias rootcert -keystore /usr/lib/jvm/java-11-amazon-corretto/jre/lib/security/cacerts -file /cert.der
 
+Note: Replace 'java-11-amazon-corretto' with the version in the latest API Docker image.
+
+# 3. Exit and restart the Docker API.
+exit
+
+# 4. Attempt the connection to JIRA on ReportPortal project again.
+```
+Both methods should allow you to import the necessary certificate for your JIRA connection inside the ReportPortal API container.
 
 :::note
 SSL instance of JIRA (even cloud version) can be accessed by JIRA API token, used instead of password.

docs/plugins/AtlassianJiraCloud.mdx

@@ -30,7 +30,7 @@ If all projects on your instance are using the same Jira projects, you will be a
 ```javascript
 'Integration Name': <The name which you want to give to your integration> - should be unique
 'Link to BTS': <valid URL of bug tracking system>
-'Project key in BTS': <project key in bug tracking system>                     
+'Project key in BTS': <project key in bug tracking system>
 'Email': <user email>
 'API Token': <user API Token>
 ```

docs/releases/Version23.2.md

@@ -44,7 +44,7 @@ Please note that Features 3 and 4 are configurable, giving you the flexibility t
 
 You can now generate as many API Keys as you need. You also have the ability to keep track of the creation date of API Keys and revoke any that are unused. Old tokens will still continue to function. Additionally, easy identification of the purpose of API Keys is facilitated through the use of prefixes.  
 
-More details can be found via the [link](/reportportal-configuration/HowToGetAnAccessTokenInReportPortal/#2-authorization-with-users-api-key-for-agents).
+More details can be found via the [link](/reportportal-configuration/HowToGetAnAccessTokenInReportPortal#2-authorization-with-users-api-key-for-agents).
 
 - **Gitlab CI integration Workaround:**  
 

docs/work-with-reports/HistoryOfLaunches.mdx

@@ -39,7 +39,7 @@ Run ReportPortal without env variable.
 
 Where you can find History table.
 
-Drill down to the Step view (test executions list). 
+Drill down to the Step view (test executions list).
 
 Click the "History" button.
 
@@ -58,7 +58,7 @@ History trends have the following color scheme:
    * Animated - still without state [in progress]
 
 You can select the depth of history: 3, 5, 10, 15, 20, 25 or 30 launches from the "History
-Depth" drop-down menu. 
+Depth" drop-down menu.
 
 There are two options for a History table:
 
@@ -70,7 +70,7 @@ In case you use a history table based on UID, a history table will show you resu
 
 ### History for all launches
 
-If you have configured ReportPortal with [TestCase History table](/work-with-reports/HistoryOfLaunches/#history-table).
+If you have configured ReportPortal with [TestCase History table](/work-with-reports/HistoryOfLaunches#history-table).
 This option is for you.
 
 **How you can open a history table with execution from all launches?**
@@ -87,11 +87,11 @@ Each column on the history table is equaled to a number of the execution.
 
 Let's see an example.
 
->**Use case:** You have a test suite for the regression. You want to perform regression testing in different environments. For those reasons, you are running your regression suite on macOS, Windows, and Linux. 
+>**Use case:** You have a test suite for the regression. You want to perform regression testing in different environments. For those reasons, you are running your regression suite on macOS, Windows, and Linux.
 After test runs finish, you will be able to see on the All launches tab on ReportPortal 3 launches with different names: *Regression_MacOS, Regression_Win, Regression_Linux*.
 If you click on the Total statistic for  the launch *Regression_MacOS* and click on the 'History' button, you will see a History table with all test cases in the suite and their 10 last executions from all launches on the project (e.g. from *Regression_MacOS, Regression_Win, Regression_Linux*)
 >
-> 
+>
 > | Test case name  | Execution #3 | Execution #2 | Execution #1|
 > | ------------- | ------------- |------------- |------------- |
 > | Test 1 | Passed  |Failed   |Passed  |
@@ -121,11 +121,11 @@ Each column on the history table is equaled to a number of the execution.
 
 Let's see an example.
 
->**Use case:** You have a test suite for the regression. You want to perform regression testing in different environments. For those reasons, you are running your regression suite on macOS, Windows, and Linux. 
+>**Use case:** You have a test suite for the regression. You want to perform regression testing in different environments. For those reasons, you are running your regression suite on macOS, Windows, and Linux.
 After test runs finish, you will be able to see on the All launches tab on ReportPortal 3 launches with different names: *Regression_MacOS, Regression_Win, Regression_Linux*.
 If you click on the Total statistic for the launch *Regression_MacOS* and click on the 'History' button and  you choose the option **'Launches with the same name'**, you will see executions only from launches with name *Regression_MacOS*.
 >
-> 
+>
 > | Test case name  | Execution #2|
 > | ------------- | ------------- |
 > | Test 1 |Passed  |
@@ -135,7 +135,7 @@ If you click on the Total statistic for the launch *Regression_MacOS* and click
 
 <MediaViewer src="https://youtu.be/DoKW0jFBELo" alt="History Table launches with the same name" type="video" />
 
-### Actions 
+### Actions
 
 From the History table you will be able to perform the next actions:
 
@@ -148,13 +148,13 @@ From the History table you will be able to perform the next actions:
 For that:
 - Hover the cell on the history table
 - Click on the checkbox
-- Check needed item 
+- Check needed item
 - Click on the button 'Action'
 - Choose needed action
 
 #### Compare launch results with the filter
 
-You can add a custom column with the latest filter results to the History table. 
+You can add a custom column with the latest filter results to the History table.
 
 >**Use case:** You have a test suite for the regression. You run this suite for different versions (version 1, version2, version 3).
 When you run tests for the new version you need to find out if new bugs appeared in it in comparison with the previous version.
@@ -168,9 +168,9 @@ The system adds the latest executions from filter 'Version 2' and you will be ab
 
 The historical line of executions represents the statuses of the current test case in history.
 
-You can see the historical line of executions at the Log level. History is shown only for the 
-current item and there are 30 items max in history. 
-You can click on the item in the history and check the results in previous executions, read 
+You can see the historical line of executions at the Log level. History is shown only for the
+current item and there are 30 items max in history.
+You can click on the item in the history and check the results in previous executions, read
 the comments, find the bugs, posted to this fail.
 This feature will save you time and help you to understand the reason for your failure.
 
@@ -187,7 +187,7 @@ History line has the following color scheme:
 You can mark the current method or case with a defect type, and write a comment
 using the defect editor block.
 
-To come into a certain execution of an appropriate launch, hit a launch number 
+To come into a certain execution of an appropriate launch, hit a launch number
 above the item.
 
 Also on a History line, you can see an "i" label, it means that the item with this label has a defect comment or/and a link to the Bug Tracking System.
@@ -210,15 +210,15 @@ No duration growth - 0 triangles
 
 duration growh from 0 to 20% - 1 triangles
 
-duration growh from 21% - 50% - 2 trianges 
+duration growh from 21% - 50% - 2 trianges
 
-duration growh from 51% - 100% - 3 trianges 
+duration growh from 51% - 100% - 3 trianges
 
-duration growh from 101% and higher - 4 trianges 
+duration growh from 101% and higher - 4 trianges
 
 #### Load more History
 
-By default the system shows 12 latest executions. If you need more history you can click on the button "Load more 9 items and the system loaded more executions on history line. Max number of items on History line is 30 executions. 
+By default the system shows 12 latest executions. If you need more history you can click on the button "Load more 9 items and the system loaded more executions on history line. Max number of items on History line is 30 executions.
 
 User can move on History line using horizontal scroll.
 
@@ -239,7 +239,7 @@ The following actions are shown on the history of actions:
 
 >   analyzer posted a comment to the test item
 
->   analyzer posted a bug to the Bug Tracking System or added a link to the existing in the Bug Tracking System issue. 
+>   analyzer posted a bug to the Bug Tracking System or added a link to the existing in the Bug Tracking System issue.
 
 To see the history of actions, navigate to a certain child item. By default you
 will see the last action in one line.

docusaurus.config.js

@@ -17,7 +17,9 @@ const config = {
   url: 'https://reportportal.io',
   baseUrl,
   onBrokenLinks: 'throw',
-  onBrokenMarkdownLinks: 'warn',
+  onBrokenAnchors: 'throw',
+  onBrokenMarkdownLinks: 'throw',
+  onDuplicateRoutes: 'throw',
   favicon: 'img/favicon.ico',
 
   organizationName: 'reportportal',