Giter Site home page Giter Site logo

vscode-github-triage-actions's Introduction

VS Code's Issue Triage GitHub Actions

We host our GitHub Actions for triaging issues here.

Many of these are not specific to VS Code, and can be used in other projects by importing the repository like so:

steps:
  - name: Checkout Actions
    uses: actions/checkout@v2
    with:
      repository: 'microsoft/vscode-triage-github-actions'
      ref: stable # not recommeneded, use the lastest released tag to ensure stability
  - name: Install Actions
    run: npm install --production
  - name: Run Commands
    uses: ./commands

Additionally, in ./api, we have a wrapper around the Octokit instance that can be helpful for developing (and testing!) your own Actions.

Note: All Actions must be compiled/packaged into a single output file for deployment. We use ncc and husky to do this on-commit. Thus committing can take quite a while. If you're making a simple change to non-code files or tests, this can be skipped with the --no-verify git commit flag.

Code Layout

The api directory contains api.ts, which provides an interface for interacting with GitHub issues. This is implemented both by octokit.ts and testbed.ts. Octokit will talk to GitHub, testbed mimics GitHub locally, to help with writing unit tests.

The utils directory contains various commands to help with interacting with GitHub/other services, which do not have a corresponding mocked version. Thus when using these in code that will be unit tested, it is a good idea to manually mock the calls, using nock or similar.

The rest of the directories contain three files:

  • index.ts: This file is the entry point for actions. It should be the only file in the directory to use Action-specific code, such as any imports from @actions/. In most cases it should simply gather any required config data, create an octokit instance (see api section above) and invoke the command. By keeping Action specific code separate from the rest of the logic, it is easy to extend these commands to run via Apps, or even via webhooks to Azure Functions or similar.
  • Command.ts: This file contains the core logic for the command. The commands should operate on the GitHub interface in api, so that they may be run against either GitHub proper or the Testbed.
  • Command.test.ts: This file contains tests for the command. Tests should invoke the command using a Testbed instance, and preferably verify the command works by querying through the GitHub interface, though there are some convenience commands implemented directly on Testbed for ease of testing.
  • cpi.ts: This is not present in every directory, but when present allows for running the action via command line, by running node action/cli.js with appropriate flags.

Action Descriptions

Author Verified

Allow issue authors to verify their own issues by pinging them when the fix goes into insiders

inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions
    default: ${{ github.token }}
  requestVerificationComment:
    description: Comment to add when asking authors to verify the issue. ${commit} and ${author} will be substituted
    required: true
  releasedLabel:
    description: Label of issues which are released and thus able to be verified
    required: true
  verifiedLabel:
    description: Label of issues that are already verified and shouldn't be further interacted with
    required: true
  authorVerificationRequestedLabel:
    description: Label added by issue fixer to signal that the author can verify the issue
    required: true

Deep Classifier

This classifier generates assignees and labels using a deep-learning model stored in Azure Blob storage and generated using an Azure GPU instance. The model is created with help from simpletransformers and huggingface/transformers.

This setup is more involved and detailed in the Action's README.

Classifier

This classifier generates assignees and labels using a model stored in Azure Blob storage and generated using a GitHub Actions runner.

The full classifier workflow is a 2-part process (Train, Apply), with each part consisting of several individual Actions. It may be helpful to see how this is configured in the vscode-remote-release repository.

Train

In this part, the full issue data for the repository is downloaded and ML models are applied to it. These models then get uploaded to Azure Storage, to be later consumed by the Labeling part. This action should run periodically (approximately monthly) to keep the models from going stale.

fetch-issues

Download all issues and associated labeling data

inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions
    default: ${{ github.token }}
  areas:
    description: Pipe-separated list of feature-areas to classify
  assignees:
    description: Pipe-separated list of assignees to classify
generate-models

This is a Python Action, invoked like:

run: python ./actions/classifier/train/generate-models/generate.py category
upload-models

Upload models to blob storage

inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions
    default: ${{ github.token }}
  blobContainerName:
    description: Name of Azure Storage container
    required: true
  blobStorageKey:
    description: Access string for blob storage account
    required: true

Apply

In this part, the models generated in the Training phase get applied to issues. To save on bandwidth and compute, this is done in batches. For example, every half hour, the issues in the past period are passed through the models and assigned a label.

fetch-issues

Collect the issues which need to be labeled and write them to a file for later processing

inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions
    default: ${{ github.token }}
  from:
    description: Start point of collected issues (minutes ago)
    required: true
  until:
    description: End point of collected issues (minutes ago)
    required: true
  blobContainerName:
    description: Name of Azure Storage container
    required: true
  blobStorageKey:
    description: Access string for blob storage account
    required: true
generate-labels

This is a Python Action, invoked like:

