Release 3.2.0

Release 3.2.0

Author: pawelangelow

.ai/commands/e2e-generate.md

@@ -1,31 +1,45 @@
 ---
-description: Explore a page using Playwright MCP and generate E2E tests
-argument-hint: <url> [focus-area]
+description: Explore a page using Playwright MCP and generate E2E tests for a Jira ticket
+argument-hint: <ticket-id or ticket-url>
 ---
 
 # Generate E2E Tests
 
-Use Playwright MCP to explore a page, discover testable functionality, and generate E2E tests.
+Use Playwright MCP to explore a page, discover testable functionality, and generate E2E tests based on a Jira ticket.
 
 **Follow all standards in `.ai/rules/e2e-testing.md`**
 
+**Reference:** @tests/e2e-playwright/TEST_PLAN.md
+
+## Prerequisites
+
+- App must be running at `http://localhost:8080` for Playwright exploration
+
 ## Input
 
-1. **URL** (required) - Page to explore (e.g., `http://localhost:8080/browser`)
-2. **Focus area** (optional) - Specific functionality (e.g., "add key", "settings")
+1. **Ticket ID or URL** (required)
 
 ## Process
 
-### Step 1: Check Test Plan
+### Step 1: Fetch Jira Ticket Details
 
-Review `tests/e2e-playwright/TEST_PLAN.md` to find tests to implement:
-- ✅ = Already implemented (skip)
+Use the Jira API to get ticket information:
+- Summary and description
+- Acceptance criteria
+- Related components/features
+
+### Step 2: Check Test Plan
+
+Review `tests/e2e-playwright/TEST_PLAN.md` to find related tests:
+- ✅ = Already implemented (skip or verify)
 - 🔲 = Not implemented (create new)
 
