Mic*_*den 9 semantic-release github-actions github-fine-grained-tokens protected-branches
我在Github 存储库中使用语义发布来创建推送时的自动发布。该版本需要将 package.json 和 CHANGELOG.md 提交到我的受保护分支。
我曾经从我的管理员帐户提供个人令牌,以允许语义发布推送到受保护的分支。为了提高安全性,我想通过新的细粒度token来替代PT 。因此,我使用与旧 PT 相同的管理员帐户创建了一个细粒度 PT,并授予其内容写入权限。不幸的是,这似乎不足以推送到受保护的分支。

知道可能需要哪些许可吗?
更新:不确定这是否受到支持。我在细粒度个人代币反馈讨论中发布了这个问题
@semantic-release/git需要Contents设置权限Read and write才能推送到受保护的分支。
Do not allow bypassing the above settings必须在分支保护设置中取消选中才能使其起作用。Allow force pushes不需要。
注意:我发现命名您的个人访问令牌密钥CI_GITHUB_TOKEN或GITHUB_TOKEN与 GitHub Actions 提供的默认密钥不同的任何名称更方便,以便在您的工作流程中轻松区分它们(因为您可能应该仅将 PAC 用于semantic-release)。
您还需要使用以下内容更新操作工作流程文件才能使其正常工作(否则git将继续使用默认生成的GITHUB_TOKEN):
- name: Checkout
uses: actions/checkout@v3
with:
persist-credentials: false # <--- this
Run Code Online (Sandbox Code Playgroud)
此外,如果您正在使用该@semantic-release/github插件,您可能还需要授予Read and write并Issues允许Pull requests机器人在版本提及时对问题和 PR 发表评论。
如果您正在寻找semantic-releaseCI 管道中的功能实现(带有手动配置清单),您可以查看我为该库所做的 PR。cron
文档中提到的重要安全性
注意:
GITHUB_TOKEN如果目标分支启用了分支保护,则无法使用自动填充。不建议通过使用GITHUB_TOKEN个人访问令牌覆盖自动填充的变量来减轻此限制,因为这会带来安全风险。由于秘密变量可用于任何分支触发的工作流,因此它成为潜在的攻击媒介,从不受保护的分支触发的工作流可以公开并使用具有提升权限的令牌,从而使分支保护变得微不足道。
通过使用细粒度令牌以及使用pull_request工作流触发器“防止对目标存储库的写入权限和秘密访问”,可以大大减轻这种风险。
但是,对存储库具有写入权限的用户仍可能会使用工作流漏洞推送分支,从而暴露您的个人访问令牌。
进一步阅读:
| 归档时间: |
|
| 查看次数: |
1399 次 |
| 最近记录: |