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: 'JacksonKearl/vscode-triage-github-actions'
ref: master # not recommeneded, use the lastest released tag to ensure stability
- name: Install Actions
run: npm install --production
- name: Run Commands
uses: ./commandsAdditionally, 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.
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 anoctokitinstance (seeapisection above) and invoke the command. By keeping Action specific code seprate from the rest of the logic, it is easy to extend these commands to run via Apps, or even via webhooks to Azure Funtions or similar.Command.ts: This file contains the core logic for the command. The commands should operate on the Github interface inapi, 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 aTestbedinstance, and preferably verify the command works by querying through theGithubinterface, though there are some convenience commands implemented directly onTestbedfor ease of testing.cpi.ts: This is not present in every directory, but when present allows for running the action via command line, by runningnode action/cli.jswith appropriate flags.
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 whenn 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 laready 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: trueThis 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.
This classifier generates assignees and lables 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.
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.
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-seperated list of feature-areas to classify
assignees:
description: Pipe-seperated list of assignees to classifyThis is a Python Action, invoked like:
run: python ./actions/classifier/train/generate-models/generate.py categoryUpload 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: trueIn 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.
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: trueThis is a Python Action, invoked like:
run: python ./actions/classifier/apply/generate-labels/main.pyApplies labels generated from the python script back to thier 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: ''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 healthRespond 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: trueClone 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