[CI][Docs] Pull requests closed by the PR limit workflow cannot be reopened by their authors
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 68/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- github-actions, javascript, markdown
- 领域
- ci-cd, documentation
调研方向
阅读 .github/workflows/pr_limit/comment.md、docs/source/developers/bug_reports.rst 和 .github/workflows/pr_limit/check.js，了解相互矛盾的重新打开说明以及当前 workflow 的行为。决定是修改指南还是 workflow，然后验证 PR 数量未达到上限的作者能否按照文档说明的流程重新打开已关闭的 pull request。
由索引模型根据 Issue 内容生成。
描述
Describe the bug, including details regarding any error messages, version, and platform.
The PR limit workflow closes a pull request that takes a contributor over the limit, and both its comment (.github/workflows/pr_limit/comment.md: "you are welcome to reopen this one") and the docs (docs/source/developers/bug_reports.rst: "Once one of your other pull requests has been merged or closed, you can reopen it") say that the author can reopen it later.
In practice the author cannot. After #54656 was merged, which brought me below the limit, reopening #54657 (closed by the workflow) fails:
$ gh pr reopen 54657 -R apache/arrow
API call failed: GraphQL: Could not open the pull request. (reopenPullRequest)
Presumably GitHub does not let an author without repository access reopen a pull request that was closed by an account with write access.
Either the comment and the docs could ask the author to request a reopen from a committer or collaborator (the workflow already leaves alone a pull request reopened by someone with repository access, see .github/workflows/pr_limit/check.js), or the workflow could let authors reopen their pull requests, e.g. by reopening them itself once the author is below the limit.
Component(s)
Continuous Integration, Documentation
- 主要语言
- C++
- 星标
- 17.2k
- 派生
- 4.4k
- 平均合并
- 2 天 19 小时
- 30 天内合并 PR
- 68
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
apache/arrow 的其他 Issue
-
[R][Parquet] ParquetReaderProperties does not expose page_checksum_verification, so a corrupt page CRC reads silently可能重新可做 关联的 PR 已关闭且未合并。 未关闭Component: R good-first-issue Type: enhancement
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
[C++][Python] IPC reader rejects a DictionaryEncoding without indexType, which the format allows可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭Component: C++ Component: Python Type: bug
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
[R] Silent loss of metadata integrity for date-time and numeric attributes in write_parquet()/read_parquet()可能重新可做 @james-finn-travers 于 19 天前认领，目前没有进行中的 PR。 未关闭Component: R Type: bug
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
[C++][Parquet] Plaintext-footer files written with AES_GCM_CTR_V1 record AES_GCM_V1 as the encryption algorithm and cannot be read可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭Type: bug
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
[R] Expose ignore_extra_columns and pad_short_rows CSV parse options可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭Component: R good-first-issue Type: enhancement
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
相似的 Issue
-
Jupyter kernel leaks two file descriptors per cell; after ~100 cells every cell fails with "pipe() failed"可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
Test discovery aborts on GPU builds without cuStateVec: check_cuStateVec expects a failed result but set_config() now raises RuntimeError可能已有人在做 @dmeliksetian 今天认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 84/100
Qiskit/qiskit-aer#2495 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
sumatrapdfreader/sumatrapdf#6403 ·
-
难度 1/5 1 小时以内 新手友好度 88/100
Jumballaya/Journeyman-Engine#199 ·
维护者通常 1 天内回复
-
backend enhancement
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 1 天内回复