Release/2.69.9 #5271
Release/2.69.9 #5271
Conversation
…lumns-popover Fe/feature/ri 7431 keys header columns popover
RI-7431: Change add key button view
RI-7431: No results found
…over-layout RI-7431: Delete key popover layout
- no longer silently mark the onboarding as seen, unless it's explicitly dismissed by the user - update the onboarding spacings to match Figma
…tible (#4964) - hide the "Getting Started" button (leading to the "Create Index" wizard) from the "No Results/Manage Indexes/Saved Queries" panels on the Vector Search page when the Redis version is older than 7.2 and doesn't support Vector Sets
* RI-7370: add tag and save when apply clicked with value inside new tag input * RI-7370: add styles for input * RI-7370: reduce min-width * RI-7370: fix review comments * RI-7370: fix review comments
#4971) * RI-7431: fix key details header layout and rework confirmation popover * RI-7431: add data-testid to the confirm popover + fix tests * RI-7431: address review comments
- update the interface and the way we serve the data for the infinite notification, so it will resemble more closely the expected format by Redis UI - rework the way we show the default "X" button for dismissing notifications - update the variant to reflect the expected design
…ta is imported (#4978) - extend the success notifications api to allow overriding the action and "x" dismiss buttons - rework the visuals of the "upload data bulk" notification
* RI-7459: brace-expansion * RI-7459: axios * RI-7459: vite * RI-7459: electron
* RI-7459: axios * RI-7459: brace-expansion * RI-7459: brace-expansion 2.0.2 * RI-7459: connect-timeout * RI-7459: ioredis-mock, @nestjs-cli
* Increase text size for command helper, cli and profiler badges * force the CLI font to the instance name, at least until global font is refactored.
…hown (#4977) Since ConfirmationPopover is "outside" the click detector "jurisdiction", clicking anywhere on it unmounts the editor and therefore, form submission does not happen
- rework the spacing for the tabs of the insights panel - rework the "tutorials" visuals in the insights panel - rework the visuals of the "tips" section in the "insights" panel - scroll the tutorial to the top when changing pages - update popover in tutorials - update visuals of the pagination buttons in the tutorials
* RI-7431: rework ff for vector search * RI-7546: disable onboarding after successful passing all steps * RI-7546: fix pr comments + hid more promotion buttons with text related to it * RI-7546: fix tests
…5225) Bumps [js-yaml](https://github.com/nodeca/js-yaml) from 3.14.1 to 3.14.2. - [Changelog](https://github.com/nodeca/js-yaml/blob/master/CHANGELOG.md) - [Commits](nodeca/js-yaml@3.14.1...3.14.2) --- updated-dependencies: - dependency-name: js-yaml dependency-version: 3.14.2 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* feat: add semantic version utils and comprehensive tests for instanceModules - Add convertToSemanticVersion function to convert numeric versions to semantic format - Add ensureSemanticVersion function with null safety checks for instance modules - Create comprehensive test suite using DBInstanceFactory and it.each patterns References: #RI-7831
* RI-7786: fix ClusterNodesTable * RI-7786: simplify isMaxColumnFieldValue * RI-7786: show loading state only during initial load or missing data * RI-7786: remove leftover styles * RI-7786: update styled divs
* feat(ui): create shared AnalysisPageContainer component * refactor(ui): use shared AnalysisPageContainer in Database Analysis page * fix(ui): add consistent padding to Overview page using shared container * refactor(ui): replace local styles with styled-components in ClusterDetailsPage * fix(ui): add consistent padding to Slow Log page using shared container * fix(ui): integrate AnalyticsPageHeader in ClusterDetails and SlowLog pages * refactor(ui): clean up styles in ClusterDetailsPage References: #RI-7785
* fix(ui): align Coplit and Insights icons on Databases page References: #RI-7774
Remove vertical padding from db index button container and add inline-flex display to tooltip anchor for proper alignment. Add InstanceHeader.stories.tsx References: #RI-7835
|
|
![jit-ci[bot]](https://avatars.githubusercontent.com/in/142441?s=60&v=4){kind=small}
There was a problem hiding this comment.
❌ Jit has detected 15 important findings in this PR that you should review.
The first 10 findings are detailed below as separate comments.
Click here to view all the findings on Jit.
It’s highly recommended that you fix these security issues before merging.
Alternatively, comment #jit_ignore_all in this PR to ignore all findings. Admin privileges required.
Repository Risks:
- Critical Severity Findings: Indicates that the resource has critical severity security findings that need immediate action.
- Internally Accessible: Accessible only within the internal network, reducing exposure to external threats but still requiring proper controls.
- Database Integration: Connects to a database, often involving sensitive data that must be securely managed.
- Production: Critical as it operates in a live production environment, directly impacting users and business operations.
Repository Context:
graph LR
GitHub$Repository_U23_redis/RedisInsight["GitHub Repository<br/>redis/RedisInsight"]:::GitHub$Repository
DBIntegration_U23_redis["DBIntegration<br/>redis"]:::DBIntegration
GitHub$Actions_U23_pipeline_U2D_build_U2D_windows_U2E_yml["GitHub Actions<br/>pipeline-build-windows.yml"]:::GitHub$Actions
GitHub$Repository_U23_redis/RedisInsight -- "Is accessible to" --> DBIntegration_U23_redis
GitHub$Repository_U23_redis/RedisInsight -- "Has" --> GitHub$Actions_U23_pipeline_U2D_build_U2D_windows_U2E_yml
| ); | ||
| } | ||
|
|
||
| const fileStream = fs.createReadStream(collectionFilePath); |
There was a problem hiding this comment.
Security control: Static Code Analysis Semgrep Pro
Javascript.Nestjs.File.Fs-Nestjs.Fs-Nestjs
The application builds a file path from potentially untrusted data, which can lead to a path traversal vulnerability. An attacker can manipulate the path which the application uses to access files. If the application does not validate user input and sanitize file paths, sensitive files such as configuration or user data can be accessed, potentially creating or overwriting files. To prevent this vulnerability, validate and sanitize any input that is used to create references to file paths. Also, enforce strict file access controls. For example, choose privileges allowing public-facing applications to access only the required files.
Severity: HIGH
Why should you fix this issue?
This code introduces a vulnerability that could compromise the security of your production environment. In production, where reliability and security are paramount, even a small vulnerability can be exploited to cause significant damage, leading to unauthorized access or service disruption.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "javascript.nestjs.file.fs-nestjs.fs-nestjs" in redisinsight/api/src/modules/bulk-actions/bulk-import.service.ts; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| echo "❌ Pull requests to 'main' are only allowed from 'feature/**', 'bugfix/**', 'release/**', 'dependabot/**', 'latest' or 'ric/**' branches." | ||
| echo "❌ Pull requests to 'main' are only allowed from 'feature/**', 'bugfix/**', 'release/**', 'dependabot/**', 'latest', 'test/**', 'docs/**', or 'ric/**' branches." | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
Security control: Static Code Analysis Semgrep Pro
Yaml.Github-Actions.Security.Run-Shell-Injection.Run-Shell-Injection
Using variable interpolation ${{...}} with github context data in a run: step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. github context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with env: to store the data and use the environment variable in the run: script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".
Severity: HIGH
Why should you fix this issue?
This code introduces a vulnerability that could compromise the security of your production environment. In production, where reliability and security are paramount, even a small vulnerability can be exploited to cause significant damage, leading to unauthorized access or service disruption.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "yaml.github-actions.security.run-shell-injection.run-shell-injection" in .github/workflows/enforce-branch-name-rules.yml; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
|
|
||
| FROM redis:7.0.8 | ||
| FROM --platform=linux/amd64 redis:7.0.8 |
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM --platform=linux/amd64 redis:7.0.8 | |
| FROM --platform=linux/amd64 redis:7.0.8 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in tests/e2e/rte/oss-cluster-7-rs/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
|
|
||
| FROM redis:7.0.0 | ||
| FROM --platform=linux/amd64 redis:7.0.0 |
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM --platform=linux/amd64 redis:7.0.0 | |
| FROM --platform=linux/amd64 redis:7.0.0 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in tests/e2e/rte/oss-cluster-7/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| FROM --platform=linux/amd64 redislabs/rejson:1.0.8 as rejson | ||
|
|
||
| FROM redis:5 | ||
| FROM --platform=linux/amd64 redis:5 |
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM --platform=linux/amd64 redis:5 | |
| FROM --platform=linux/amd64 redis:5 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in redisinsight/api/test/test-runs/oss-st-5/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| @@ -1,4 +1,4 @@ | |||
| FROM bitnami/redis:6.0.8 | |||
| FROM bitnamilegacy/redis:6.0.8 | |||
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM bitnamilegacy/redis:6.0.8 | |
| FROM bitnamilegacy/redis:6.0.8 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in tests/e2e/rte/oss-standalone-tls/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| @@ -1,4 +1,4 @@ | |||
| FROM bitnami/redis-cluster:6.0.8 | |||
| FROM bitnamilegacy/redis-cluster:6.0.8 | |||
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM bitnamilegacy/redis-cluster:6.0.8 | |
| FROM bitnamilegacy/redis-cluster:6.0.8 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in redisinsight/api/test/test-runs/oss-clu-tls/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| @@ -1,4 +1,4 @@ | |||
| FROM bitnami/redis:6.0.8 | |||
| FROM bitnamilegacy/redis:6.0.8 | |||
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM bitnamilegacy/redis:6.0.8 | |
| FROM bitnamilegacy/redis:6.0.8 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in redisinsight/api/test/test-runs/oss-st-6-tls-auth/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| @@ -1,3 +1,3 @@ | |||
| FROM bitnami/redis-cluster:6.2.6 | |||
| FROM bitnamilegacy/redis-cluster:6.2.6 | |||
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM bitnamilegacy/redis-cluster:6.2.6 | |
| FROM bitnamilegacy/redis-cluster:6.2.6 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in redisinsight/api/test/test-runs/oss-clu/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| @@ -1,4 +1,4 @@ | |||
| FROM bitnami/redis:6.2.4 | |||
| FROM bitnamilegacy/redis:6.2.4 | |||
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM bitnamilegacy/redis:6.2.4 | |
| FROM bitnamilegacy/redis:6.2.4 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in redisinsight/api/test/test-runs/oss-st-6-tls/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
Resolve conflicts
* RI-000: fix e2e workflows * RI-000: fix e2e workflows + eslint
Merge from latest
There was a problem hiding this comment.
❌ Jit has detected 15 important findings in this PR that you should review.
The first 10 findings are detailed below as separate comments.
Click here to view all the findings on Jit.
It’s highly recommended that you fix these security issues before merging.
Alternatively, comment #jit_ignore_all in this PR to ignore all findings. Admin privileges required.
Until now, you ignored/fixed 13 findings.
|
|
||
| FROM redis:7.0.8 | ||
| FROM --platform=linux/amd64 redis:7.0.8 |
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM --platform=linux/amd64 redis:7.0.8 | |
| FROM --platform=linux/amd64 redis:7.0.8 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in tests/e2e/rte/oss-cluster-7-rs/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
|
|
||
| FROM redis:7.0.0 | ||
| FROM --platform=linux/amd64 redis:7.0.0 |
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM --platform=linux/amd64 redis:7.0.0 | |
| FROM --platform=linux/amd64 redis:7.0.0 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in tests/e2e/rte/oss-cluster-7/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| FROM --platform=linux/amd64 redislabs/rejson:1.0.8 as rejson | ||
|
|
||
| FROM redis:5 | ||
| FROM --platform=linux/amd64 redis:5 |
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM --platform=linux/amd64 redis:5 | |
| FROM --platform=linux/amd64 redis:5 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in redisinsight/api/test/test-runs/oss-st-5/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| @@ -1,4 +1,4 @@ | |||
| FROM bitnami/redis:6.0.8 | |||
| FROM bitnamilegacy/redis:6.0.8 | |||
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM bitnamilegacy/redis:6.0.8 | |
| FROM bitnamilegacy/redis:6.0.8 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in tests/e2e/rte/oss-standalone-tls/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| @@ -1,4 +1,4 @@ | |||
| FROM bitnami/redis-cluster:6.0.8 | |||
| FROM bitnamilegacy/redis-cluster:6.0.8 | |||
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM bitnamilegacy/redis-cluster:6.0.8 | |
| FROM bitnamilegacy/redis-cluster:6.0.8 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in redisinsight/api/test/test-runs/oss-clu-tls/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| @@ -1,4 +1,4 @@ | |||
| FROM bitnami/redis:6.0.8 | |||
| FROM bitnamilegacy/redis:6.0.8 | |||
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM bitnamilegacy/redis:6.0.8 | |
| FROM bitnamilegacy/redis:6.0.8 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in redisinsight/api/test/test-runs/oss-st-6-tls-auth/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| @@ -1,3 +1,3 @@ | |||
| FROM bitnami/redis-cluster:6.2.6 | |||
| FROM bitnamilegacy/redis-cluster:6.2.6 | |||
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM bitnamilegacy/redis-cluster:6.2.6 | |
| FROM bitnamilegacy/redis-cluster:6.2.6 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in redisinsight/api/test/test-runs/oss-clu/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| @@ -1,4 +1,4 @@ | |||
| FROM bitnami/redis:6.2.4 | |||
| FROM bitnamilegacy/redis:6.2.4 | |||
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM bitnamilegacy/redis:6.2.4 | |
| FROM bitnamilegacy/redis:6.2.4 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in redisinsight/api/test/test-runs/oss-st-6-tls/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| @@ -1,4 +1,4 @@ | |||
| FROM bitnami/redis:6.0.8 | |||
| FROM bitnamilegacy/redis:6.0.8 | |||
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM bitnamilegacy/redis:6.0.8 | |
| FROM bitnamilegacy/redis:6.0.8 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in redisinsight/api/test/test-runs/oss-st-6-tls-auth-ssh/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| @@ -1,4 +1,4 @@ | |||
| FROM redislabs/redis:6.2.8-50 | |||
| FROM redislabs/redis:8.0.2-17 | |||
There was a problem hiding this comment.
Security control: Docker Scan
Image User Should Not Be 'Root'
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Severity: HIGH
Fix suggestion:
This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.
Suggestion guidelines
- First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this:
docker run <image> whoami. If it returnsroot, then you should consider using a non-root user, by following one of the next steps:- If a non-root user already exists in your container, consider using it.
- If not, you can create a new user by adding a
USERcommand to the Dockerfile, with a non-root user as argument, for example:USER <non-root-user-name>.
| FROM redislabs/redis:8.0.2-17 | |
| FROM redislabs/redis:8.0.2-17 | |
| RUN addgroup --system <group> | |
| RUN adduser --system <user> --ingroup <group> | |
| USER <user>:<group> | |
Why should you fix this issue?
This Dockerfile introduces a container vulnerability. In a production environment, using insecure container configurations or outdated base images can lead to significant security risks. If an attacker exploits a vulnerability in the container, it could compromise the entire application or lead to unauthorized access.
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Image user should not be 'root'" in tests/e2e/rte/redis-enterprise/Dockerfile; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
ArtemHoruzhenko
requested review from
ArtemHoruzhenko,
dantovska,
pawelangelow,
pd-redis and
valkirilov
as code owners
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| secrets: inherit | ||
| with: | ||
| group_tests: 'without_e2e' | ||
| group_tests: "without_e2e" |
There was a problem hiding this comment.
Bug: Release workflow passes undefined input to tests workflow
The release-prod.yml workflow passes group_tests: "without_e2e" to tests.yml, but the tests.yml workflow_call inputs no longer define group_tests (it was removed in this PR). This will cause the workflow to fail or produce unexpected behavior when triggering a production release from the latest branch.
| startsWith(github.ref_name, 'bugfix/') || | ||
| startsWith(github.ref_name, 'ric/') || | ||
| contains(github.event.pull_request.labels.*.name, 'run-all-tests') || | ||
| contains(github.event.pull_request.labels.*.name, 'run-frontend-tests') |
There was a problem hiding this comment.
Bug: Release workflows will skip all tests due to branch conditions
The if conditions on frontend-tests, backend-tests, and integration-tests jobs only match branch patterns like fe/, fe-be/, feature/, bugfix/, and ric/, plus PR labels. When release-stage.yml (triggered on release/**) or release-prod.yml (triggered on latest) calls this workflow, none of these conditions match because these are push events without PR label context. This means all tests will be silently skipped during release builds, allowing untested code to be released.
What
Testing
Note
Cursor Bugbot is generating a summary for commit 85e4c3d. Configure here.