JiaHe - 家和的学习分享

回顾了人类认识维生素C的历程，从最初水手们碰到的“海上凶神”到重挫英国海军的坏血病，人类的认识也在一点一点地进步。直到近代有了先进理论的指导，伴随着化学研究飞速发展，人类终于认识了维生素C，战胜了坏血病。这标志着一个新时代的到来。

维生素是一类小分子有机物，它们虽然不提供生命活动所需的能量，却是身体代谢过程中必需的物质。经过上百年的研究，人们已了解了15种维生素的结构，维生素C就是其中很重要的一种。它可治疗牙龈出血、灼伤；能加速手术后的恢复；增强治疗尿路感染药物的疗效……但是维生素C最为著名的用途是治疗“坏血病”。人们认识维生素C也是从防治“坏血病”开始的，这是一段漫长而充满血腥的历史。

使用命令：bash main.sh ./config.sh <Class文件路径>

#!/bin/bash

REMOTE_USER="admin"                 # 服务器用户名
REMOTE_HOST="*.*.*.*"               # 服务器地址
REMOTE_DIR="/tmp"                   # 服务器上传目录，建议使用临时目录
REMOTE_PASSWORD="***"               # 服务器登录密码
REMOTE_PORT=22                      # 服务器端口
REMOTE_ARTHAS_DIR="{arthas-dir}"    # arthas目录
PROJECT_NAME="{jar-keyword}"        # 服务器上的jar包名，模糊匹配

#!/bin/bash

