diff --git a/.github/workflows/e2e-tests-cypress-template.yml b/.github/workflows/e2e-tests-cypress-template.yml index f35dec5d205e..5822d06757da 100644 --- a/.github/workflows/e2e-tests-cypress-template.yml +++ b/.github/workflows/e2e-tests-cypress-template.yml @@ -249,7 +249,7 @@ jobs: ref: ${{ inputs.commit_sha }} fetch-depth: 1 - name: ci/dispatch-begin - uses: mattermost/mattermost-test-system-io/.github/actions/test-system-io-dispatch-begin@a2ea7f005484c28fedf51e16645f6d3bd683fd63 # 2026-05-16 + uses: mattermost/mattermost-test-system-io/.github/actions/test-system-io-dispatch-begin@1631d8fcea24f4545a0b3b7f77e41c2fe0be4418 # 2026-07-28 with: use-staging: ${{ vars.E2E_USE_STAGING_TEST_IO_URL != 'false' }} framework: cypress @@ -332,7 +332,7 @@ jobs: working-directory: e2e-tests run: make start-server - name: ci/dispatch-run - uses: mattermost/mattermost-test-system-io/.github/actions/test-system-io-dispatch-run@a2ea7f005484c28fedf51e16645f6d3bd683fd63 # 2026-05-16 + uses: mattermost/mattermost-test-system-io/.github/actions/test-system-io-dispatch-run@1631d8fcea24f4545a0b3b7f77e41c2fe0be4418 # 2026-07-28 with: use-staging: ${{ vars.E2E_USE_STAGING_TEST_IO_URL != 'false' }} framework: cypress @@ -377,7 +377,7 @@ jobs: - name: ci/run-summary id: summary continue-on-error: true - uses: mattermost/mattermost-test-system-io/.github/actions/test-system-io-summary@a2ea7f005484c28fedf51e16645f6d3bd683fd63 # 2026-05-16 + uses: mattermost/mattermost-test-system-io/.github/actions/test-system-io-summary@1631d8fcea24f4545a0b3b7f77e41c2fe0be4418 # 2026-07-28 with: use-staging: ${{ vars.E2E_USE_STAGING_TEST_IO_URL != 'false' }} composite-identity: ${{ needs.prepare-run.outputs.composite-identity-json }} diff --git a/.github/workflows/e2e-tests-playwright-template.yml b/.github/workflows/e2e-tests-playwright-template.yml index 9eadd4ec6c06..af819e039f34 100644 --- a/.github/workflows/e2e-tests-playwright-template.yml +++ b/.github/workflows/e2e-tests-playwright-template.yml @@ -232,7 +232,7 @@ jobs: ref: ${{ inputs.commit_sha }} fetch-depth: 1 - name: ci/dispatch-begin - uses: mattermost/mattermost-test-system-io/.github/actions/test-system-io-dispatch-begin@a2ea7f005484c28fedf51e16645f6d3bd683fd63 # 2026-05-16 + uses: mattermost/mattermost-test-system-io/.github/actions/test-system-io-dispatch-begin@1631d8fcea24f4545a0b3b7f77e41c2fe0be4418 # 2026-07-28 with: use-staging: ${{ vars.E2E_USE_STAGING_TEST_IO_URL != 'false' }} framework: playwright @@ -317,7 +317,7 @@ jobs: working-directory: e2e-tests/playwright run: npx playwright test --project=setup - name: ci/dispatch-run - uses: mattermost/mattermost-test-system-io/.github/actions/test-system-io-dispatch-run@a2ea7f005484c28fedf51e16645f6d3bd683fd63 # 2026-05-16 + uses: mattermost/mattermost-test-system-io/.github/actions/test-system-io-dispatch-run@1631d8fcea24f4545a0b3b7f77e41c2fe0be4418 # 2026-07-28 with: use-staging: ${{ vars.E2E_USE_STAGING_TEST_IO_URL != 'false' }} framework: playwright @@ -363,7 +363,7 @@ jobs: - name: ci/run-summary id: summary continue-on-error: true - uses: mattermost/mattermost-test-system-io/.github/actions/test-system-io-summary@a2ea7f005484c28fedf51e16645f6d3bd683fd63 # 2026-05-16 + uses: mattermost/mattermost-test-system-io/.github/actions/test-system-io-summary@1631d8fcea24f4545a0b3b7f77e41c2fe0be4418 # 2026-07-28 with: use-staging: ${{ vars.E2E_USE_STAGING_TEST_IO_URL != 'false' }} composite-identity: ${{ needs.prepare-run.outputs.composite-identity-json }} diff --git a/docs/main/deployment-guide/server/kubernetes/deploy-k8s.mdx b/docs/main/deployment-guide/server/kubernetes/deploy-k8s.mdx index 0cdeda51f9dc..585a25bf6c6e 100644 --- a/docs/main/deployment-guide/server/kubernetes/deploy-k8s.mdx +++ b/docs/main/deployment-guide/server/kubernetes/deploy-k8s.mdx @@ -32,34 +32,34 @@ The Mattermost Kubernetes Operator can be installed using Helm. 1. Install Helm (version 3.13.0 or later). See the [Helm quickstart documentation](https://helm.sh/docs/using_helm/) for installation instructions. 2. Add the Mattermost Helm repository: -> ``` sh -> helm repo add mattermost https://helm.mattermost.com -> ``` + ``` sh + helm repo add mattermost https://helm.mattermost.com + ``` 3. Create a file named `config.yaml` and populate it with the contents of the [Mattermost operator values file](https://github.com/mattermost/mattermost-helm/blob/master/charts/mattermost-operator/values.yaml). This file allows for customization of the operator. 4. Create a namespace for the Mattermost Operator: -> ``` sh -> kubectl create ns mattermost-operator -> ``` + ``` sh + kubectl create ns mattermost-operator + ``` 5. Install the Mattermost Operator. If you don't specify a version, the latest version of the Mattermost Operator will be installed. We recommend using the latest version of the Mattermost Operator. -> ``` sh -> helm install <your-release-name> mattermost/mattermost-operator -n -> ``` -> -> For example: -> -> ``` sh -> helm install mattermost-operator mattermost/mattermost-operator -n mattermost-operator -> ``` -> -> To use your custom `config.yaml` file: -> -> ``` sh -> helm install mattermost-operator mattermost/mattermost-operator -n mattermost-operator -f config.yaml -> ``` + ``` sh + helm install mattermost/mattermost-operator -n + ``` + + For example: + + ``` sh + helm install mattermost-operator mattermost/mattermost-operator -n mattermost-operator + ``` + + To use your custom `config.yaml` file: + + ``` sh + helm install mattermost-operator mattermost/mattermost-operator -n mattermost-operator -f config.yaml + ``` ### Step 3: Deploy Mattermost @@ -72,71 +72,71 @@ The Mattermost Kubernetes Operator can be installed using Helm. 1. **(Mattermost Enterprise only)** Create a Mattermost license secret. Create a file named `mattermost-license-secret.yaml` with the following content, replacing `[LICENSE_FILE_CONTENTS]` with your actual license: -> ``` yaml -> apiVersion: v1 -> kind: Secret -> metadata: -> name: my-mattermost-license -> type: Opaque -> stringData: -> license: -> ``` + ``` yaml + apiVersion: v1 + kind: Secret + metadata: + name: my-mattermost-license + type: Opaque + stringData: + license: + ``` 2. Create a Mattermost installation manifest file named `mattermost-installation.yaml`. File names in this guide are suggestions; you can use different names. Use the following template, adjusting the values as needed: -> ``` yaml -> apiVersion: installation.mattermost.com/v1beta1 -> kind: Mattermost -> metadata: -> name: # Example: mm-example-full -> spec: -> size: # Example: 5000users -> ingress: -> enabled: true -> host: # Example: example.mattermost-example.com -> annotations: -> kubernetes.io/ingress.class: nginx -> version: # Example: 9.3.0 -> licenseSecret: "" # If you created a license secret, put the name here -> ``` -> -> Key fields in the manifest include: -> -> - `metadata.name`: The name of your Mattermost deployment in Kubernetes. -> - `spec.size`: The size of your installation (e.g., "100users", "1000users", etc.). -> - `spec.ingress.host`: The DNS name for your Mattermost installation. -> - `spec.version`: The Mattermost version. See the [server version archive](/product-overview/version-archive) for available versions. You should use a [supported version](/product-overview/release-policy) of Mattermost in conjunction with the latest version of the Mattermost Operator. -> - `spec.licenseSecret`: The name of the Kubernetes secret containing your license (required for Enterprise). -> -> For a full list of configurable fields, see the [example manifest](https://github.com/mattermost/mattermost-operator/blob/master/docs/examples/mattermost_full.yaml) and the [Custom Resource Definition](https://github.com/mattermost/mattermost-operator/blob/master/config/crd/bases/installation.mattermost.com_mattermosts.yaml). + ``` yaml + apiVersion: installation.mattermost.com/v1beta1 + kind: Mattermost + metadata: + name: + spec: + size: + ingress: + enabled: true + host: + annotations: + kubernetes.io/ingress.class: nginx + version: + licenseSecret: "" + ``` + + Key fields in the manifest include: + + - `metadata.name`: The name of your Mattermost deployment in Kubernetes. + - `spec.size`: The size of your installation (e.g., "100users", "1000users", etc.). + - `spec.ingress.host`: The DNS name for your Mattermost installation. + - `spec.version`: The Mattermost version. See the [server version archive](/product-overview/version-archive) for available versions. You should use a [supported version](/product-overview/release-policy) of Mattermost in conjunction with the latest version of the Mattermost Operator. + - `spec.licenseSecret`: The name of the Kubernetes secret containing your license (required for Enterprise). + + For a full list of configurable fields, see the [example manifest](https://github.com/mattermost/mattermost-operator/blob/master/docs/examples/mattermost_full.yaml) and the [Custom Resource Definition](https://github.com/mattermost/mattermost-operator/blob/master/config/crd/bases/installation.mattermost.com_mattermosts.yaml). 3. Create a file named `mattermost-database-secret.yaml` for database credentials. This secret must be in the same namespace as the Mattermost installation. -> ``` yaml -> apiVersion: v1 -> data: -> DB_CONNECTION_CHECK_URL: -> DB_CONNECTION_STRING: -> MM_SQLSETTINGS_DATASOURCEREPLICAS: -> kind: Secret -> metadata: -> name: my-postgres-connection -> type: Opaque -> ``` -> -> Example for AWS Aurora with PostgreSQL (`DB_CONNECTION_CHECK_URL`, `DB_CONNECTION_STRING`, and `MM_SQLSETTINGS_DATASOURCEREPLICAS` are the base64-encoded form of your Aurora connection URL, e.g. `postgres://user:password@host:5432/mattermost`): -> -> ``` yaml -> apiVersion: v1 -> data: -> DB_CONNECTION_CHECK_URL: cG9zdGdyZXM6Ly91c2Vy... # base64-encoded connection URL -> DB_CONNECTION_STRING: cG9zdGdyZXM6Ly91c2Vy... # base64-encoded connection URL -> MM_SQLSETTINGS_DATASOURCEREPLICAS: cG9zdGdyZXM6... # base64-encoded replica URL -> kind: Secret -> metadata: -> name: my-postgres-connection -> type: Opaque -> ``` + ``` yaml + apiVersion: v1 + data: + DB_CONNECTION_CHECK_URL: + DB_CONNECTION_STRING: + MM_SQLSETTINGS_DATASOURCEREPLICAS: + kind: Secret + metadata: + name: my-postgres-connection + type: Opaque + ``` + + Example for AWS Aurora with PostgreSQL (`DB_CONNECTION_CHECK_URL`, `DB_CONNECTION_STRING`, and `MM_SQLSETTINGS_DATASOURCEREPLICAS` are the base64-encoded form of your Aurora connection URL, e.g. `postgres://user:password@host:5432/mattermost`): + + ``` yaml + apiVersion: v1 + data: + DB_CONNECTION_CHECK_URL: cG9zdGdyZXM6Ly91c2Vy... + DB_CONNECTION_STRING: cG9zdGdyZXM6Ly91c2Vy... + MM_SQLSETTINGS_DATASOURCEREPLICAS: cG9zdGdyZXM6... + kind: Secret + metadata: + name: my-postgres-connection + type: Opaque + ``` @@ -152,7 +152,7 @@ Create a file named `mattermost-filestore-secret.yaml` to store the credentials apiVersion: v1 kind: Secret metadata: - name: # Choose a descriptive name (e.g., my-s3-credentials) + name: type: Opaque data: accesskey: @@ -199,10 +199,12 @@ metadata: name: my-s3-credentials type: Opaque data: - accesskey: QUNDRVNTX0tFWQo= # Example: Replace with your actual encoded key - secretkey: U1VQRVJfU0VDUkVUX0tFWQo= # Example: Replace with your actual encoded key + accesskey: QUNDRVNTX0tFWQo= + secretkey: U1VQRVJfU0VDUkVUX0tFWQo= ``` +Replace both values with your own base64-encoded keys. + ### Step 5: Configure the Mattermost Installation Manifest @@ -210,52 +212,58 @@ data: 1. Modify the `mattermost-installation.yaml` file (created in step 2) to connect Mattermost to your external database and object storage. Refer to the supported fields for guidance on where to add these configurations within the YAML structure. 2. Connect to the database: -> 1. Add the following to the `spec` section of your manifest: -> -> > ``` yaml -> > spec: -> > database: -> > external: -> > secret: <database-secret-name> # The name of the database secret (e.g., my-postgres-connection) -> > ``` -> -> 2. **(Recommended)** Configure the database-readiness init container to use the in-image `mattermost db ping` command instead of the legacy `postgres:13` + `pg_isready` flow. This avoids the need to pull a separate `postgres:13` image (the primary motivation for air-gapped clusters that can't mirror it) and keeps your readiness check in sync with the Mattermost release you're running. -> -> > ``` yaml -> > spec: -> > database: -> > external: -> > secret: -> > readinessCheck: -> > mode: builtin -> > timeout: 5m # optional; default is 5m -> > ``` -> -> Using `builtin` mode requires a Mattermost release that ships the `mattermost db ping` command (see the [Mattermost server pull request](https://github.com/mattermost/mattermost/pull/36406) for availability). -> -> Omitting `readinessCheck` (or setting `mode: external`) preserves the legacy `postgres:13` + `pg_isready` behavior. The legacy mode is the current default for backward compatibility and will be deprecated in a future operator release. See the [Mattermost CRD reference](https://github.com/mattermost/mattermost-operator/blob/master/docs/mattermost_v1beta1_crd.md) for the full `readinessCheck` field schema. + 1. Add the following to the `spec` section of your manifest: + + ``` yaml + spec: + database: + external: + secret: + ``` + + Replace `` with the name of the database secret you created (e.g., `my-postgres-connection`). + + 2. **(Recommended)** Configure the database-readiness init container to use the in-image `mattermost db ping` command instead of the legacy `postgres:13` + `pg_isready` flow. This avoids the need to pull a separate `postgres:13` image (the primary motivation for air-gapped clusters that can't mirror it) and keeps your readiness check in sync with the Mattermost release you're running. + + ``` yaml + spec: + database: + external: + secret: + readinessCheck: + mode: builtin + timeout: 5m + ``` + + `timeout` is optional and defaults to `5m`. + + Using `builtin` mode requires a Mattermost release that ships the `mattermost db ping` command (see the [Mattermost server pull request](https://github.com/mattermost/mattermost/pull/36406) for availability). + + Omitting `readinessCheck` (or setting `mode: external`) preserves the legacy `postgres:13` + `pg_isready` behavior. The legacy mode is the current default for backward compatibility and will be deprecated in a future operator release. See the [Mattermost CRD reference](https://github.com/mattermost/mattermost-operator/blob/master/docs/mattermost_v1beta1_crd.md) for the full `readinessCheck` field schema. 3. Connect to Object Storage: -> 1. Add the following to the `spec` section of your manifest: -> -> > ``` yaml -> > spec: -> > fileStore: -> > external: -> > url: <storage-service-url> # The URL of your storage service (e.g., s3.amazonaws.com) -> > bucket: <bucket-name> # The name of your storage bucket -> > secret: <filestore-secret-name> # The name of the filestore secret (e.g., my-s3-credentials) -> > ``` + 1. Add the following to the `spec` section of your manifest: + + ``` yaml + spec: + fileStore: + external: + url: + bucket: + secret: + ``` + + Replace `` with the URL of your storage service (e.g., `s3.amazonaws.com`), `` with the name of your storage bucket, and `` with the name of the filestore secret you created (e.g., `my-s3-credentials`). 4. If you are using Amazon S3, it's recommended to enable server-side encryption (SSE) and SSL. Add the following environment variables to the `mattermostEnv` section: -> ``` yaml -> spec: -> mattermostEnv: -> MM_FILESETTINGS_AMAZONS3SSL: true -> MM_FILESETTINGS_AMAZONS3SSE: true -> ``` + ``` yaml + spec: + mattermostEnv: + MM_FILESETTINGS_AMAZONS3SSL: true + MM_FILESETTINGS_AMAZONS3SSE: true + ``` ## Review Mattermost Resource Status diff --git a/docs/site/src/components/CardGrid/styles.module.css b/docs/site/src/components/CardGrid/styles.module.css index 87f7c954ec2f..016e0fadc6d0 100644 --- a/docs/site/src/components/CardGrid/styles.module.css +++ b/docs/site/src/components/CardGrid/styles.module.css @@ -86,10 +86,13 @@ } .title { - font-family: var(--mm-font-heading); - font-weight: 900; + /* Mixed-case, multi-word labels (e.g. "For End Users") read as too + * heavy/shouty in Archivo Black at 900 — same issue already fixed for + * h1-h4 — so use the sans face at a lighter bold weight instead. */ + font-family: var(--mm-font-sans); + font-weight: 700; font-size: 1.05rem; - letter-spacing: 0.01em; + letter-spacing: -0.01em; margin-bottom: 0.35rem; color: var(--mm-text-primary); } diff --git a/docs/site/src/components/IMEDiagram/styles.module.css b/docs/site/src/components/IMEDiagram/styles.module.css index feb12e3704bf..2adf6e1cd0eb 100644 --- a/docs/site/src/components/IMEDiagram/styles.module.css +++ b/docs/site/src/components/IMEDiagram/styles.module.css @@ -2,10 +2,9 @@ * * Tighter visual match to the brand infographic: * - Application zone visibly contained in a denim wash + border - * - Intro panels are NOT clickable cards; they're text columns with a - * denim left-edge accent (brand-aligned, signals "category label" — - * marigold is a sparse CTA/interactive accent per the token contract, - * not decoration for static, non-interactive panels) + * - Intro panels are NOT clickable cards; they're plain text columns + * (no left-edge accent bar — the surrounding denim wash/borders already + * signal the section boundary) * - Use Case cells use a soft denim-tinted background, not white-on-white * - All clickable cells share the same white-with-marigold-on-hover treatment * - Section titles get a thin marigold underline for visual rhythm @@ -93,19 +92,12 @@ } /* === Intro panels (Application / Integration / Deployment left column) === - Not clickable. Denim left-edge accent for visual rhythm. */ + Not clickable — plain text columns, no left-edge accent bar. */ .appIntro, .intIntro, .depIntro { - padding: 0.25rem 0.6rem 0.25rem 0.7rem; - border-left: 3px solid var(--mm-color-denim, #1E325C); -} - -[data-theme='dark'] .appIntro, -[data-theme='dark'] .intIntro, -[data-theme='dark'] .depIntro { - border-left-color: var(--mm-denim-300, #8499C5); + padding: 0.25rem 0.6rem 0.25rem 0; } .appIntro h3, diff --git a/docs/site/src/css/custom.css b/docs/site/src/css/custom.css index 2a5930f94bec..5bb89ca7019f 100644 --- a/docs/site/src/css/custom.css +++ b/docs/site/src/css/custom.css @@ -599,6 +599,19 @@ blockquote { padding-right: clamp(1rem, 2vw, 2rem); } +/* theme-classic's DocItem/Layout only caps the article column at 75% via + * its own `docItemCol` class when a TOC renders alongside it — pages with + * `hide_table_of_contents: true` (e.g. the homepage) get a lone full-width + * `.col` instead, so prose reads much wider than on every other doc page. + * Recreate the same 75% cap here, keyed off the `
` that's always + * a descendant of the doc content column, regardless of TOC presence. */ +@media (min-width: 997px) { + .docMainContainer_TBSr .col:has(> div > article), + [class*='docMainContainer'] .col:has(> div > article) { + max-width: 75%; + } +} + /* Without max-width, the doc content flex column no longer has an upper * bound to shrink against, so a wide code block (long lines, e.g. inline * YAML comments) inflates its own intrinsic min-content size and drags the diff --git a/docs/site/static/img/ui/restore_F099B.svg b/docs/site/static/img/ui/restore_F099B.svg index c039fd4dd9de..514c24527801 100644 --- a/docs/site/static/img/ui/restore_F099B.svg +++ b/docs/site/static/img/ui/restore_F099B.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file