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.
- User commits the code in a feature branch
- 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
).
- If trigger is from
- Workflow
dispatch.yml
monitors issue comments for dispatch commands. - I create a issue comment and type text
/deploy
or/reject
to deploy or reject a release to publish it to VS Marketplace. - If
/deploy
command is detected, workflowdeploy.yml
is triggered. - 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.
on:
workflow_dispatch:
inputs:
action:
description: Trigger build
required: true
default: "ci"
pull_request:
branches:
- master
pull_request_review:
branches:
- master
types:
- submitted
push:
branches:
- 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
andpull_request_review
triggers allow us to trigger this workflow on PRs -
push
lets our workflow to trigger on actual commits onmaster
andfeature/**
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.
on:
issue_comment:
types:
- 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
with:
token: ${{ secrets.REPO_ACCESS_TOKEN }}
reaction-token: ${{ secrets.REPO_ACCESS_TOKEN }}
commands: deploy, reject
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.
on:
repository_dispatch:
types:
- 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.
Conclusion
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.
Top comments (0)