目前，作为PR合并的一部分，我正在尝试使用GitHub操作自动化应用程序的bump版本。有一个自定义脚本，可以识别应用程序的当前版本和PR附带的标签，并在存储版本号的文件上相应地更改主要|次要|补丁版本。重要的是，版本冲突仅在PR合并时发生，并且是GitHub操作的一部分，因为这有助于避免版本文件中的合并冲突，并消除了手动冲突版本的方式。
下面给出了GitHub Actions的代码片段。
jobs:
release:
# Skip on Pull Request Close event.
if: "!(github.event_name == 'pull_request' && !github.event.pull_request.merged)"
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
ref: ${{ github.ref }}
- id: bumpversion
if: github.event.pull_request.merged
env:
PR_LABELS: ${{ toJson(github.event.pull_request.labels) }}
run: bash .github/scripts/bump_version.sh -l "${PR_LABELS}"
bump_version.sh脚本有一个下面给出的函数，用于更改版本，然后将其推送到main分支。
git config user.email "${GITHUB_ACTOR}@users.noreply.github.com"
echo "commiting the version bump changes..."
git add .
git commit -m "Bump Version v${current_version} -> v${incremented_version}"
echo "pushing the version bump changes..."
git push origin dev
这运行得很好，但问题是，当PR合并到main分支时，它会在该分支上进行2次提交。有一个CI/CD管道会侦听此main分支以获取更改，当有新的提交时会触发它。由于此PR合并进行了2次提交，因此会触发两次。
单个PR合并图像的2次提交
问题：是否可以在不创建第二次提交的情况下通过GitHub操作作为合并的一部分更新文件？有没有其他方法可以解决这个问题，帮助我将版本作为PR合并的一部分？
我的即时想法是，您可以更改CI/CD中的触发器("on:"(以忽略两个提交中的第一个，而只在第二个提交上运行CI/CD。
有很多方法可以做到这一点，利用提交时附带的任何元数据。这里有一个利用标签的想法。您可能需要重构定义incremented_version的代码，但在bash中应该不难做到。
这是一个CI/CD，它会忽略标记为*.0.0的东西，但会触发*.1或*.0.1:之类的东西
on:
push:
# Sequence of patterns matched against refs/tags
tags:
- !v*.0.0
- !v*.0 # Do not push events to tags v1.0.0, v1.0, v2.0.0, and v2.0, etc.
就我个人而言，我喜欢让两个提交中的第一个有一个额外的.0并忽略这些。它看起来更干净。在配置bash脚本以完成此操作之后，：
on:
push:
# Sequence of patterns matched against refs/tags
tags:
- !v*.0.0 # Do not push events to tags v1.0.0, v2.0.0, etc.
当我在寻找更好的解决方案时，一个选项是修改提交并强制推回main。我推荐force-with-lease，如果力推不干净，它会填充失败。这将需要创建一个具有适当权限的GITHUB PAT。
git config user.email "${GITHUB_ACTOR}@users.noreply.github.com"
echo "commiting the version bump changes..."
git add .
git commit -m "Bump Version v${current_version} -> v${incremented_version}" --amend
echo "pushing the version bump changes..."
git push origin dev --force-with-lease