Add static wiki pages to your work items
Explore the docs »
View Extension
·
Changelog
·
Report Bug
·
Request Feature
Table of Contents
Work item wiki is a control to render a wikipage inside a work item page. This can be useful if you need to document something for that work item type. For example definition of done/ready, bug categories etc.
Example where rendered on custom page:
Feature | Supported |
---|---|
Header (H1, H2, H3) | ✅ |
Italic | ✅ |
Bold | ✅ |
Link | ✅ |
Attachment | ✅ |
Image | ✅ |
Code / Code Block | ✅ |
Unordered list | ✅ |
Ordered list | ✅ |
Table | ✅ |
Mermaid Diagram | ❌ |
Work Item Mentions | ❌ |
Table of Contents | ❌ |
Formulas | ❌ |
Mention | ❌ |
Query Results | ❌ |
Task List | ❌ (Display only) |
Work Item Link is a custom form control that needs to be added to the Work Item Form. It can be added on an existing page, or as a new tab. For how to do this, refer to the official documentation.
Wiki Url
is the url to the wiki page, it should look something like:https://dev.azure.com/organization/demo-project/_wiki/wikis/demo-project.wiki/1/This-is-a-page
Version Branch
is used when publishing the wiki from code. If your main branch is notwikiMaster
, this field must be set to load links, images and attachments correctly.
-
A MarketPlace publisher Create a publisher
-
tfx-cli
installed. Due to issues with outdated dependencies this is not included inpackage.json
npm install -g tfx-cli
-
Pipelines uses the following extensions that needs to be installed in your organization in addition to default tasks:
- GitGuard - Used to verify changes to files, such as changelog.
- Azure DevOps Extension Tasks - Used to build and publish extension.
-
Clone the repo
git clone https://github.com/joachimdalen/azdevops-work-item-wiki.git
-
Install dependencies
> npm install
-
Update publisher in
vss-extension.dev.json
-
Compile development version
npm run prepare:dev
-
Run extension
npm run serve:dev
Note: You might need to open https://localhost:3000/ in your browser from time to time to accept the unsecure certificate to have the extension load properly from your local environment.
See documenation.
See the open issues for a full list of proposed features.
Contributions are welcome, both in the form of suggestions and code. Create
If you want to contribute code, I ask that you follow some guidelines.
- New and changed features should to the best ability be covered by tests
- Follow the branching policy:
feature/
for new featuresbugfix/
for bug fixesdocs/
for documentation changes
- If your change is related to an issue, use the id as the first part of the branch e.g
bugfix/12-fix-crash-when-updating-rule
- Pull requests should target the
develop
branch
- Fork the Project
- Create your Feature Branch (
git checkout -b feature/123-some-feature
) - Commit your Changes (
git commit -m 'Add some feature'
) - Push to the Branch (
git push origin feature/123-some-feature
) - Open a Pull Request
master
is only deployed toPROD
and tagged withv<extension_version>
- Pull requests are always squash merged into
master
master
is the only branch where GitHub releases are created for
- Pull requests are always squash merged into
feature/*
andbugfix/*
are deployed toQA
. For deployment toDEV
using local assets (only manifest changes are deployed to dev), theDeploy to DEV instead of QA
option needs to be checked when running the deployment pipeline.
QA
and DEV
are private development and verfication environments (publications of the extensions.) Submit a new issue if you for some reason wish access to either of these.
Note Access to these are not given for your local development. Please publish your own development release.
Distributed under the MIT License. See LICENSE
for more information.
If you have generic questions about the project or usage you can make contact in the following ways:
- Submit an issue with the
@type/question
label - New Issue - Submit a new question under the Marketplace Q&A section.