-### Step 2: Explore the Page with Playwright MCP
+### Step 3: Explore the Page with Playwright MCP
+
+Navigate to the relevant page based on the ticket's feature area:
 
 ```
-browser_navigate_Playwright → url
+browser_navigate_Playwright → url (e.g., http://localhost:8080)
 browser_snapshot_Playwright
 browser_click_Playwright → element, ref
 browser_snapshot_Playwright (after each action)
@@ -36,34 +50,45 @@ Look for:
 - Element roles (button, combobox, grid) → use with `page.getByRole()`
 - Form field placeholders → use with `page.getByPlaceholder()`
 
-### Step 3: Check Existing Infrastructure
+### Step 4: Check Existing Infrastructure
 
 ```bash
 ls tests/e2e-playwright/tests/
 ls tests/e2e-playwright/pages/
 ls tests/e2e-playwright/test-data/
 ```
 
-### Step 4: Generate Test Artifacts
+### Step 5: Generate Test Artifacts
 
-Based on exploration, create/update:
+Based on exploration and ticket requirements, create/update:
 
 1. **Page Object** - `tests/e2e-playwright/pages/{feature}/{Feature}Page.ts`
 2. **Test Data Factory** - `tests/e2e-playwright/test-data/{feature}/index.ts`
 3. **Fixture** (if new page) - Update `tests/e2e-playwright/fixtures/base.ts`
 4. **Test File** - `tests/e2e-playwright/tests/{feature}/{action}/*.spec.ts`
 
-### Step 5: Verify
+### Step 6: Verify
+
+Run only the new tests using list reporter (no HTML report):
 
 ```bash
 cd tests/e2e-playwright
-npx playwright test --grep "<new-test-name>" --reporter=list
+npx playwright test tests/main/{feature}/{action}/ --project=chromium --reporter=list
 npm run lint && npx tsc --noEmit
 ```
 
-### Step 6: Update Test Plan
+**Note:** Use `--reporter=list` to avoid Playwright generating and hosting an HTML report. Use `--project=chromium` to run only browser tests (faster feedback).
+
+### Step 7: Update Test Plan
+
+Update `tests/e2e-playwright/TEST_PLAN.md` to match actual tests:
 
-Mark implemented tests as ✅ in `tests/e2e-playwright/TEST_PLAN.md`
+- **Rename** test case names to match the actual test titles in spec files
+- **Add** new test cases that were created
+- **Delete** test cases that were removed or consolidated
+- Mark implemented tests as ✅
+
+Test case names in TEST_PLAN.md should exactly match the test titles in spec files (e.g., `should open Help Center and display all menu options`).
 
 ## Exploration Checklist
 
@@ -96,7 +121,12 @@ Mark implemented tests as ✅ in `tests/e2e-playwright/TEST_PLAN.md`
 ## Example Usage
 
 ```
-@e2e-generate http://localhost:8080
-@e2e-generate http://localhost:8080/browser "add string key"
-@e2e-generate http://localhost:8080/workbench
+@e2e-generate RI-7992
+@e2e-generate https://redislabs.atlassian.net/browse/RI-7992
 ```
+
+The command will:
+1. Fetch ticket details from Jira
+2. Determine the relevant page/feature to test
+3. Explore the UI at http://localhost:8080
+4. Generate appropriate E2E tests based on ticket requirements

.ai/commands/generate-release-notes.md

@@ -84,8 +84,10 @@ For each ticket, analyze its essence to categorize it:
 
 * **Only tickets with the "Github-Issue" label should be included in the Bugs/Bug fixes section**
 * When processing tickets from JIRA query or CSV, filter bugs to only include those with the "Github-Issue" label
+* **Include all bugs that have the "Github-Issue" label**—every such ticket must appear in the Bugs section with no limit or additional filtering
 * Other bug tickets (without this label) should be excluded from the Bugs/Bug fixes section
 * **Bugs with Github-Issue label should ONLY appear in the Bugs section, NOT in Headlines or Details sections**
+* **Always list each of these bugs with the GitHub issue link**: For every ticket in the Bugs section (tickets with "Github-Issue" label), output the line in the form `[#ISSUE-NUMBER](https://github.com/redis/RedisInsight/issues/ISSUE-NUMBER) [Short description]`. Resolve the GitHub issue number from: (1) JIRA labels such as `Github-4658` (use the number part), (2) JIRA description or linked PR body (e.g. "References #5381", "Closes #5382"), or (3) search on GitHub (repo: redis/RedisInsight) for the issue or PR that matches the bug (e.g. by JIRA key like RI-7894 or by summary). If the number cannot be determined, still include the short description but add a note to look up the link.
 
 **Feature indicators:**
 
@@ -105,9 +107,9 @@ Use the template from `docs/release-notes/RELEASE_NOTES_TEMPLATE.md` as a refere
 
 ### Format Selection
 
-* **If only bugs (with "Github-Issue" label)**: Use simple "Bug fixes" section only
+* **If only bugs (with "Github-Issue" label)**: Use simple "Bug fixes" section only; include every ticket that has the "Github-Issue" label
 * **If features/improvements exist**: Use full format with "Headlines", "Details", and "Bugs" sections
-  * Note: The "Bugs" section should only include tickets with the "Github-Issue" label
+  * Note: The "Bugs" section must include all tickets with the "Github-Issue" label (include every one)
 
 ### Section Organization Rules
 
@@ -137,9 +139,9 @@ Use the template from `docs/release-notes/RELEASE_NOTES_TEMPLATE.md` as a refere
 * [#ISSUE-NUMBER](https://github.com/redis/RedisInsight/issues/ISSUE-NUMBER) [Summary] (for GitHub issues, use link format)
 
 ### Bugs (if features exist) OR Bug fixes (if only bugs - see 3.0.2 example)
-* **IMPORTANT: Only include tickets with the "Github-Issue" label in this section**
-* [Short description of problem and fix] (for JIRA tickets, don't include ticket ID)
-* [#ISSUE-NUMBER](https://github.com/redis/RedisInsight/issues/ISSUE-NUMBER) [Summary] (for GitHub issues, use link format)
+* **IMPORTANT: Include all tickets with the "Github-Issue" label in this section (every one, no limit). Always list each bug with its GitHub issue link.**
+* Each line must be: `[#ISSUE-NUMBER](https://github.com/redis/RedisInsight/issues/ISSUE-NUMBER) [Short description of problem and fix]`
+* Resolve ISSUE-NUMBER from JIRA labels (e.g. Github-4658 → 4658), ticket/PR references, or GitHub search if needed.
 
 **SHA-512 Checksums**
 
@@ -150,8 +152,9 @@ https://redis.io/docs/latest/develop/tools/insight/release-notes/v.[VERSION]/
 
 **Important formatting notes from GitHub releases:**
 
-* **For JIRA tickets**: Do NOT include ticket IDs (like `#<ticket-number>` or `#<ticket-key>`). Instead, provide a very short description of what was the problem and what was fixed. This information can be found in the JIRA ticket description or the GitHub pull request linked to the ticket.
-* **For GitHub issues**: Use actual links in format `[#<issue-number>](https://github.com/redis/RedisInsight/issues/<issue-number>)` (not just `#<issue-number>` or `#<ticket-key>`)
+* **For the Bugs section (tickets with "Github-Issue" label)**: Always list each bug with its GitHub issue link: `[#<issue-number>](https://github.com/redis/RedisInsight/issues/<issue-number>) [Short description]`. Resolve the issue number from JIRA labels (e.g. `Github-4658`), from "References #NNNN" / "Closes #NNNN" in linked PRs or descriptions, or by searching GitHub (repo: redis/RedisInsight) for the matching issue.
+* **For other JIRA tickets** (Headlines/Details): Do NOT include ticket IDs. Provide a very short description of what was added or fixed.
+* **For GitHub issues** (when referenced elsewhere): Use actual links in format `[#<issue-number>](https://github.com/redis/RedisInsight/issues/<issue-number>)` (not just `#<issue-number>` or `#<ticket-key>`).
 * Use "SHA-512 Checksums" for all releases
 * Keep descriptions concise and user-focused
 * Headlines should highlight the most impactful user-facing changes

.cursor/agents/test-runner.md

@@ -0,0 +1,24 @@
+---
+name: test-runner
+model: composer-1.5
+description: Test automation expert. Use proactively to run tests and fix failures.
+---
+
+You are a test automation expert.
+
+When you see code changes, proactively run appropriate tests.
+
+When completing a major task, run all tests to ensure the task is complete.
+
+If tests fail:
+
+1. Analyze the failure output
+2. Identify the root cause
+3. Fix the issue while preserving test intent
+4. Re-run to verify
+
+Report test results with:
+
+- Number of tests passed/failed
+- Summary of any failures
+- Changes made to fix issues

.github/build/build.Dockerfile

@@ -1,4 +1,4 @@
-FROM node:20.14-alpine
+FROM node:22.12.0-alpine
 
 # runtime args and environment variables
 ARG DIST=Redis-Insight.tar.gz

.github/build/release-docker.sh

@@ -2,7 +2,7 @@
 set -e
 
 HELP="Args:
--v - Semver (3.0.3)
+-v - Semver (3.2.0)
 -d - Build image repository (Ex: -d redisinsight)
 -r - Target repository (Ex: -r redis/redisinsight)
 "

.github/workflows/enforce-branch-name-rules.yml

@@ -10,19 +10,21 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Check branch name
+        env:
+          BRANCH_NAME: ${{ github.head_ref }}
         run: |
-          echo "Source branch: ${{ github.head_ref }}"
-          if [[ "${{ github.head_ref }}" != feature/* && \
-                "${{ github.head_ref }}" != bugfix/* && \
-                "${{ github.head_ref }}" != release/* && \
-                "${{ github.head_ref }}" != dependabot/* && \
-                "${{ github.head_ref }}" != latest && \
-                "${{ github.head_ref }}" != fe/* && \
-                "${{ github.head_ref }}" != be/* && \
-                "${{ github.head_ref }}" != e2e/* && \
-                "${{ github.head_ref }}" != test/* && \
-                "${{ github.head_ref }}" != docs/* && \
-                "${{ github.head_ref }}" != ric/* ]]; then
+          echo "Source branch: $BRANCH_NAME"
+          if [[ "$BRANCH_NAME" != feature/* && \
+                "$BRANCH_NAME" != bugfix/* && \
+                "$BRANCH_NAME" != release/* && \
+                "$BRANCH_NAME" != dependabot/* && \
+                "$BRANCH_NAME" != latest && \
+                "$BRANCH_NAME" != fe/* && \
+                "$BRANCH_NAME" != be/* && \
+                "$BRANCH_NAME" != e2e/* && \
+                "$BRANCH_NAME" != test/* && \
+                "$BRANCH_NAME" != docs/* && \
+                "$BRANCH_NAME" != ric/* ]]; then
             echo "❌ Pull requests to 'main' are only allowed from 'feature/**', 'bugfix/**', 'release/**', 'dependabot/**', 'latest', 'test/**', 'docs/**', or 'ric/**' branches."
             exit 1
           fi

.github/workflows/pipeline-build-macos.yml

@@ -117,7 +117,6 @@ jobs:
 
     env:
       APPLE_ID: ${{ secrets.APPLE_ID }}
-      APPLE_ID_PASSWORD: ${{ secrets.APPLE_ID_PASSWORD }}
       APPLE_TEAM_ID: ${{ secrets.APPLE_TEAM_ID }}
       APPLE_APP_SPECIFIC_PASSWORD: ${{ secrets.APPLE_APP_SPECIFIC_PASSWORD }}
       USE_HARD_LINKS: ${{ vars.USE_HARD_LINKS }}

.github/workflows/publish-stores.yml

@@ -33,13 +33,15 @@ jobs:
         run: |
           appVersion=$(jq -r '.version' redisinsight/package.json)
 
+          # Publish desktop image
           docker login -u $DOCKER_USER -p $DOCKER_PASS
 
           ./.github/build/release-docker.sh \
           -d redisinsight \
           -r $DOCKER_REPO \
           -v $appVersion
 
+          # Publish cloud image
           docker login -u $DOCKER_V1_USER -p $DOCKER_V1_PASS
 
           ./.github/build/release-docker.sh \

.github/workflows/tests-e2e-playwright-docker.yml

@@ -90,6 +90,8 @@ jobs:
           OSS_STANDALONE_V8_HOST: 'host.docker.internal'
           OSS_STANDALONE_EMPTY_HOST: 'host.docker.internal'
           OSS_STANDALONE_BIG_HOST: 'host.docker.internal'
+          OSS_STANDALONE_TLS_HOST: 'host.docker.internal'
+          OSS_CLUSTER_HOST: 'host.docker.internal'
 
       - name: Upload test results
         if: ${{ !cancelled() }}

.github/workflows/tests-e2e-playwright-lint.yml

@@ -23,7 +23,11 @@ jobs:
         working-directory: ${{ env.E2E_DIR }}
         run: npm run lint
 
+      - name: Check formatting
+        working-directory: ${{ env.E2E_DIR }}
+        run: npm run format:check
+
       - name: Type check E2E code
         working-directory: ${{ env.E2E_DIR }}
-        run: npx tsc --noEmit
+        run: npm run type-check