We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
新功能
在创建新的更新请求时关闭过时的更新请求。
有些时候我们会在短时间内进行多次推送(例如在测试网页时),而 GitHub Action 会在每次推送都使用 Sitemap Creator 生成更新请求,最终导致出现一堆拉取请求。 解决时需要维护者合并最新的更新请求,然后手动关闭过时的拉取请求(不出意外的话这几个拉取请求会出现合并冲突,想自己写自动化的话可以考虑下)。
通过标签来判断 当 Sitemap Creator 创建新的更新请求 前 ,先检查带是否有带有指定 label 的 PR。如有,关闭他们。 问题:维护者可能会将指定的 label 用于其他类型的 PR,(例如我自己会设置 label 为 工作流,同时其他工作流也会使用这个 label)进而导致把其他工作流的 PR 给关闭了。
label
工作流
通过标题来判断 当 Sitemap Creator 创建新的更新请求 前 ,先检查带是否有带有指定 title 的 PR。如有,关闭他们。 (目前的 PR title 是 [$(date '+%Y/%m/%d %H:%M')] 自动更新网站地图,可以匹配自动更新网站地图字样) 问题: i. 维护者可能会修改相关 PR 的标题导致找不到那些 PR ii. 后续可能会添加 PR/Commit 标题自定义功能,匹配更不固定
title
[$(date '+%Y/%m/%d %H:%M')] 自动更新网站地图
自动更新网站地图
通过修改的文件来判断 当 Sitemap Creator 创建新的更新请求 前 ,先检查是否有 仅 修改网站地图文件的 PR。如有,关闭他们。 问题:这可能会关闭掉一些不是 Sitemap Creator 创建的 PR
我认为目前: 最佳的匹配方式是通过 修改的文件 来判断,这可以避免一些不定参数。 最稳定的匹配方式是 三者皆匹配中,这可以最大限度的避免误关 PR。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
选择一个类别
新功能
对新功能/建议的描述
在创建新的更新请求时关闭过时的更新请求。
为什么需要实现此功能
有些时候我们会在短时间内进行多次推送(例如在测试网页时),而 GitHub Action 会在每次推送都使用 Sitemap Creator 生成更新请求,最终导致出现一堆拉取请求。
解决时需要维护者合并最新的更新请求,然后手动关闭过时的拉取请求(不出意外的话这几个拉取请求会出现合并冲突,想自己写自动化的话可以考虑下)。
对于实施该功能的方法的建议
通过标签来判断
当 Sitemap Creator 创建新的更新请求 前 ,先检查带是否有带有指定
label
的 PR。如有,关闭他们。问题:维护者可能会将指定的
label
用于其他类型的 PR,(例如我自己会设置label
为工作流
,同时其他工作流也会使用这个label
)进而导致把其他工作流的 PR 给关闭了。通过标题来判断
当 Sitemap Creator 创建新的更新请求 前 ,先检查带是否有带有指定
title
的 PR。如有,关闭他们。(目前的 PR title 是
[$(date '+%Y/%m/%d %H:%M')] 自动更新网站地图
,可以匹配自动更新网站地图
字样)问题:
i. 维护者可能会修改相关 PR 的标题导致找不到那些 PR
ii. 后续可能会添加 PR/Commit 标题自定义功能,匹配更不固定
通过修改的文件来判断
当 Sitemap Creator 创建新的更新请求 前 ,先检查是否有 仅 修改网站地图文件的 PR。如有,关闭他们。
问题:这可能会关闭掉一些不是 Sitemap Creator 创建的 PR
我认为目前:
最佳的匹配方式是通过 修改的文件 来判断,这可以避免一些不定参数。
最稳定的匹配方式是 三者皆匹配中,这可以最大限度的避免误关 PR。
The text was updated successfully, but these errors were encountered: