feat: remove copyable strings from md files (#31)

Oreoxmt · Dec 5, 2023 · b8d4658 · b8d4658
1 parent 39e174d
commit b8d4658
Show file tree

Hide file tree

Showing 17 changed files with 14 additions and 238 deletions.
diff --git a/sync_pr.sh b/sync_pr.sh
@@ -87,6 +87,13 @@ generate_sync_tasks() {
   esac
 }
 
+remove_copyable() {
+  # Remove copyable strings ({{< copyable "..." >}}\n) from Markdown files.
+  $FIND . -name '*.md' | while IFS= read -r FILE; do
+    $SED -i '/{{< copyable ".*" >}}/{N;d}' "$FILE"
+  done
+}
+
 clone_repo() {
 
   # Clone repo if it doesn't exist already.
@@ -115,6 +122,9 @@ perform_sync_task() {
     git -C "$SRC_DIR" diff --merge-base --name-only --diff-filter=AMR origin/"$BASE_BRANCH" --relative | tee /dev/fd/2 |
       rsync -av --files-from=- "$SRC_DIR" "$DEST_DIR"
 
+    # Remove copyable strings.
+    (cd "$DEST_DIR" && remove_copyable)
+
     if [[ "$IS_CLOUD" && -f "$DEST_DIR/TOC-tidb-cloud.md" ]]; then
       process_cloud_toc "$DEST_DIR"
     fi
@@ -132,6 +142,10 @@ commit_changes() {
   git commit -m "$COMMIT_MESS" || echo "No changes to commit"
 }
 
+# Select appropriate versions of find and sed depending on the operating system.
+FIND=$(which gfind || which find)
+SED=$(which gsed || which sed)
+
 # Get the directory of this script.
 SCRIPT_DIR=$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" &>/dev/null && pwd)
 cd "$SCRIPT_DIR"

diff --git a/...kdown-pages/en/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md b/...kdown-pages/en/tidb-in-kubernetes/master/grant-permissions-to-remote-storage.md
@@ -17,8 +17,6 @@ The AWS client can read `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` from the
 
 Create the `s3-secret` secret by running the following command. Use the AWS account's AccessKey and SecretKey. The secret stores the credential used for accessing S3-compatible storage.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1
 ```
@@ -70,8 +68,6 @@ If you associate the user's [IAM](https://aws.amazon.com/cn/iam/) role with the
 
     When you use BR to back up TiDB data, the TiKV Pod also needs to perform read and write operations on S3-compatible storage as the BR Pod does. Therefore, you need to add annotations to the TiKV Pod to associate it with the IAM role.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"annotations":{"iam.amazonaws.com/role":"arn:aws:iam::123456789012:role/user"}}}}'
     ```
@@ -126,8 +122,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 3. Associate the IAM role with the `ServiceAccount` resources.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl annotate sa tidb-backup-manager eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/user --namespace=test1
     ```
@@ -142,8 +136,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 4. Associate the `ServiceAccount` with the TiKV Pod:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"serviceAccount": "tidb-backup-manager"}}}'
     ```
@@ -160,8 +152,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 Create the `gcs-secret` secret which stores the credential used to access GCS. The `google-credentials.json` file stores the service account key that you have downloaded from the Google Cloud console. Refer to [Google Cloud documentation](https://cloud.google.com/docs/authentication/getting-started) for details.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1
 ```
@@ -176,8 +166,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT` and `AZURE_STORAGE_KEY` from t
 
 Run the following command to create the `azblob-secret` secret and use your Azure account access key to grant permissions. The secret stores the credential used for accessing Azure Blob Storage.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic azblob-secret --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_STORAGE_KEY=yyy --namespace=test1
 ```
@@ -188,8 +176,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT`, `AZURE_CLIENT_ID`, `AZURE_TEN
 
 1. Create the `azblob-secret-ad` secret by running the following command. Use the Active Directory (AD) of your Azure account. The secret stores the credential used for accessing Azure Blob Storage.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl create secret generic azblob-secret-ad --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_CLIENT_ID=yyy --from-literal=AZURE_TENANT_ID=zzz --from-literal=AZURE_CLIENT_SECRET=aaa --namespace=test1
     ```
@@ -198,8 +184,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT`, `AZURE_CLIENT_ID`, `AZURE_TEN
 
     When you use BR to back up TiDB data, the TiKV Pod also needs to perform read and write operations on Azure Blob Storage as the BR Pod does. Therefore, you need to associate the TiKV Pod with the secret.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"envFrom":[{"secretRef":{"name":"azblob-secret-ad"}}]}}}'
     ```

diff --git a/...-pages/en/tidb-in-kubernetes/release-6.7/grant-permissions-to-remote-storage.md b/...-pages/en/tidb-in-kubernetes/release-6.7/grant-permissions-to-remote-storage.md
@@ -17,8 +17,6 @@ The AWS client can read `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` from the
 
 Create the `s3-secret` secret by running the following command. Use the AWS account's AccessKey and SecretKey. The secret stores the credential used for accessing S3-compatible storage.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1
 ```
@@ -70,8 +68,6 @@ If you associate the user's [IAM](https://aws.amazon.com/cn/iam/) role with the
 
     When you use BR to back up TiDB data, the TiKV Pod also needs to perform read and write operations on S3-compatible storage as the BR Pod does. Therefore, you need to add annotations to the TiKV Pod to associate it with the IAM role.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"annotations":{"iam.amazonaws.com/role":"arn:aws:iam::123456789012:role/user"}}}}'
     ```
@@ -126,8 +122,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 3. Associate the IAM role with the `ServiceAccount` resources.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl annotate sa tidb-backup-manager eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/user --namespace=test1
     ```