# 检查输入参数
if [[ $# -lt 1 ]]; then
    echo "Usage: $0 <config-file> [CLASS_SRC]"
    exit 1
fi

CONFIG_FILE=$1
CLASS_SRC=$2

# 检查配置文件是否存在
if [[ ! -f $CONFIG_FILE ]]; then
    echo "Configuration file $CONFIG_FILE does not exist!"
    exit 1
fi

# 加载配置文件
source "$CONFIG_FILE"

# 如果 CLASS_SRC 为空，使用配置文件中定义的 CLASS_SRC 默认值
if [[ -z $CLASS_SRC ]]; then
    CLASS_SRC="$CLASS_SRC_DEFAULT"
fi

# 校验 CLASS_SRC 是否存在
if [[ ! -f $CLASS_SRC ]]; then
    echo "Error: CLASS_SRC file does not exist: $CLASS_SRC"
    exit 1
fi

# 加载公共逻辑脚本
source "$(dirname "$0")/common.sh"

# 解析 Class 名称
CLASS_NAME=$(basename "$CLASS_SRC")
echo "Using CLASS_NAME: $CLASS_NAME"

# 执行上传
echo "Uploading $CLASS_NAME to server $REMOTE_HOST..."
sshpass -p "$REMOTE_PASSWORD" scp -P "$REMOTE_PORT" "$CLASS_SRC" "$REMOTE_USER@$REMOTE_HOST:$REMOTE_DIR/"
echo "Upload success..."

# 执行热更新
echo "Running hot update on server $REMOTE_HOST..."
sshpass -p "$REMOTE_PASSWORD" ssh -p "$REMOTE_PORT" "$REMOTE_USER@$REMOTE_HOST" << EOF
    PID=\$(jps | grep "$PROJECT_NAME" | awk '{print \$1}')
    
    if [ -n "\$PID" ]; then
        echo "Found $PROJECT_NAME process ID: \$PID"
        java -jar $REMOTE_ARTHAS_DIR/arthas-boot.jar \$PID << END
          retransform $REMOTE_DIR/$CLASS_NAME
          exit
END
          echo "Completed hot update for $CLASS_NAME"
    else
        echo "No matching $PROJECT_NAME process found on $REMOTE_HOST."
    fi
EOF

参考：https://github.com/ysysycyc/auto-retransform

¶介绍

有时，您可能需要从 Git 历史记录中永久删除文件。这可能是因为意外提交了敏感信息，或者只是为了减少仓库大小。本指南介绍了两种常用的方法：使用 BFG Repo-Cleaner 和 git-filter-repo。这两种方法都会重写 Git 历史记录，因此，遵循安全预防措施以避免数据丢失是至关重要的。

¶安全注意事项

1. 备份您的仓库：在进行任何历史重写之前，请创建仓库的备份。您可以将仓库克隆到单独的位置：

   git clone --mirror https://github.com/your-user/your-repo.git your-repo-backup

2. 与您的团队沟通：通知您的团队有关历史重写的情况，因为这将要求所有人重新克隆仓库。

3. 在单独的分支上测试：在单独的分支上执行历史重写，以确保一切正常，然后再将更改推送到主分支。

¶使用 BFG Repo-Cleaner

BFG Repo-Cleaner 是一种删除大型文件或敏感数据的简单快捷的替代方法，比 git-filter-branch 更快更简单。

¶安装

1. 从 这里 下载最新版本的 BFG Repo-Cleaner。
2. 使用 Java 运行 BFG：

   java -jar bfg-1.14.0.jar

¶使用 BFG 删除文件

1. 克隆您的仓库：

   git clone --mirror https://github.com/your-user/your-repo.git cd your-repo.git

2. 运行 BFG 删除文件：

   java -jar bfg-1.14.0.jar --delete-files your-file.txt

3. 清理和重新打包：

   git reflog expire --expire=now --all && git gc --prune=now --aggressive

4. 推送更改：

   git push --force

¶使用 git-filter-repo

git-filter-repo 是一个功能强大的工具，用于重写 Git 历史记录，提供比 BFG Repo-Cleaner 更大的灵活性。

¶安装

1. 通过 pip 安装：

   pip install git-filter-repo

¶使用 git-filter-repo 删除文件

1. 克隆您的仓库：

   git clone https://github.com/your-user/your-repo.git cd your-repo

2. 运行 git-filter-repo：

   git filter-repo --path your-file.txt --invert-paths

3. 清理和重新打包：

   git reflog expire --expire=now --all && git gc --prune=now --aggressive

4. 推送更改：

   git push --force

¶结论

通过遵循本指南中描述的步骤，您可以使用 BFG Repo-Cleaner 或 git-filter-repo 安全有效地从 Git 历史记录中删除文件。请记住，在重写历史记录之前备份您的仓库，并与您的团队沟通。

如何使用 GitHub 操作调试并解决此 corepack 问题。

如果你的构建突然出现 cannot find matching keyid: {"signatures":[...],"keys":[...]} 这样的失败信息，通常意味着 npm 注册表键值已被轮换，而你的旧 Corepack 无法验证 pnpm 的新版本（如 9.15.4 或 10.1.0+）。

这种情况可能发生在 GitHub Actions、GitLab、Docker 或其他使用 Corepack 管理软件包管理器的地方。

¶快速调试步骤

1. 检查 Node.js 版本： node -v （如果您看到 v16.x ，则您使用的是 Node 16；如果您看到 v18.x 或更高版本，则您使用的是 Node 18+）。
2. 检查 Corepack 版本： corepack --version. 任何早于 0.31.0 的版本都可能没有新的密钥集。
3. 查找条件逻辑。有些工作流程只在 Node 16 上更新 Corepack。如果您在 Node 18+ 上构建，该逻辑可能会完全跳过更新。

¶如何修复

¶如果您使用的是 18+ 节点（或更新版本）

升级到最新的 Corepack (≥ 0.31.0 )：

steps:
  - name: Use Latest Corepack
    run: |
      echo "Before: corepack version => $(corepack --version || echo 'not installed')"
      npm install -g corepack@latest
      echo "After : corepack version => $(corepack --version)"
      corepack enable
      pnpm --version

这将确保你拥有与 npm 注册表变更相匹配的新签名密钥。

¶如果您使用的是节点 16（无法放弃节点 16 支持）

使用 Corepack 0.20 ，这是仍支持 Node 16 的最后一个版本，其中包含最新 pnpm 版本的更新密钥：

steps:
  - name: Pin Corepack 0.20
    run: |
      echo "Before: corepack => $(corepack --version || echo 'not installed')"
      npm install -g corepack@0.20
      echo "After : corepack => $(corepack --version)"
      corepack enable
      pnpm --version

在 0.20 之后，较新的 Corepack 版本将不再支持 Node 16，因此，如果你还不能放弃 Node 16，这是一个安全的 “权宜之计”。

¶避免禁用签名检查

虽然设置 COREPACK_INTEGRITY_KEYS=0 （跳过签名检查）可以绕过错误，但也绕过了重要的安全性。只有在完全了解风险的情况下，才能使用这种方法。

¶摘要

1. 检查您的 Node 和 Corepack 版本。
2. 如果您使用的是 Node 18 以上版本，请升级到 Corepack ≥ 0.31.0 （如果您需要 Node 16，请升级到 0.20 ）。
3. 删除任何阻止 Corepack 升级在实际环境中运行的条件逻辑。
4. 完成！ 您的 CI 构建应该会成功，您也会保持安全。

更多详情，请参阅 Corepack Issue #612 和 Corepack Releases.