microsoft / vscode-github-triage-actions Goto Github PK

Github Actions for helping VS Code manage our issues

License: MIT License

TypeScript 88.59% Python 10.36% Shell 1.05%

vscode-github-triage-actions's Issues

Set `not planned` as the `state_reason` when automatically closing issues

The underlying octokit API (the latest version) has added a state_reason for specifying GitHub's new closing state. (It's not entirely clear to me if the correct value would be not planned or not-planned).

The new GitHub Issues - May 19th update | GitHub Changelog

Opening this issue to track updating VS Code's actions to specify the state_reason when automatically closing issues.

We cloned the VS Code actions as the basis for actions in the vscode-cpptools repo. Since using the latest octokit seems to require updating other dependencies, I figured I'd wait for you guys to address this first, then ingest your changes. :)

add `on-testplan` to any ref'd issue within an issue with label `testplan-item`

and conversely, set a date by which to adopt the verification-needed label for any feature-requests on the milestone that lack the on-testplan label

Post community PRs once they have 1 team review

For the monaco editor I get lots of PRs. It is annoying that I have to post those PRs manually to the review channel.

It would be much nicer if they get posted automatically once I added the first review (out of the two required reviews)

Labels aren't properly being assigned

It appears that labels are not being correctly assigned in the VS Code repo. They don't appear to be getting assigned at all.

Release pipeline action should understand reopening issues

i.e. remove unreleased/insiders-released

Improving the Description

Current:

There is an ambiguous point about the description written by vscode-triage-bot
It's not clear if vscode-triage-bot counts all the votes in the feature-suggestion comments or only the first post
Example microsoft/vscode#127087 (comment)

Update:

Writing a description that will not leave any ambiguity

Automatically comment on on issues with `verification-steps-needed`

During endgame when we verify issues, we use the verification-steps-needed label to indicate that steps are missing. However, users don't get notified when a label is changed so you are left unaware that steps are needed. It would be great if the bot could automatically comment on the issue to indicate this and ask the author to provide verification steps.

Don't delete PR messages if the PR has not been merged

We can attempt to parse the GitHub PR URL from the message and then query the GitHub API to check if the PR is merged or closed. This should prevent cases where the #codereview channel gives a false sense of security with a ✅ review

Support transferring issues via commands

Currently commands such as labeling or commenting on an issue can only provide a comment reply. Sometimes that comment reply says the issue should be transferred somewhere else. Instead, the bot should support transferring issues to repos it has access to.

Chinese (simplified) translation of english-please comment

Looks like your comment is also machine translated, so here it is:

感谢您创建此问题！

然而，由于您没有使用英语，我们很难进行处理。如果可能，请您将此问题描述修改为英文。请您直接编辑此问题，不要提交回复或新问题。

请注意，机器翻译服务通常无法处理用于讨论软件问题所需的技术性语言，所以我们推荐您寻找一位熟悉相关技术的人来协助翻译。

如果您无法做到，没有关系。此问题已经被标记为需要翻译，等待社区成员志愿进行翻译。

Automatically add `testplan-item` label and milestone to valid TPIs from team members

Could the VS Code GitHub bot possibly add the testplan-item label and milestone to all issues which are valid TPIs? This could run just for issues created by team members (so we don't have to validate issues from the community for example). This would address us missing a few TPIs because the label wasn't applied.

Node.js 16 actions are deprecated

Actions fail due to outdated node version. For example: https://github.com/dotnet/extensions/actions/runs/8293758762.

Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: ./actions/locker. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

According to the linked article node 16 has reached EOL last year and needs to be replaced with node 20.

I'm very far from web but I'm happy to send a PR with a change if it's a matter of find-replace like this:

insiders-released bot should understand endgame.

See microsoft/vscode#101804.

Why there is no more automated duplicate issue detection?

Hi there, I noticed that there are two types of bots used in the vscode repo, i.e., vscodebot and vscode triage bot. It seems vscodebot is not active anymore. I just checked this repo and it seems there is no duplicate issue detection function (e.g., microsoft/vscode#131696 (comment)) implemented. I am just curious why it is the case. Thank you for your time if you are willing to talk about it a bit :)

Question about Authorization Management In issue comment

Hi～ I am currently following your work in VS Code's Issue Triage GitHub Actions @JacksonKearl
And I try to make a kubevela robot for our open source project oam/Kubevela https://github.com/oam-dev/kubevela
After I test and fine tune in my own repo( https://github.com/wangyuan249/actioTestRepo ), I found it is a great project !

While we are facing some problems about Authorization Management In issue comment trigger:
We hope that we can specify some users to have the access when comment in issue area, and trigger the label or assign process and to prevent everyone can trigger this process or to test and play in issue area.

And Now we see such fields like “memberOf” 、“allowUsers” in the command.json file

  {
    "type": "author", 
    "memberOf": { "org": "oam-dev" },
    "action": "updateLabel",
    "addLabel": "author/kubevela"
  },
  {
    "type": "author",
    "notMemberOf": { "org": "oam-dev" },
    "action": "updateLabel",
    "addLabel": "author/not-kubevela"
  },
  {
    "type": "comment",
    "name": "needsMoreInfo",
    "allowUsers": [
	    "wangyuan249",
	    "user1",
	    "user2",
	    "user3"
    ],
    "action": "updateLabels",
    "addLabel": "needs more info"
  },

In my opinion, it is not flexible to maintain the "allowUser" list frequently or to maintain the member list in an organization.
Is there a way for us to scan our projects to determine who is the contributor of our project（or who often speaks in issue and give them the access to comment and trigger label. (When trigger a github action, to scan like this.)

I would be very appreciated if you could give me a reply. thanks!

Detect when `triage-needed` issue is unassigned

And then reassign to random again.

Triage bot could be smarter about issues reported from OSS build

I got this when I created microsoft/vscode#196250 from Help/Report Issue

Bot to post who the new build champ is?

Currently the build champ role can get forgotten and relies on my checking the ✅ emojis in #build against https://github.com/microsoft/vscode-internalbacklog/blob/main/assignments/build-champs.md to make sure everything is working correctly. It'd be nice if the ping happened automatically.

Label issues that were filed for an old version of vscode

I sometimes don't notice when the vscode version on an issue is out of date. It would be helpful to get a label or a comment on issues that are not on the latest version.

Test plan item marked as invalid even though it is not

Sample valid TPI - https://github.com/microsoft/vscode-internalbacklog/issues/4693
Open it and label as test-planitem

🐛 BOT invalidates it because the ref issue is not found even though it exists.

CC @lszomoru

ML Model: experiment with a Transformer model

Depending on the size of the dataset, using a Transformer model from https://github.com/huggingface/transformers could boost the accuracy of the classifier.

I can give a hand if needed=)

Investigate buggy auto cleaning

Auto cleaning without the ✅ seems to work unreliably often posting a cryptic error message

https://github.com/microsoft/vscode-pull-request-github/runs/8206970910?check_suite_focus=true

Addition of husky precommit hook causes all action runs to fail

The addition of the husky precommit hook in #96 causes all action runs to fail. Example: https://github.com/microsoft/vscode-docker/runs/7739520077?check_suite_focus=true

Run npm install --production --prefix ./actions
npm WARN config production Use `--omit=dev` instead.

> [email protected] prepare
> husky install

sh: 1: husky: not found
npm ERR! code 127
npm ERR! path /home/runner/work/vscode-docker/vscode-docker/actions
npm ERR! command failed
npm ERR! command sh -c husky install

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/runner/.npm/_logs/2022-08-09T05_11_[4](https://github.com/microsoft/vscode-docker/runs/7739520077?check_suite_focus=true#step:3:5)4_31[6](https://github.com/microsoft/vscode-docker/runs/7739520077?check_suite_focus=true#step:3:7)Z-debug-0.log
Error: Process completed with exit code 12[7](https://github.com/microsoft/vscode-docker/runs/7739520077?check_suite_focus=true#step:3:8).

Assign closed bugs, feature requests, and PRs to current milestone

I definitely mess this up a couple of times and have even had some bugs slip past verification as I forgot to assign them to the milestone. It would be nice if the bot could assign things like bugs, feature requests, and PRs to the milestone once they've been completed. We wouldn't want this for all labels such as duplicate, needs more info, or failed backlog-candidates.

Messages converted to draft and still in the codereview channel should be cleaned

A message can be converted to a draft many hours later and linger in the #codereview channel not needing a review.

The bot should auto-clean these in the same fashion as a closed PR

Add *.js files to .gitignore

As the bot is written in TypeScript, it does not need to have compiled JavaScript files in the GitHub repository

Support random fallback when unable to assign

Currently we have a dedicated inbox tracker to deal with issues the bot can not automatically assign. It would be preferable to instead fall back to assigning to a random team member.

"old version" should support `main` or commit hash

Continuation of #72 & #61.

I just opened microsoft/vscode#162609 & triggered "you may be using an old version", based on this line:

VS Code Version: main (currently at 2a07191)

I'm not suggesting that the exact syntax I used should be supported, but it would be nice to try to support main and/or a GitHub commit hash in some way or another. And by "support", I mean: don't suggest upgrading to the latest version.