run: python ./actions/classifier/apply/generate-labels/main.py
apply-labels

Applies labels generated from the python script back to their respective issues

inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions
    default: ${{ github.token }}
  config-path:
    description: The PATH of a .github/PATH.json in the repo that describes what should be done per feature area
    required: true
  allowLabels:
    description: "Pipe (|) separated list of labels such that the bot should act even if those labels are already present (use for bot-applied labels/etc.)"
    default: ''

Monitor

This action monitors unassign events and reports them back to app insights for analysis.

inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions
    default: ${{ github.token }}
  botName:
    description: The login of the bot
    required: true
  appInsightsKey:
    description: Key for Azure App Insights to monitor application health

Commands

Respond to commands given in the form of either labels or comments by select groups of people.

This takes as input a config-path, which is the config part of a ./github/config.json file in the host repo that describes the commands. This config file should have type:

export type Command =
	{ name: string } &
	({ type: 'comment' & allowUsers: (username | '@author')[] } | { type: 'label' }) &
	{ action?: 'close' } &
	{ comment?: string; addLabel?: string; removeLabel?: string } &
	{ requireLabel?: string; disallowLabel?: string }

Commands of type comment and name label or assign are special-cased to label or assign their arguments:

\label bug "needs more info"
\assign JacksonKearl
inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions
    default: ${{ github.token }}
  config-path:
    description: Name of .json file (no extension) in .github/ directory of repo holding configuration for this action
    required: true

Copycat

Clone all new issues in a repo to a different repo. Useful for testing.

inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions to both repos
    default: ${{ github.token }}
  owner:
    description: account/organization that owns the destination repo (the microsoft part of microsoft/vscode)
    required: true
  repo:
    description: name of the destination repo (the vscode part of microsoft/vscode)
    required: true

English Please

Action that identifies issues that are not in English and requests the author to translate them. It additionally labels the issues with a label like translation-required-russian, allowing community members to filter for issues they may be able to help translate.

It can also add needs more info type labels, to allow the needs-more-info action to close non-english issues that do not receive translations after a set time.

Automatic language detection simply checks for non-latin characters. Issues in foreign languages with latin script must be flagged manually, by applying the nonEnglishLabel.

In our experience, automatic translation services are unable to effectively translate technical language, so rather than automatically translating the issue, this Action flags the issue as being in a particular language and lea es a comment requesting the original issue author to either translate the issue themselves if they are able to, or wait for a community member to translate.

This Action uses the Azure Translator Text API to identify languages and translate the comment requesting translation to the issue's language.

If you are able to provide a manual translation of the comment, you can help us out by leaving an issue or file a PR against the file ./english-please/translation-data.json. Thanks!

inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions
    default: ${{ github.token }}
  nonEnglishLabel:
    description: Label to add when issues are not written in English
    required: true
  needsMoreInfoLabel:
    description: Optional label to add for triggering the 'needs more info' bot to close issues that are not translated
  translatorRequestedLabelPrefix:
    description: Labels will be created as needed like "translator-requested-zh" to allow community members to assist in translating issues
    required: true
  translatorRequestedLabelColor:
    description: Labels will be created as needed like "translator-requested-zh" to allow community members to assist in translating issues
    required: true
  cognitiveServicesAPIKey:
    description: API key for the text translator cognitive service to use when detecting issue language and responding to the issue author in their language
    required: true

Feature Request

Manage feature requests according to the VS Code feature request specification

inputs:
  token:
    description: GitHub token with issue, milestone, comment, and label read/write permissions
    default: ${{ github.token }}
  candidateMilestoneID:
    description: Numeric ID of the candidate issues milestone
    required: true
  candidateMilestoneName:
    description: Name of the candidate issues milestone
    required: true
  backlogMilestoneID:
    description: Numeric ID of the backlog milestone
    required: true
  featureRequestLabel:
    description: Label for feature requests
    required: true
  upvotesRequired:
    description: Number of upvotes required to advance an issue
    required: true
  numCommentsOverride:
    description: Number of comments required to disable automatically closing an issue
    required: true
  labelsToExclude:
    description: A comma-separated list of labels to exclude from processing
  initComment:
    description: Comment when an issue is introduced to the backlog milestone
    required: true
  warnComment:
    description: Comment when an issue is nearing automatic closure
    required: true
  acceptComment:
    description: Comment when an issue is accepted into backlog
    required: true
  rejectComment:
    description: Comment when an issue is rejected
    required: true
  rejectLabel:
    description: Label applied to issues that are rejected
  warnDays:
    description: Number of days before closing the issue to warn about it's impending closure
    required: true
  closeDays:
    description: Number of days to wait before closing an issue
    required: true
  milestoneDelaySeconds:
    description: Delay between adding a feature request label and assigning the issue to candidate milestone
    required: true