@@ -142,8 +136,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 4. Associate the `ServiceAccount` with the TiKV Pod:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"serviceAccount": "tidb-backup-manager"}}}'
     ```
@@ -160,8 +152,6 @@ When you use this method to grant permissions, you can [create the EKS cluster](
 
 Create the `gcs-secret` secret which stores the credential used to access GCS. The `google-credentials.json` file stores the service account key that you have downloaded from the Google Cloud console. Refer to [Google Cloud documentation](https://cloud.google.com/docs/authentication/getting-started) for details.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1
 ```
@@ -176,8 +166,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT` and `AZURE_STORAGE_KEY` from t
 
 Run the following command to create the `azblob-secret` secret and use your Azure account access key to grant permissions. The secret stores the credential used for accessing Azure Blob Storage.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 kubectl create secret generic azblob-secret --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_STORAGE_KEY=yyy --namespace=test1
 ```
@@ -188,8 +176,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT`, `AZURE_CLIENT_ID`, `AZURE_TEN
 
 1. Create the `azblob-secret-ad` secret by running the following command. Use the Active Directory (AD) of your Azure account. The secret stores the credential used for accessing Azure Blob Storage.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl create secret generic azblob-secret-ad --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_CLIENT_ID=yyy --from-literal=AZURE_TENANT_ID=zzz --from-literal=AZURE_CLIENT_SECRET=aaa --namespace=test1
     ```
@@ -198,8 +184,6 @@ The Azure client can read `AZURE_STORAGE_ACCOUNT`, `AZURE_CLIENT_ID`, `AZURE_TEN
 
     When you use BR to back up TiDB data, the TiKV Pod also needs to perform read and write operations on Azure Blob Storage as the BR Pod does. Therefore, you need to associate the TiKV Pod with the secret.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"envFrom":[{"secretRef":{"name":"azblob-secret-ad"}}]}}}'
     ```

diff --git a/test/sync_mult_prs/data/markdown-pages/en/tidb/master/upgrade-tidb-using-tiup.md b/test/sync_mult_prs/data/markdown-pages/en/tidb/master/upgrade-tidb-using-tiup.md
@@ -59,17 +59,13 @@ Before upgrading your TiDB cluster, you first need to upgrade TiUP or TiUP mirro
 
 1. Upgrade the TiUP version. It is recommended that the TiUP version is `1.11.3` or later.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup update --self
     tiup --version
     ```
 
 2. Upgrade the TiUP Cluster version. It is recommended that the TiUP Cluster version is `1.11.3` or later.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup update cluster
     tiup cluster --version
