chore(performance): Add readmes #1501
Conversation
📝 WalkthroughWalkthroughThis pull request introduces new README documentation for performance testing across multiple API endpoints, including those in the Changes
Possibly related PRs
Suggested reviewers
Warning Rate limit exceeded@dagfinno has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 10 minutes and 38 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (11)
tests/k6/tests/graphql/README.md (3)
1-4: Update title to match content descriptionThe current title "Graphql get dialogs" doesn't accurately reflect the content. Consider updating it to "GraphQL Search Performance Tests" or similar, as this README specifically covers GraphQL search functionality testing.
8-11: Enhance test file section with more detailsConsider adding:
- The full path to the test file
- A brief description of the test scenarios or parameters it supports
- Expected outputs or success criteria
60-61: Improve Test Results section formatting and clarityThe section has several issues:
- Remove duplicate "Test Results" heading
- Add proper punctuation and capitalization
- Clarify the AppInsights integration
-## Test Results -Test results can be found in github action run log and in appinsights. We are prepared for exporting results to grafana, but so far results are exported to a private grafana instance only, as can be seen from the `.secrets`listed earlier +## Test Results +Test results can be found in: +- GitHub Actions run logs +- Azure Application Insights +- Private Grafana instance (currently limited access) + +Note: We are prepared for public Grafana exports in the future.🧰 Tools
🪛 LanguageTool
[grammar] ~60-~60: This phrase is duplicated. You should probably use “Test Results” only once.
Context: ...h.js \ --input tokens=personal ``` ## Test Results Test results can be found in github action run log a...(PHRASE_REPETITION)
[typographical] ~61-~61: It seems that a comma is missing.
Context: ...d for exporting results to grafana, but so far results are exported to a private grafa...(SO_COMMA)
tests/k6/tests/enduser/performance/README.md (5)
1-3: Consider enhancing the title for better clarity.The current title "Enduser get dialogs" could be more descriptive. Consider something like "Performance Tests for Enduser Dialog API Endpoints" to better reflect the document's content.
-# Enduser get dialogs +# Performance Tests for Enduser Dialog API Endpoints
6-6: Consider using an absolute link for prerequisites.The relative link to prerequisites could break if files are reorganized. Consider using an absolute GitHub URL.
9-10: Add more context about the test file's purpose.Consider adding a brief description of what
enduser-search.jsdoes and its key features.## Test file -The test file associated with this performance test is -- `enduser-search.js` +The test file associated with this performance test is: +- `enduser-search.js` - Implements sequential API endpoint testing for enduser dialogs, measuring response times and performance metrics.
15-24: Enhance endpoint documentation with parameter descriptions.Consider adding descriptions for the placeholders (
<ssn>,<dialogId>, etc.) and their expected formats.
74-76: Improve clarity of test results section.The section needs grammatical improvements and better structure.
## Test Results -Test results can be found in github action run log and in appinsights. We are prepared for exporting results to grafana, but so far results are exported to a private grafana instance only, as can be seen from the `.secrets`listed earlier +Test results can be found in: +- GitHub Actions run logs +- Application Insights + +While we're prepared to export results to Grafana, currently results are only exported to a private Grafana instance (configured via the `.secrets` file mentioned above).🧰 Tools
🪛 LanguageTool
[grammar] ~74-~74: This phrase is duplicated. You should probably use “Test Results” only once.
Context: ...h.js \ --input tokens=personal ``` ## Test Results Test results can be found in github action run log a...(PHRASE_REPETITION)
[typographical] ~75-~75: It seems that a comma is missing.
Context: ...d for exporting results to grafana, but so far results are exported to a private grafa...(SO_COMMA)
tests/k6/tests/serviceowner/performance/README.md (3)
10-14: Fix grammatical error and enhance test file descriptionsThe sentence has a subject-verb agreement error, and the test file descriptions could be more informative.
Apply this diff:
-The test files associated with this performance test is - - `create-dialog.js` - - `create-remove-dialog.js` - - `serviceowner-search.js` - - `purge-dialogs.js` (used for cleanup after test) +The test files associated with this performance test are: + - `create-dialog.js` - Tests the performance of dialog creation endpoints + - `create-remove-dialog.js` - Evaluates the complete lifecycle of dialog creation and removal + - `serviceowner-search.js` - Measures the performance of dialog search functionality + - `purge-dialogs.js` - Utility script for cleaning up test data after performance tests
31-35: Add example command with realistic valuesTo make the instructions more user-friendly, include a concrete example of the test command.
Add an example after the command:
k6 run <test-file> -e API_VERSION=v1 \ -e API_ENVIRONMENT=<(test|staging|yt01)> \ --vus=<vus> --duration=<duration> +Example: +k6 run create-dialog.js -e API_VERSION=v1 \ +-e API_ENVIRONMENT=test \ +--vus=10 --duration=30s
76-95: Enhance cleanup documentation with best practicesAdd information about when to run cleanup and error handling.
Add the following information:
### Clean up To clean up after the performance test, you can use the `purge-dialogs.js` test file. This file is specifically designed for cleanup purposes. It ensures that any resources created during the test, such as dialogs, are removed from the system. +Best practices for cleanup: +- Run cleanup immediately after completing your test session +- Verify cleanup success in the logs +- If cleanup fails, retry with increased timeout values +- For debugging purposes, you may want to preserve test data temporarily + To run the cleanup script, follow these steps:
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
tests/k6/tests/enduser/performance/README.md(1 hunks)tests/k6/tests/graphql/README.md(1 hunks)tests/k6/tests/serviceowner/performance/README.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
tests/k6/tests/enduser/performance/README.md
[grammar] ~74-~74: This phrase is duplicated. You should probably use “Test Results” only once.
Context: ...h.js \ --input tokens=personal ``` ## Test Results Test results can be found in github action run log a...
(PHRASE_REPETITION)
[typographical] ~75-~75: It seems that a comma is missing.
Context: ...d for exporting results to grafana, but so far results are exported to a private grafa...
(SO_COMMA)
tests/k6/tests/graphql/README.md
[grammar] ~60-~60: This phrase is duplicated. You should probably use “Test Results” only once.
Context: ...h.js \ --input tokens=personal ``` ## Test Results Test results can be found in github action run log a...
(PHRASE_REPETITION)
[typographical] ~61-~61: It seems that a comma is missing.
Context: ...d for exporting results to grafana, but so far results are exported to a private grafa...
(SO_COMMA)
🔇 Additional comments (4)
tests/k6/tests/graphql/README.md (1)
63-64: Expand TODO section with more context
The current TODO item "Fix reporting" lacks context. Consider:
- Describing the specific reporting issues
- Adding acceptance criteria
- Linking to related issues or documentation
tests/k6/tests/enduser/performance/README.md (2)
57-64: Enhance security-related documentation.
The .secrets example should clearly indicate that the ** are placeholders. Consider adding a note about secure handling of credentials and tokens.
```file
-TOKEN_GENERATOR_USERNAME:**
-TOKEN_GENERATOR_PASSWORD:**
+TOKEN_GENERATOR_USERNAME=<your-username-here>
+TOKEN_GENERATOR_PASSWORD=<your-password-here>
# Additional secrets...+> Note: Replace placeholder values with actual credentials. Never commit real credentials to version control.
---
`77-79`: **Expand the TODO section with specific requirements.**
The current TODO item "Fix reporting" is too vague. Consider adding more details about what needs to be fixed and any specific requirements or acceptance criteria.
</details>
<details>
<summary>tests/k6/tests/serviceowner/performance/README.md (1)</summary>
`96-100`: **Expand reporting and results documentation**
The test results and TODO sections need more detailed information:
- How to access the private Grafana instance
- What metrics are available and how to interpret them
- Specific details about what needs to be fixed in reporting
Would you like me to help create a more detailed results and reporting section?
</details>
</details>
</details>
<!-- This is an auto-generated comment by CodeRabbit for review status -->
dagfinno
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (13)
tests/k6/tests/graphql/README.md (4)
1-3: Enhance document structure with proper formatting.Consider improving the heading to better reflect the content and adding proper formatting for code elements.
-# Graphql get dialogs +# GraphQL Performance Tests -This directory holds a performance test with POST for `graphql`. The test file `graphql-search.js` is responsible for executing the performance test. It includes a list of end users (ssn) with pre-generated tokens and performs a POST request to the GraphQL endpoint with the payload `input: { party: ["urn:altinn:person:identifier-no:${identifier}"]}`. This test is designed to measure the performance of the GraphQL search functionality. +This directory holds a performance test with POST for GraphQL. The test file `graphql-search.js` is responsible for executing the performance test. It includes a list of end users (SSN) with pre-generated tokens and performs a POST request to the GraphQL endpoint with the following payload: + +```graphql +input: { + party: ["urn:altinn:person:identifier-no:${identifier}"] +} +``` + +This test is designed to measure the performance of the GraphQL search functionality.
18-29: Enhance security and clarity in command examples.
- Add a warning about handling credentials securely.
- Use more descriptive placeholder values.
- Add example values as comments.
-TOKEN_GENERATOR_USERNAME=<username> \ -TOKEN_GENERATOR_PASSWORD=<passwd> API_ENVIRONMENT=<(test|staging|yt01)> \ +# Ensure these credentials are kept secure and never committed to version control +TOKEN_GENERATOR_USERNAME=<your-username> \ # Example: "john.doe" +TOKEN_GENERATOR_PASSWORD=<your-password> \ # Example: Keep this secret! +API_ENVIRONMENT=<environment> \ # Example: "test"
31-36: Add more context to GitHub Actions instructions.Consider adding:
- Required permissions for running the workflow
- Expected duration of the test
- Where to find the results after completion
60-64: Improve results section clarity and TODO details.
- Fix grammar in the results section
- Expand the TODO with more context about the reporting issue
-Test results can be found in GitHub action run log and in App Insights. We are prepared for exporting results to grafana, but so far results are exported to a private grafana instance only, as can be seen from the .secrets listed earlier +Test results can be found in the GitHub Actions run log and in App Insights. While we are prepared for exporting results to Grafana, currently results are only exported to a private Grafana instance, as configured in the `.secrets` file. -## TODO -Fix reporting +## TODO +- Fix reporting issues: + - [ ] Configure public Grafana instance + - [ ] Set up proper metrics export + - [ ] Implement comprehensive test result visualization🧰 Tools
🪛 LanguageTool
[grammar] ~60-~60: This phrase is duplicated. You should probably use “Test Results” only once.
Context: ...h.js \ --input tokens=personal ``` ## Test Results Test results can be found in GitHub action run log a...(PHRASE_REPETITION)
[uncategorized] ~61-~61: You might be missing the article “the” here.
Context: ...st Results Test results can be found in GitHub action run log and in App Insights. We ...(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[typographical] ~61-~61: It seems that a comma is missing.
Context: ...d for exporting results to grafana, but so far results are exported to a private grafa...(SO_COMMA)
tests/k6/tests/enduser/performance/README.md (5)
8-11: Consider enhancing the test file section with more details.Add a brief description of what
enduser-search.jsdoes and its key features to help users understand its purpose without having to open the file.## Test file -The test file associated with this performance test is -- `enduser-search.js` +The test file associated with this performance test is: +- `enduser-search.js` - Implements sequential endpoint testing for end users, measuring response times and performance metrics.
12-24: Consider adding performance expectations or success criteria.The test description clearly outlines the endpoints being tested, but it would be helpful to include:
- Expected response time thresholds
- Success/failure criteria
- Performance benchmarks
32-42: Consider adding example commands with realistic values.While the instructions are clear, providing complete example commands with realistic values would make it easier for users to understand the expected format:
TOKEN_GENERATOR_USERNAME=<username> \ TOKEN_GENERATOR_PASSWORD=<passwd> API_ENVIRONMENT=<test|staging|yt01> \ ../../scripts/generate_tokens.sh ../../performancetest_data personal + +Example: +TOKEN_GENERATOR_USERNAME=testuser \ +TOKEN_GENERATOR_PASSWORD=secretpass API_ENVIRONMENT=test \ +../../scripts/generate_tokens.sh ../../performancetest_data personal
45-50: Add details about required parameters and their values.The GitHub Actions section would benefit from:
- List of required parameters
- Valid value ranges or examples
- Expected outcomes
74-78: Improve clarity of results section and TODO details.
- Fix grammar in the results section:
-## Test Results -Test results can be found in GitHub action run log and in App Insights. We are prepared for exporting results to grafana, but so far results are exported to a private grafana instance only, as can be seen from the `.secrets`listed earlier +## Test Results +Test results can be found in the GitHub Actions run log and in App Insights. While we're prepared for exporting results to Grafana, currently results are only exported to a private Grafana instance, as configured in the `.secrets` file.
- The TODO item "Fix reporting" is too vague. Consider expanding it with specific tasks or requirements.
🧰 Tools
🪛 LanguageTool
[grammar] ~74-~74: This phrase is duplicated. You should probably use “Test Results” only once.
Context: ...h.js \ --input tokens=personal ``` ## Test Results Test results can be found in GitHub action run log a...(PHRASE_REPETITION)
[typographical] ~75-~75: It seems that a comma is missing.
Context: ...d for exporting results to grafana, but so far results are exported to a private grafa...(SO_COMMA)
tests/k6/tests/serviceowner/performance/README.md (4)
9-14: Enhance test file descriptionsConsider adding brief descriptions for each test file to help users understand their specific purposes. For example:
The test files associated with this performance test are -create-dialog.js -create-remove-dialog.js -serviceowner-search.js -purge-dialogs.js (used for cleanup after test) +- `create-dialog.js` - Tests the performance of dialog creation endpoint +- `create-remove-dialog.js` - Evaluates the complete lifecycle of dialog creation and removal +- `serviceowner-search.js` - Measures search functionality performance +- `purge-dialogs.js` - Utility script for cleaning up test data after performance tests
16-16: Add missing article in heading-### Run Test +### Run the Test🧰 Tools
🪛 LanguageTool
[uncategorized] ~16-~16: Possible missing article found.
Context: ... (used for cleanup after test) ### Run Test To run the performance test, follow the...(AI_HYDRA_LEO_MISSING_THE)
40-42: Document GitHub Actions parametersConsider adding descriptions for the workflow parameters to help users make informed choices. For example:
2. Select "Run workflow" and fill in the required parameters: + - `vus`: Number of virtual users (concurrent load) + - `duration`: Test duration (e.g., "5m" for 5 minutes) + - `testSuitePath`: Path to the test script to execute + - `tokens`: Authentication token type to use ("personal", "enterprise", or "both") 3. Tag the performance test with a descriptive name.
96-100: Enhance results and TODO sectionsThe results and TODO sections could benefit from more detail:
- For results: Consider specifying what key metrics users should look for in App Insights and Grafana
- For TODO: Provide more context about what aspects of reporting need fixing
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
tests/k6/tests/enduser/performance/README.md(1 hunks)tests/k6/tests/graphql/README.md(1 hunks)tests/k6/tests/serviceowner/performance/README.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
tests/k6/tests/enduser/performance/README.md
[grammar] ~74-~74: This phrase is duplicated. You should probably use “Test Results” only once.
Context: ...h.js \ --input tokens=personal ``` ## Test Results Test results can be found in GitHub action run log a...
(PHRASE_REPETITION)
[typographical] ~75-~75: It seems that a comma is missing.
Context: ...d for exporting results to grafana, but so far results are exported to a private grafa...
(SO_COMMA)
tests/k6/tests/graphql/README.md
[grammar] ~60-~60: This phrase is duplicated. You should probably use “Test Results” only once.
Context: ...h.js \ --input tokens=personal ``` ## Test Results Test results can be found in GitHub action run log a...
(PHRASE_REPETITION)
[uncategorized] ~61-~61: You might be missing the article “the” here.
Context: ...st Results Test results can be found in GitHub action run log and in App Insights. We ...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[typographical] ~61-~61: It seems that a comma is missing.
Context: ...d for exporting results to grafana, but so far results are exported to a private grafa...
(SO_COMMA)
tests/k6/tests/serviceowner/performance/README.md
[uncategorized] ~16-~16: Possible missing article found.
Context: ... (used for cleanup after test) ### Run Test To run the performance test, follow the...
(AI_HYDRA_LEO_MISSING_THE)
🔇 Additional comments (3)
tests/k6/tests/graphql/README.md (2)
15-17: Fix incorrect directory path
42-50: Enhance security-related documentation
tests/k6/tests/enduser/performance/README.md (1)
1-3: LGTM! Clear and informative introduction.
The introduction effectively communicates the purpose, scope, and implementation details of the performance tests.
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (12)
tests/k6/tests/graphql/performance/README.md (2)
1-2: Improve title clarity and formattingThe current title "Graphql get dialogs" doesn't accurately reflect the content, as this README covers GraphQL search performance testing.
-# Graphql get dialogs +# GraphQL Search Performance Testing
53-53: Fix heading hierarchy and formatting
- Change the heading level from h5 to h4 for consistency
- Remove the trailing period from the heading
- Use fenced code blocks consistently throughout the document
🧰 Tools
🪛 Markdownlint
53-53: Expected: h4; Actual: h5
Heading levels should only increment by one level at a time(MD001, heading-increment)
53-53: Punctuation: '.'
Trailing punctuation in heading(MD026, no-trailing-punctuation)
tests/k6/tests/enduser/performance/README.md (6)
8-11: Consider enhancing the test file section with more details.Add a brief description of what
enduser-search.jsdoes and its key features to help developers understand its purpose without having to open the file.
37-42: Add example values for better clarity.Consider adding example values for the parameters to help users understand the expected format:
k6 run enduser-search.js -e API_VERSION=v1 \ -e API_ENVIRONMENT=<test|staging|yt01> \ --vus=<vus> --duration=<duration> +e API_ENVIRONMENT=test \ +--vus=10 --duration=30s
46-50: Document the required parameters for GitHub Actions.Add a list of the required parameters with descriptions and example values to help users fill in the workflow form correctly.
56-64: Improve clarity of secrets file example.The secrets file example should clarify which values are required vs optional:
-K6_CLOUD_PROJECT_ID=** -K6_CLOUD_TOKEN=** +K6_CLOUD_PROJECT_ID=<required_for_cloud_reporting> +K6_CLOUD_TOKEN=<required_for_cloud_reporting>
77-79: Enhance the test results section with more details.Consider adding:
- Expected format of the results
- How to interpret the results
- Links to relevant dashboards or monitoring tools
🧰 Tools
🪛 LanguageTool
[grammar] ~77-~77: This phrase is duplicated. You should probably use “Test Results” only once.
Context: ...h.js \ --input tokens=personal ``` ## Test Results Test results can be found in GitHub action run log a...(PHRASE_REPETITION)
[typographical] ~78-~78: It seems that a comma is missing.
Context: ...d for exporting results to grafana, but so far results are exported to a private grafa...(SO_COMMA)
67-67: Fix markdown formatting issues.
- Change the heading level from h5 to h4 by using one less
#- Remove the trailing period from the heading
- Use fenced code blocks consistently throughout the document
🧰 Tools
🪛 Markdownlint
67-67: Expected: h4; Actual: h5
Heading levels should only increment by one level at a time(MD001, heading-increment)
67-67: Punctuation: '.'
Trailing punctuation in heading(MD026, no-trailing-punctuation)
tests/k6/tests/serviceowner/performance/README.md (4)
1-3: Consider adding target audience information.The introduction effectively explains the purpose, but could benefit from specifying the intended audience (e.g., developers, QA engineers, DevOps) and any required expertise level.
5-15: Enhance prerequisites section with specific requirements.Consider adding:
- Minimum K6 version requirement
- Required permissions/roles for token generation
- Estimated disk space needed for test artifacts
- Any environment-specific requirements
24-35: Add example values and validation steps.The CLI instructions would be more user-friendly with:
- Example values for
<vus>and<duration>with recommended ranges- Steps to validate successful token generation
- Expected output examples
99-103: Expand the test results section.Consider adding:
- Key metrics to look for in the results
- Troubleshooting guide for common issues
- Links to example reports or dashboards
- Success criteria or baseline metrics
Also, the TODO item about fixing reporting should be tracked in an issue.
Would you like me to create a GitHub issue to track the reporting fixes?
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
tests/k6/tests/enduser/performance/README.md(1 hunks)tests/k6/tests/graphql/performance/README.md(1 hunks)tests/k6/tests/serviceowner/performance/README.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
tests/k6/tests/enduser/performance/README.md
[grammar] ~77-~77: This phrase is duplicated. You should probably use “Test Results” only once.
Context: ...h.js \ --input tokens=personal ``` ## Test Results Test results can be found in GitHub action run log a...
(PHRASE_REPETITION)
[typographical] ~78-~78: It seems that a comma is missing.
Context: ...d for exporting results to grafana, but so far results are exported to a private grafa...
(SO_COMMA)
tests/k6/tests/graphql/performance/README.md
[grammar] ~63-~63: This phrase is duplicated. You should probably use “Test Results” only once.
Context: ...h.js \ --input tokens=personal ``` ## Test Results Test results can be found in GitHub action run log a...
(PHRASE_REPETITION)
[typographical] ~64-~64: It seems that a comma is missing.
Context: ...d for exporting results to grafana, but so far results are exported to a private grafa...
(SO_COMMA)
🪛 Markdownlint
tests/k6/tests/enduser/performance/README.md
67-67: Expected: h4; Actual: h5
Heading levels should only increment by one level at a time
(MD001, heading-increment)
67-67: Punctuation: '.'
Trailing punctuation in heading
(MD026, no-trailing-punctuation)
65-65: Expected: fenced; Actual: indented
Code block style
(MD046, code-block-style)
tests/k6/tests/graphql/performance/README.md
53-53: Expected: h4; Actual: h5
Heading levels should only increment by one level at a time
(MD001, heading-increment)
53-53: Punctuation: '.'
Trailing punctuation in heading
(MD026, no-trailing-punctuation)
51-51: Expected: fenced; Actual: indented
Code block style
(MD046, code-block-style)
tests/k6/tests/serviceowner/performance/README.md
60-60: Punctuation: '.'
Trailing punctuation in heading
(MD026, no-trailing-punctuation)
58-58: Expected: fenced; Actual: indented
Code block style
(MD046, code-block-style)
🔇 Additional comments (4)
tests/k6/tests/graphql/performance/README.md (2)
56-61: Add explanation for architecture-specific settings
Explain why --container-architecture linux/amd64 is needed and when users might need to modify this setting.
66-67: Expand TODO section with specific tasks
The current TODO is too vague. Consider listing specific items that need attention:
- What aspects of reporting need fixing?
- Are there specific metrics missing?
- What's the target state for reporting?
tests/k6/tests/enduser/performance/README.md (1)
80-81: Expand the TODO section with more context.
The "Fix reporting" TODO is too vague. Please provide:
- What specific reporting issues need to be fixed
- Any known limitations or problems
- Planned improvements or solutions
tests/k6/tests/serviceowner/performance/README.md (1)
79-98: Add verification steps for cleanup process.
The cleanup section should include:
- How to verify successful cleanup
- Error handling steps if cleanup fails
- Warning about potential impact on shared environments
|
Add README.md for serviceowner/performance, enduser/performance and graphql/performance
Description
Related Issue(s)
Verification
Documentation
docs-directory, Altinnpedia or a separate linked PR in altinn-studio-docs., if applicable)Summary by CodeRabbit
New Features
Documentation