Locker

Lock issues and/or PRs that have been closed and not updated for some time.

inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions
    default: ${{ github.token }}
  daysSinceClose:
    description: Days to wait since closing before locking the item
    required: true
  daysSinceUpdate:
    description: days to wait since the last interaction before locking the item
    required: true
  ignoredLabel:
    description: items with this label will not be automatically locked
  ignoreLabelUntil:
    description: items with this label will not be automatically locked, until they also have the until label
  labelUntil:
    description: items with this will not automatically locked, even if they have the ignoreLabelUntil label
  typeIs:
    description: either 'issue' or 'pr' to limit the query to only those types

Needs More Info Closer

Close issues that are marked a needs more info label and were last interacted with by a contributor or bot, after some time has passed.

Can also ping the assignee if the last comment was by someone other than a team member or bot.

inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions
    default: ${{ github.token }}
  label:
    description: Label signifying an issue that needs more info
    required: true
  additionalTeam:
    description: Pipe-separated list of users to treat as team for purposes of closing `needs more info` issues
  closeDays:
    description: Days to wait before closing the issue
    required: true
  closeComment:
    description: Comment to add upon closing the issue
  pingDays:
    description: Days to wait before pinging the assignee
    required: true
  pingComment:
    description: Comment to add when pinging assignee. ${assignee} and ${author} are replaced.

New Release

Label issues with a version tag matching the latest vscode release, creating the label if it does not exist. Delete the label (thereby unassigning all issues) when the latest release has been out for some time

inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions
    default: ${{ github.token }}
  days:
    description: time ago for releases to count as new releases
    required: true
  label:
    description: name of label to apply
    required: true
  labelColor:
    description: color of label to apply
    required: true
  labelDescription:
    description: description of label to apply
    required: true

Stale Closer

Closes stale issues that have not had activity or upvotes

inputs:
  token:
    description: GitHub token with issue, milestone, comment, and label read/write permissions
    default: ${{ github.token }}
  candidateMilestoneID:
    description: Numeric ID of the candidate issues milestone
    required: true
  candidateMilestoneName:
    description: Name of the candidate issues milestone
    required: true
  featureRequestLabel:
    description: Label for feature requests
    required: true
  upvotesRequired:
    description: Number of upvotes required to advance an issue
    required: true
  numCommentsOverride:
    description: Number of comments required to disable automatically closing an issue
    required: true
  labelsToExclude:
    description: A comma-separated list of labels to exclude from processing
  warnComment:
    description: Comment when an issue is nearing automatic closure
    required: true
  rejectComment:
    description: Comment when an issue is rejected
    required: true
  rejectLabel:
    description: Label applied to issues that are rejected
  warnDays:
    description: Number of days before closing the issue to warn about it's impending closure
    required: true
  closeDays:
    description: Number of days to wait before closing an issue
    required: true
  milestoneDelaySeconds:
    description: Delay between adding a feature request label and assigning the issue to candidate milestone
    required: true

Test Plan Item Validator

Tag testplan item issues that don't match the VS Code test plan item format

inputs:
  token:
    description: 'GitHub token with issue, comment, and label read/write permissions'
    default: ${{ github.token }}
  label:
    description: The label that signifies an item is a testplan item and should be checked
    required: true
  invalidLabel:
    description: The label to add when a test plan item is invalid
    required: true
  comment:
    description: Comment to post to invalid test plan items
    required: true

Topic Subscribe

Subscribe a set of users to an issue when it gets a particular label.

inputs:
  token:
    description: GitHub token with issue, comment, and label read/write permissions
    default: ${{ github.token }}
  config-path:
    description: Name of .json file (no extension) in .github/ directory of repo holding configuration for this action
    required: true

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

vscode-github-triage-actions's People

Contributors

bpasero avatar bwateratmsft avatar chrmarti avatar dependabot[bot] avatar ejizba avatar eleanorjboyd avatar ericboucher avatar ismailarilik avatar jeffhandley avatar joaomoreno avatar karrtikr avatar lramos15 avatar microsoftopensource avatar moshfeu avatar riflechan avatar sandy081 avatar sanmai-nl avatar vinckr avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

vscode-github-triage-actions's Issues

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.

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.

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.

Add duplicate PR detection

It is possible that if you toggle from draft, ready for review, back to draft that the message is posted twice. It is also possible someone manually posts a message prior to the the bot getting to it. We should detect duplicates and not post.

A large part of these issues stem from PRs being converted to draft very close to creation time but the GitHub payload still comes back as draft

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

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!

"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.

Chinese (simplified) translation of english-please comment

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

感谢您创建此问题!

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

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

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

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. :)

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.

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 :)

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)

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

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.