Create work item in Azure DevOps when a GitHub Issue is created
Update Azure DevOps work item when a GitHub Issue is updated
The id of the Work Item created or updated
-
Add a secret named
ADO_PERSONAL_ACCESS_TOKEN
containing an Azure Personal Access Token with "read & write" permission for Work Items -
Add an optional secret named
GH_PERSONAL_ACCESS_TOKEN
containing a GitHub Personal Access Token with "repo" permissions. See optional information below. -
Install the Azure Boards App from the GitHub Marketplace
-
Add a workflow file which responds to issue events.
- Set Azure DevOps organization and project details.
- Set specific work item type settings (type, new state, closed state)
Optional Env Variables
ado_area_path
: To set a specific area path you want your work items created ingithub_token
: Used to update the Issue with AB# syntax to link the work item to the issue. This will only work if the project is configured to use the GitHub Azure Boards app.ado_bypassrules
: Used to bypass any rules on the form to ensure the work item gets created in Azure DevOps. However, some organizations getting bypassrules permissions for the token owner can go against policy. By default the bypassrules will be set to false. If you have rules on your form that prevent the work item to be created with just Title and Description, then you will need to set to true.
name: Sync issue to Azure DevOps work item
"on":
issues:
types:
[opened, edited, deleted, closed, reopened, labeled, unlabeled, assigned]
jobs:
alert:
runs-on: ubuntu-latest
steps:
- uses: danhellem/github-actions-issue-to-work-item@master
env:
ado_token: "${{ secrets.ADO_PERSONAL_ACCESS_TOKEN }}"
github_token: "${{ secrets.GH_PERSONAL_ACCESS_TOKEN }}"
ado_organization: "ado_organization_name"
ado_project: "your_project_name"
ado_area_path: "optional_area_path"
ado_wit: "User Story"
ado_new_state: "New"
ado_close_state: "Closed"
ado_bypassrules: true