Close issues included in the "Development" links section

[skylon07]

From my understanding, currently this action only looks for issues that use the "magic closing words" in the PR description. It'd be nice if the list also included issues linked in the "Development" section:

This is useful if you're trying to manage PRs/issues from a project board. If a PR is open and an issue is linked to it, either from the PR's card or the issue's card, it's added to this "Development" list, but not the PR's description (without manual editing).

I think all that would need to be done is add any issues from the "Development" section that aren't already included after parsing the description. I know from reading other issues that this project aims to minimize API calls, though, so maybe this would need to be an opt-in behavior (like passing an optional flag alongside GITHUB_TOKEN).

[ldez]

Hello,

"Development" is just a name related to your board, I guess, because it doesn't seem to be related to something specific to GitHub.

I don't know how those elements are linked, I need a better overview to understand the context.

[skylon07]

Ah, sorry if my explanation was unclear -- I guess I assumed familiarity with the feature already.

Here's a couple of screenshots in a playground repo I have.

"Development list" in a pull request

"Development list" in an issue

It is a GitHub feature -- it's not specific to any project board. But (at least with how it's is set up at work) project boards provide an easy way to modify links between issues/PRs via this list. The most straightforward way to see how this list works is to create an issue/PR, click on the "Development" text, and start clicking issues in the dropdown list:

Screen.Recording.2024-10-28.at.14.32.07.mp4

It's also worth mentioning this issue isn't necessarily blocking anything for me; a workaround is to just modify the description of the PR manually any time issues are linked to it. The main request here is to remove that "manual work" by just supporting issues referenced via this list too.

I do think it's important to support both use cases though (ie this request should not replace current behaviors). Normally when you reference issues using "magic closing words" in PRs based on the default branch, it will automatically add them to the "Development" list. However, this is only when the PR is based on the default branch. If the PR is based on some other branch, issues won't be automatically added this way (despite the description text underneath the "Development" list suggesting they will -- it is wrong, I've tested it). Just wanted to note that caveat in case you explore the feature more.

Hopefully this gives you a better overview. Let me know if anything is still confusing to you.

[ldez]

Successfully merging this pull request may close these issues.

This section is for potential issues related to PR.

The problem is that you don't know if the issues in this section are just "related" or should be closed.

This weird GitHub feature is not often used (I never see a project that really uses it) because text-based references are the "default": it's easy to modify, and it's visible.

[ldez]

In all cases, there is no API to get the "Development" information.

And the pull request object doesn't have those elements.

[skylon07]

The problem is that you don't know if the issues in this section are just "related" or should be closed.

That's fair -- I think that was similar to GitHub's answer for not supporting non-default branches in the first place. For work, we just assume all issues "related" to a PR should be closed (because they're just tasks related to a feature branch). I know we aren't the only ones that assume this, but obviously that's not a true assumption for everyone anyway (and I sometimes forget that)... so that's probably another good argument for making this opt-in if it were added.

In all cases, there is no API to get the "Development" information.

Ah... well, that's interesting. I haven't ever messed with the GitHub API before, so I didn't know that was a limitation. That makes it a little hard to implement this feature then, huh? Haha.

Well, I appreciate you talking with me and looking into that. I'm still very happy this action exists -- I just found out about it today. It's solves a pain point I've had for a while and I was really hoping I wouldn't have to learn how to implement GitHub actions myself to solve it, heh. I'll leave it up to you to close the issue if you want, or keep it open if you want to come around to it later. I'm good either way.

[ldez]

For now, I'll put it on "wontfix" because it's just not possible to do it, but maybe the API will evolve.