mirror of
https://github.com/hanzoai/team.git
synced 2026-09-30 01:57:35 +00:00
Fix docs site homepage width, unreadable bold text, and deploy-k8s / icon UI bugs (#37681)
* Fix homepage width, card-title weight, and deploy-k8s code block clutter
The homepage's hide_table_of_contents:true dropped the usual 75% width
cap DocItem/Layout applies via docItemCol, so prose read much wider
than every other doc page. Restore the cap unconditionally.
CardGrid's card titles ("For End Users", etc.) used Archivo Black at
900 weight, the same too-heavy/shouty treatment already fixed for
h1-h4 — switch to the sans face at 700 to match.
On the Kubernetes Operator deploy page, strip inline "# comment"
annotations out of the YAML/shell snippets (moving anything useful
into surrounding prose), and replace nested blockquotes used purely
for list indentation with plain nested lists, since the blockquotes
were triggering the site's yellow-bordered blockquote styling at
every nesting level for no reason.
* Fix oversized Restore icon on the Send messages doc page
restore_F099B.svg was the only icon under docs/site/static/img/ui
missing explicit width/height attributes (every sibling icon sets
width="24" height="24"). Without them, the browser falls back to its
default SVG replaced-element size instead of the 24x24 the inline
.theme-icon usage expects, rendering it many times larger than the
surrounding text.
---------
Co-authored-by: Hanzo Dev <[email protected]>
This commit is contained in:
committed by
GitHub
co-authored by
Hanzo Dev
parent
c5340635e7
commit
0100726431
@@ -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 <namespace_name>
|
||||
> ```
|
||||
>
|
||||
> 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 <your-release-name> mattermost/mattermost-operator -n <namespace_name>
|
||||
```
|
||||
|
||||
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: <LICENSE_FILE_CONTENTS>
|
||||
> ```
|
||||
``` yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: my-mattermost-license
|
||||
type: Opaque
|
||||
stringData:
|
||||
license: <LICENSE_FILE_CONTENTS>
|
||||
```
|
||||
|
||||
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: <INSTALLATION_NAME_HERE> # Example: mm-example-full
|
||||
> spec:
|
||||
> size: <SIZE_VALUE_HERE> # Example: 5000users
|
||||
> ingress:
|
||||
> enabled: true
|
||||
> host: <FULL_DOMAIN_NAME_HERE> # Example: example.mattermost-example.com
|
||||
> annotations:
|
||||
> kubernetes.io/ingress.class: nginx
|
||||
> version: <VERSION_HERE> # 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: <INSTALLATION_NAME_HERE>
|
||||
spec:
|
||||
size: <SIZE_VALUE_HERE>
|
||||
ingress:
|
||||
enabled: true
|
||||
host: <FULL_DOMAIN_NAME_HERE>
|
||||
annotations:
|
||||
kubernetes.io/ingress.class: nginx
|
||||
version: <VERSION_HERE>
|
||||
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_CHECK_URL>
|
||||
> DB_CONNECTION_STRING: <DB_CONNECTION_STRING>
|
||||
> MM_SQLSETTINGS_DATASOURCEREPLICAS: <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_CHECK_URL>
|
||||
DB_CONNECTION_STRING: <DB_CONNECTION_STRING>
|
||||
MM_SQLSETTINGS_DATASOURCEREPLICAS: <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
|
||||
```
|
||||
|
||||
<Note>
|
||||
|
||||
@@ -152,7 +152,7 @@ Create a file named `mattermost-filestore-secret.yaml` to store the credentials
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: <secret-name> # Choose a descriptive name (e.g., my-s3-credentials)
|
||||
name: <secret-name>
|
||||
type: Opaque
|
||||
data:
|
||||
accesskey: <base64-encoded-access-key>
|
||||
@@ -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.
|
||||
|
||||
</Important>
|
||||
|
||||
### 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: <database-secret-name>
|
||||
> > 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: <database-secret-name>
|
||||
```
|
||||
|
||||
Replace `<database-secret-name>` 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: <database-secret-name>
|
||||
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: <storage-service-url>
|
||||
bucket: <bucket-name>
|
||||
secret: <filestore-secret-name>
|
||||
```
|
||||
|
||||
Replace `<storage-service-url>` with the URL of your storage service (e.g., `s3.amazonaws.com`), `<bucket-name>` with the name of your storage bucket, and `<filestore-secret-name>` 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
|
||||
|
||||
|
||||
@@ -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);
|
||||
}
|
||||
|
||||
@@ -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 `<article>` 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
|
||||
|
||||
@@ -1 +1 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13,3A9,9 0 0,0 4,12H1L4.89,15.89L4.96,16.03L9,12H6A7,7 0 0,1 13,5A7,7 0 0,1 20,12A7,7 0 0,1 13,19C11.07,19 9.32,18.21 8.06,16.94L6.64,18.36C8.27,20 10.5,21 13,21A9,9 0 0,0 22,12A9,9 0 0,0 13,3Z" /></svg>
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24"><path d="M13,3A9,9 0 0,0 4,12H1L4.89,15.89L4.96,16.03L9,12H6A7,7 0 0,1 13,5A7,7 0 0,1 20,12A7,7 0 0,1 13,19C11.07,19 9.32,18.21 8.06,16.94L6.64,18.36C8.27,20 10.5,21 13,21A9,9 0 0,0 22,12A9,9 0 0,0 13,3Z" /></svg>
|
||||
|
Before Width: | Height: | Size: 273 B After Width: | Height: | Size: 296 B |
Reference in New Issue
Block a user