We have created a few extensions for Azure DevOps (0) that are pipeline extensions.
We are trying to create new extensions that can react to changes in work items of Azure Boards. The API's for interacting with changes in work items are fairly straight-forward, but we are struggling with configuration of the extension.
Essentially we need to allow the users to configure the extension on two levels
1) On "Organization level"
It should be possible for a user (Project Administrator) to configure parameters as "external system URL" etc. An example of this could be something like below mockup:
2) On "Project level"
For each project in Azure DevOps an admin should be able to configure parameters like "Enable/disable extension" or "External UID" etc. An example of this could be something like below mockup:
When the extension reacts to "Work item saved" it will query the parameters on both levels to figure out what to do.
My problem is: where the heck do I save this information? I could add a number of "custom fields" to the template in use, but since fields can only be added to work item types, it is really not ideal in any way.
Where can I save this information through the API's?
PS: Source code for our extensions are available as OSS (Apache license) here:
(0) https://bitbucket.org/projectum/
Thank you :-)
It turns out that Azure DevOps has a way to store data for extensions. It can store data on both Project Collection scope as well as User scope.
I think I will be able to use this to store the data I need. All I need now is to figure out where to put the UI that the user or admin will use to maintain this data.
https://learn.microsoft.com/en-us/azure/devops/extend/develop/data-storage?view=vsts
:-)
For #1, it somewhat looks like what you can configure under a pipeline's service connections. This is per project though and not at an organization level.
This might be easier to manage outside of an extension and instead just use a service hook to call some middle tier that accomplishes what you want.
Related
For context, I just read this question Creating Issues on Board in Azure DevOps from API
I have the exact same goal, except the solution didn't address it enough in my opinion because it didn't create the element inside the board.
I am using https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/create?view=azure-devops-rest-5.1&tabs=HTTP, It works great, however, I cannot send my item in a specific team board, it always end in "Work Items" menu, did I miss a field or something ?
That depends on your board.... as an example, for Agile you have to create User Story, Feature, or Epic.
Additionally, check your team settings (Define area paths and assign to a team)... if it uses custom settings for Area Path, you have to add Area Path to your request body.
I'm looking for a way to add an additional column for test steps in Azure DevOps TestCase WorkItem.
It is possible to add new fields (string / select controls etc) and reorder existing fields on the test case level. But is it possible to customize the Microsoft.VSTS.TCM.Steps Field?
There is no possibility to adapt it in the test case edit view
and the field delete / edit in all fields area is deactivated too
In the self hosted azure devops server 2019 it seems to be possible over tfs power tools / wit export & import. But how to do it in the azure cloud? maybe there is a way over extensions?
It seems you are using XML process model in azure devops server 2019. But in azure devops service, you are using inherited processes model. To customize work item types in inherited processes, please refer to the following link:
https://learn.microsoft.com/en-us/azure/devops/organizations/settings/work/customize-process-wit?view=azure-devops
You can only delete the custom fields, those fields defined for system processes can not be deleted. Steps is a particular field that can not be hide. If you want to customize Steps field, you would need to create a custom work item and customize the Steps field there.
I would like to add some custom fields to a Azure DevOps Project.
By default, there are only two fields available: Name and Description.
However, I would like to add additional information to the project like internal ProjectNo, OrderNo, OfferNo, Offer Date and so on.
Is there a way to do this?
As far as I'm aware there isn't any way to custom this aspect currently. You could always add it as a suggestion here; https://developercommunity.visualstudio.com/spaces/21/index.html.
Alternatively, depending on what you are looking to accomplish and how you want to use these new fields, could you make these 'projects' Epics (or create another Work Item type) under a 'global project'? If so you can easily customise work items to include these fields.
I have a Personal Access Token about to expire in DevOps/VSTS, but I can't see it in DevOps to do a ctrl-f and find it in my source code.
I have an Angular 2+ frontend with a .net core api backend.
Which file should I be looking at? Does it need to go in the backend? Or Frontend? Or both?
config.json? project.json? Which property is it (if it is a config file like that)?
Or is it somewhere else I need to update this? Not in source code, but something with the build agent? How would I update that?!
Which file should I be looking at? Does it need to go in the backend?
Since we could not clearly know how is your script look like, I assume you may not remember clearly about this because of huge script files. For this, Azure Devops has a feature Search can search what you want across all your code.
For any repos which with a api called, we suggest you search the code files first with Search feature. And also, you may pass the token value with task variable. So, you also need to check your pipeline variable.
Or developers need the Work Item forms as designed for our agile process, but we'd like our regular users to be able to add new bugs and user stories using a simplified form, where a lot of fields are removed and some have team specific default values.
How can this be done?
The closest match I've found so far is templates, where field defaults can be defined, but the form that's used/displayed is still the large cluttered one. Being able to use the template link to land directly on a pre-filled form is a step in the right direction, though.
Azure DevOps allows you to modify your process template and add new work items to your project. You can find the documentation to do this here.
Go to Organization settings for your account --> Process --> Create an inherited process from your process template --> New Work Item Type.
You can then define the fields you want and the layout of the template.
Something else that could be useful in your scenario is the Test and Feedback Extension. This is a simple browser plugin that lets users explore feedback requests and file comments and bugs.