这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@robertkirkman
Copy link
Member

No description provided.

@robertkirkman robertkirkman force-pushed the auto-close-repository-health-check-issues branch from 2b6e8d5 to 71cb3aa Compare November 9, 2025 09:03
@robertkirkman robertkirkman force-pushed the auto-close-repository-health-check-issues branch 4 times, most recently from 9e5c9a1 to 2f6e9ea Compare November 9, 2025 09:20
@robertkirkman robertkirkman changed the title feat(ci): Automatically close old "Repository Health Check Failed" issues before opening new ones feat(ci): Automatically close the previous "Repository Health Check Failed" issue before opening the new one Nov 9, 2025
owokitty added a commit to owokitty/termux-packages that referenced this pull request Nov 9, 2025
owokitty added a commit to owokitty/termux-packages that referenced this pull request Nov 9, 2025
@robertkirkman
Copy link
Member Author

I ran a test in my fork repository on account @owokitty, which is visible in the GitHub links above, and it does successfully detect my placeholder test "Repository Health Check Failed" issue in my fork,

however, unfortunately I wasn't able to complete a full test of detecting and also closing the issue, because when it got to the part of the script where gh issue close is used, this error occurred:

image

I'm assuming that this error occurs because my fork doesn't have access to the real @termuxbot2 and the real repository to test with, so it doesn't have the GitHub permission to close its own issues like that because my fork repository isn't the same as the real repository.

I don't know if there's any way to test whether the same error would occur when attempting to use gh issue close on the real repository or not, without actually deploying this and allowing it to run.

At the very least, my test has confirmed (I think) that the correct issue gets detected by the gh issue list | jq command, so if allowed to run, it wouldn't attempt to close any unexpected issues, and would only attempt to close the issue that it's intended to close.

@robertkirkman robertkirkman force-pushed the auto-close-repository-health-check-issues branch from 2f6e9ea to 2848402 Compare November 9, 2025 09:45
@robertkirkman robertkirkman marked this pull request as ready for review November 9, 2025 09:46
owokitty added a commit to owokitty/termux-packages that referenced this pull request Nov 9, 2025
@robertkirkman robertkirkman force-pushed the auto-close-repository-health-check-issues branch from 2848402 to 1a12af3 Compare November 9, 2025 09:56
@robertkirkman robertkirkman marked this pull request as draft November 10, 2025 14:00
@robertkirkman robertkirkman force-pushed the auto-close-repository-health-check-issues branch from 1a12af3 to ff493ab Compare November 10, 2025 14:13
@robertkirkman robertkirkman marked this pull request as ready for review November 10, 2025 14:17
@truboxl
Copy link
Contributor

truboxl commented Nov 19, 2025

The current implement closes the latest one at a time and then create new.

I think it should create the new one then close all the rest of the issues. Or the reverse if the implementation is easier to maintain.

@robertkirkman
Copy link
Member Author

robertkirkman commented Nov 19, 2025

I think it should create the new one then close all the rest of the issues. Or the reverse if the implementation is easier to maintain.

My original implementation did that (visible in PR commit history above).

@TomJo2000 told me to make it close only one issue in this comment: #27165 (comment) , so I changed it to do what he told me.

@TomJo2000
Copy link
Member

TomJo2000 commented Nov 19, 2025

@TomJo2000 told me to make it close only one issue in this comment: #27165 (comment) , so I changed it to do what he told me.

That was mostly intended to avoid mishaps like it mass closing unrelated issues in case it got an unfiltered list of issues back somehow.

In the general case we should have exactly 0 or 1 prior open health check issue, and that's the only one we'd want to close in favor of the superseding one.
Bulk closing open health check issues prior to this PR is a one time thing that can (and I'd argue should) be done manually after this PR is merged.

@truboxl
Copy link
Contributor

truboxl commented Nov 19, 2025

You are closing the latest open issue instead of the oldest open issue so no, the current implementation isnt correct either.

I rather go for bulk closing to clear confusion.

@robertkirkman robertkirkman changed the title feat(ci): Automatically close the previous "Repository Health Check Failed" issue before opening the new one feat(ci): Automatically close old "Repository Health Check Failed" issues before opening new ones Nov 19, 2025
@robertkirkman robertkirkman force-pushed the auto-close-repository-health-check-issues branch from ff493ab to 8d9e768 Compare November 19, 2025 06:37
@robertkirkman
Copy link
Member Author

You are closing the latest open issue instead of the oldest open issue so no, the current implementation isnt correct either.

I rather go for bulk closing to clear confusion.

I don't understand exactly what you mean would be the difference between the "latest" and "oldest" open issue matching the query in the case when only 1 issue is open, but I have changed this back to how it was at first now.

@truboxl
Copy link
Contributor

truboxl commented Nov 19, 2025

Good. The current implementation lists all the open issues that will be closed before open a new issue:

$ gh issue list \
              --limit 99999 \
              --label "health-check" \
              --state open \
              --search "$ISSUE_TITLE in:title type:issue" \
              --json number | jq -r '.[] | .number'
27291
27162
27081
27008
26935
26850

The previous implementation only list the latest open issue. By Tom's logic the ancient issues are still kept. Bad.

$  gh issue list \
              --limit 1 \
              --label "health-check" \
              --state open \
              --search "$ISSUE_TITLE in:title type:issue" \
              --json number | jq -r '.[] | .number'
27291

@robertkirkman
Copy link
Member Author

robertkirkman commented Nov 19, 2025

Good. The current implementation lists all the open issues that will be closed before open a new issue:

$ gh issue list \
              --limit 99999 \
              --label "health-check" \
              --state open \
              --search "$ISSUE_TITLE in:title type:issue" \
              --json number | jq -r '.[] | .number'
27291
27162
27081
27008
26935
26850

The previous implementation only list the latest open issue. By Tom's logic the ancient issues are still kept. Bad.

$  gh issue list \
              --limit 1 \
              --label "health-check" \
              --state open \
              --search "$ISSUE_TITLE in:title type:issue" \
              --json number | jq -r '.[] | .number'
27291

Tomjo2000's point was that, if all extra issues were manually closed first, then only 1 open matching issue would ever exist at any point in time, meaning that it would never be necessary to match more than 1 issue.

The only reason I originally implemented it to close more than 1 issue is because they have been building up for some time without this PR applied, so I wanted it to automatically close all of the preexisting issues the first time it runs.

After the first run of this workflow after the PR is merged, the loop will never have more than 1 iteration ever again, but that's ok.

@robertkirkman robertkirkman force-pushed the auto-close-repository-health-check-issues branch from 8d9e768 to 90310f7 Compare November 19, 2025 07:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants