问题描述
在使用Github Actions时遇到了问题。他的项目是一个monorepo，包含了三个NodeJS应用的组件：/core、/worker和/frontend。每个应用都有自己的目录和Dockerfile。此外，项目中还有一个/deployments目录，其中包含了所有将通过ArgoCD应用的Kustomize manifests。
用户的问题出现在Github Actions的工作流程中，尤其是在最后一步。问题出在他在Kustomize目录中替换Kubernetes manifests中的镜像标签，然后将更改后的文件推送到另一个分支或仓库。然而，如果在未来的构建中再次执行替换操作，之前推送的manifests将被其他空的、未替换的manifests覆盖。
用户希望知道如何避免这个问题，以及如何保留所有manifests中的过去更改。
解决方案
在解决这个问题之前，建议备份你的代码和配置文件，以防止意外更改。以下是解决方案的步骤。
使用不同的替换标记
当前的替换方法在后续构建中可能会导致覆盖问题。为了避免这个问题，你可以尝试使用不同的替换标记，以确保在不同的构建中替换不同的内容。
例如，你可以将sed命令中的”IMAGE_TAG”和”DEPLOY_TIMESTAMP”替换为其他字符串，以便在每次构建中替换不同的标记。这将确保之前推送的manifests不会被覆盖。
以下是修改后的步骤示例：
- name: Setting Image Tags/Annotations
run: |
for yaml in $(find deployment/kustomize/base -type f -name "core-*.yaml" -print); do
sed -i "s/NEW_IMAGE_TAG/$COMMIT_SHA/g" $yaml;
sed -i "s/NEW_DEPLOY_TIMESTAMP/$TIMESTAMP/g" $yaml;
done
- name: Committing to Staging Branch
run: |
export COMMIT_MESSAGE=$(git log --format=%B -n 1 | sed '2d')
git config --global user.name "CI"
git config --global user.email "ci@github.com"
git checkout -b staging
git add .
git commit -m "$COMMIT_MESSAGE"
git push -u -f origin dummy
使用版本控制来管理变更
另一个方法是使用版本控制系统来管理manifests的变更。每次替换镜像标签后，不直接提交到分支，而是创建一个新的提交并将其保存在版本控制系统中。这样，你可以轻松地查看每个构建的变更，并在需要的时候将特定的变更应用到特定的环境中。
使用Git分支来管理变更
你可以为每个构建创建一个新的Git分支，将替换后的manifests提交到这些分支中。这样，你可以保留每个构建的状态，避免覆盖问题，并可以根据需要将特定的变更合并到主分支中。
自动化脚本或工具
如果你经常需要在不同构建中替换manifests中的内容，考虑编写一个自动化脚本或使用适合的工具来管理这个过程。这可以帮助你更容易地执行替换操作，并确保在不同的构建中保持一致的配置。
无论哪种方法，都建议在进行更改之前进行充分的测试，并在执行之前确保备份重要的文件和配置。这将帮助你避免意外的问题，并保持项目的稳定性和可靠性。
请记住，不同的解决方案可能适用于不同的情况，根据你的项目需求和团队的工作流程，选择最适合的方法来解决问题。