I have previously blogged about publishing VSCode extensions to VSMarketplace (using GitHub actions). However, that workflow relied heavily on the branching strategy and was on assumption that anything that is merged to master is ready for publishing to VSMarketplace. It worked great, but occasionally I felt the need to test the extension from master and I wanted a way to approve before I decide to publish to marketplace. In this post we will see how I used ChatOps with the help of GitHub actions and Issues to achieve the same.

How will it work?

If you are short on time, the workflow I have implemented is as below.

  1. User commits the code in a feature branch
  2. Commit automatically triggers CI workflow build.yml
    • If trigger is from feature/* branch, it produces the artifact (.vsix file) and ends the workflow. This allows me to download and test the vsix file.
    • If trigger is from master branch, it creates a GitHub issue to monitor for dispatch comments (/deploy and /reject).
  3. Workflow dispatch.yml monitors issue comments for dispatch commands.
  4. I create a issue comment and type text /deploy or /reject to deploy or reject a release to publish it to VS Marketplace.
  5. If /deploy command is detected, workflow deploy.yml is triggered.
  6. If command is instead /reject, the release is rejected and issue is marked that it can be closed.

Curious on how each step is implemented? Read on.

Triggering CI build when user commits

The goal of CI is that, with each commit, we can produce shippable .vsix (packaged extension) file as an artifact for our extension. So we additional triggers in our build.yml file.

        description: Trigger build
        required: true
        default: "ci"
      - master
      - master
      - submitted
      - feature/** # match an pushes on feature/* and feature/<any sub branch>/*
      - master
    paths-ignore: # don't run when changes made to these folders
      - ".vscode/**"
  • workflow_dispatch trigger lets us manually trigger the workflow.

  • pull_request and pull_request_review triggers allow us to trigger this workflow on PRs
  • push lets our workflow to trigger on actual commits on master and feature/** branches.

Creating issue for dispatch events

As part of CI, once we produce artifact, we create the issue so that we can monitor issue for dispatch commands. I have a separate job create-issue in build.yml which creates the issue only if CI is running against master branch.

You can take a look at the job here

The output of the job will open an issue something like this (screenshot is from previous release).

Monitoring dispatch events in issue comments

The required issue is created and now is the time to monitor for issue comments with specific commands we defined - /dispatch and /reject.

We can do this with issue_comment trigger as below.

      - created

With the above trigger our dispatch.yml workflow triggers whenever a comment is added on our issue. To dispatch the events I am using action from Peter Evans as below.

- name: dispatch command
  if: github.repository_owner == github.event.comment.user.login
  uses: peter-evans/slash-command-dispatch@v2
    token: ${{ secrets.REPO_ACCESS_TOKEN }}
    reaction-token: ${{ secrets.REPO_ACCESS_TOKEN }}
    commands: deploy, reject

GitHub Actions

As you can see, in the last line (#7), I am supporting only deploy and reject commands.

I want to dispatch events, only if user commenting on the issue is owner of the repository (which is me). This allows me to dispatch events only if I have typed the dispatch command and no on else.

Handling dispatch commands

Now, I want to deploy to marketplace, when I see /deploy, and reject the deployment when I see /reject in issue comment.

For this, I have two workflow files deploy.yml and reject.yml with trigger similar to below.

      - deploy-command

So as soon as the user types /deploy command as a issue comment, the command is captured and dispatched by dispatch.yml workflow.

The dispatched command is captured by our deploy.yml or reject.yml which act on repository_dispatch event of either deploy or reject commands. All this work seamlessly with the help of slash-command-dispatch action and GitHub’s repository_dispatch events.

Our deploy workflow just publishes the extension to VS Marketplace and before doing this it also updates the comments to the issue which triggered the workflow.


There you have it! A quick and simple way to have a approval process in GitHub actions using ChatOps. I am confident that GitHub Actions will have OOB approval flows in Actions, but until that time, this is one way to achieve it. Do let me know if you know or have implemented similar things in a better way - I would love to learn about it.

About author
Utkarsh Shigihalli
Utkarsh Shigihalli
Utkarsh is passionate about software development and has experience in the areas of Azure, Azure DevOps, C# and TypeScript. Over the years he has worked as an architect, independent consultant and manager in many countries including India, United States, Netherlands and United Kingdom. He is a Microsoft MVP and has developed numerous extensions for Visual Studio, Visual Studio Code and Azure DevOps.
We Are
  • onlyutkarsh
    Utkarsh Shigihalli
    Microsoft MVP, Technologist & DevOps Coach

  • arora_tarun
    Tarun Arora
    Microsoft MVP, Author & DevOps Coach at Avanade

Do you like our posts? Subscribe to our newsletter!
Our Book