@@ -83,8 +79,6 @@ Before upgrading your TiDB cluster, you first need to upgrade TiUP or TiUP mirro
 
 Refer to [Deploy a TiDB Cluster Using TiUP - Deploy TiUP offline](/production-deployment-using-tiup.md#deploy-tiup-offline) to download the TiUP mirror of the new version and upload it to the control machine. After executing `local_install.sh`, TiUP will complete the overwrite upgrade.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tar xzvf tidb-community-server-${version}-linux-amd64.tar.gz
 sh tidb-community-server-${version}-linux-amd64/local_install.sh
@@ -93,8 +87,6 @@ source /home/tidb/.bash_profile
 
 After the overwrite upgrade, run the following command to merge the server and toolkit offline mirrors to the server directory:
 
-{{< copyable "shell-regular" >}}
-
 ```bash
 tar xf tidb-community-toolkit-${version}-linux-amd64.tar.gz
 ls -ld tidb-community-server-${version}-linux-amd64 tidb-community-toolkit-${version}-linux-amd64
@@ -105,8 +97,6 @@ tiup mirror merge ../tidb-community-toolkit-${version}-linux-amd64
 
 After merging the mirrors, run the following command to upgrade the TiUP Cluster component:
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup update cluster
 ```
@@ -124,8 +114,6 @@ Now, the offline mirror has been upgraded successfully. If an error occurs durin
 
 1. Enter the `vi` editing mode to edit the topology file:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster edit-config <cluster-name>
     ```
@@ -142,8 +130,6 @@ Now, the offline mirror has been upgraded successfully. If an error occurs durin
 
 To avoid the undefined behaviors or other issues during the upgrade, it is recommended to check the health status of Regions of the current cluster before the upgrade. To do that, you can use the `check` sub-command.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster check <cluster-name> --cluster
 ```
@@ -174,16 +160,12 @@ If your application has a maintenance window for the database to be stopped for
 
 #### Online upgrade
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster upgrade <cluster-name> <version>
 ```
 
 For example, if you want to upgrade the cluster to v7.1.0:
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster upgrade <cluster-name> v7.1.0
 ```
@@ -207,24 +189,18 @@ tiup cluster upgrade <cluster-name> v7.1.0
 
 1. Before the offline upgrade, you first need to stop the entire cluster.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster stop <cluster-name>
     ```
 
 2. Use the `upgrade` command with the `--offline` option to perform the offline upgrade. Fill in the name of your cluster for `<cluster-name>` and the version to upgrade to for `<version>`, such as `v7.1.0`.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster upgrade <cluster-name> <version> --offline
     ```
 
 3. After the upgrade, the cluster will not be automatically restarted. You need to use the `start` command to restart it.
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster start <cluster-name>
     ```
@@ -233,8 +209,6 @@ tiup cluster upgrade <cluster-name> v7.1.0
 
 Execute the `display` command to view the latest cluster version `TiDB Version`:
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster display <cluster-name>
 ```
@@ -255,8 +229,6 @@ Re-execute the `tiup cluster upgrade` command to resume the upgrade. The upgrade
 
 1. Execute `tiup cluster audit` to see the operation records:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster audit
     ```
@@ -265,8 +237,6 @@ Re-execute the `tiup cluster upgrade` command to resume the upgrade. The upgrade
 
 2. Execute `tiup cluster replay <audit-id>` to retry the corresponding operation:
 
-    {{< copyable "shell-regular" >}}
-
     ```shell
     tiup cluster replay <audit-id>
     ```
@@ -275,8 +245,6 @@ Re-execute the `tiup cluster upgrade` command to resume the upgrade. The upgrade
 
 You can specify `--force`. Then the processes of transferring PD leader and evicting TiKV leader are skipped during the upgrade. The cluster is directly restarted to update the version, which has a great impact on the cluster that runs online. In the following command, `<version>` is the version to upgrade to, such as `v7.1.0`.
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup cluster upgrade <cluster-name> <version> --force
 ```
@@ -285,8 +253,6 @@ tiup cluster upgrade <cluster-name> <version> --force
 
 You can upgrade the tool version by using TiUP to install the `ctl` component of the corresponding version:
 
-{{< copyable "shell-regular" >}}
-
 ```shell
 tiup install ctl:v7.1.0
 ```