I am developing a service hook extension for Azure DevOps that is loosely based on the sample provided on https://learn.microsoft.com/en-us/azure/devops/extend/develop/add-service-hook?view=azure-devops
I cannot find any documentation on the available actions. For example, the sample provides a sample consumer with an action of publishEvent but there is no reference material on this.
Could someone please point me toward any reference documentation that might exist?
It's only supported to send standard event payload with custom service hooks for now. In the sample, you can see the action defined as below:
"actions": [
{
"id": "performAction",
"name": "Perform action",
"description": "Posts a standard event payload",
"supportedEventTypes": [
"git.push",
"git.pullrequest.created",
"git.pullrequest.updated"
],
"publishEvent": {
"url": "{{{url}}}",
"resourceDetailsToSend": "all",
"messagesToSend": "all",
"detailedMessagesToSend": "all"
}
}
]
With this setting, it will send all the payload about the trigger event to the URL you configured. And you can configure how much of the information to send:
resourceDetailsToSend - all, minimal, none
messagesToSend - all, text, html, markdown, none
detailedMessagesToSend - all, text, html, markdown, none
Related
I am trying to create events via the MS Graph API (with Powershell but using the REST API).
So far I can create events without problems. All the properties I want to set are correctly set - except I don't seem to manage to set the IcalUId - as I cannot find such created events via
"/users/$UPNofMBX/calendar/events?`$filter=iCalUId eq '$appointment_UID'"
($Appointment_UID = the desired identifier for later finding the event - It is coming from an external - commercial solution)
If I import via Outlook an ICS file with a specific value in the "UID:" field, the above Graph query finds the event which carries the searched for value in the ICalUId field.
If I set it at creation time via graph with the below body, the above search query line does not find the event.
The body of the REST call looks like this:
$Body = #"
{
"subject": "$appointment_Subject",
"iCalUId": "$appointment_uid",
"body": {
"contentType": "HTML",
"content": "$appointment_Body"
},
"start": {
"dateTime": "$appointment_Time_Start",
"timeZone": "Europe/Berlin"
},
"end": {
"dateTime": "$appointment_Time_End",
"timeZone": "Europe/Berlin"
},
"location":{
"displayName":"$appointment_Location"
},
"attendees": [
{
"emailAddress": {
"address":"$UPNofMBX",
"name": "Ressource"
},
"type": "required"
}
],
"allowNewTimeProposals": false,
"transactionId":"$(New-Guid)"
}
Unfortunately, in none of the examples # Microsoft is the use of the ICalId explained when creating an event. Also I didn't find any examples on the net.
Hint: If I use Microsoft.Exchange.WebServices.Data within a C# app, I can set the iCalUId.
The goal is to set a reference UID / ID / anything in the to-be-created event so that I can find this event later via this reference in order to update or delete it. The only reference information I have is the UID (iCalUId) from an (update/delete) ICS file from the external commercial solution.
I would prefer to not build a translation table between the UIDs from the commercial solution when they arrive via ICS and the IDs of the newly created events when they are given back in the REST call # creation time so I can find them later if necessary.
Any insight what I am doing wrong or a solution is greatly appreciated.
I am using the MLFlow Webhooks , mentioned here. I am using that to queue an Azure Devops Pipeline.
However, I can't seem to to find a way to retrieve the payload variables inside my pipeline.
E.g. during transition of models, according to the document, such a payload is passed
POST
/your/endpoint/for/event/model-versions/stage-transition
--data {
"event": "MODEL_VERSION_TRANSITIONED_STAGE",
"webhook_id": "c5596721253c4b429368cf6f4341b88a",
"event_timestamp": 1589859029343,
"model_name": "Airline_Delay_SparkML",
"version": "8",
"to_stage": "Production",
"from_stage": "None",
"text": "Registered model 'someModel' version 8 transitioned from None to Production."
}
My webhook is created like this:
mlflow_webhook_triggerDevOps={
"events": ["TRANSITION_REQUEST_CREATED", "REGISTERED_MODEL_CREATED"],
"description": "Integration with Azure DevOps",
"status": "ACTIVE",
"http_url_spec": {
"url": "https://dev.azure.com/orgname/ProjectName/_apis/build/builds?definitionId=742&api-version=6.0",
"authorization": "Basic " + base64_message
}
}
mlflow_createwebhook=requests.post('https://databricksurl/api/2.0/mlflow/registry-webhooks/create', headers=header, proxies=proxies, json=mlflow_webhook_body)
How do I then retrieve the payload variable e.g. model_name, inside my pipeline definition in Azure Devops?.
I looked at this post, but I can't seem to see any payload information (like mentioned above) under the Network-payload tab (or I am not using properly).
Right now, I can trigger the pipeline, but can't seem to find a way to retrieve the payload.
Is it possible? Am I missing something?
I'm using FHIR R4 with Hapi FHIR API.
I want to know how marked the ServiceRequest resources with information about created user.
I've read the FHIR documentation and I've found the relevantHistory tag where I can put there a Provenance reference.
All good but the HAPI Fhir can't query that field/tag so I can't get all ServiceRequests created by me or another user.
I've also tried to use a customize extension named tracking, where I've put the tracking user info.
I don't want to use a requester tag because, it is filled with other guide line meaning supplied by customer
EDIT AFTER Mirjam Baltus
Hi,
interesting your point of view but, I've found another solution as follow, I want to discuss it with you (if you want).
I've added a SearchParameter resource attached on ServiceRequest to allow the search on relevantHistory field.
This is the JSON resource:
{
"resourceType": "SearchParameter",
"id": "6589",
"meta": {
"versionId": "7",
"lastUpdated": "2021-02-25T11:25:25.549+00:00",
"source": "#1btUOFbG0D3dMdwI"
},
"title": "Storia",
"status": "active",
"code": "relevantHistory",
"base": [
"ServiceRequest"
],
"type": "reference",
"expression": "ServiceRequest.relevantHistory",
"xpathUsage": "normal",
"target": [
"Provenance"
],
"modifier": [
"missing"
],
"chain": [
"reference"
]
}
So I've written a query on ServiceRequest filtered by relevantHistory field (linked to Provenance).
I've adopted this strategy because I need to know only the creator of ServiceRerquest, so in this way, I've factorized the information in Provenance resource where in the target field I've put the Practitioner / Organization who created the ServiceRequest and in the agent component I've replicated this information with ENTERER value in the enum AgentRole and AgentType.
In this way, I've collected one Provenance for more ServiceRequests, instead If I follow your way, I'll have for each ServiceRequest a dedicated Provenance.
You think I've followed a wrong way or it is a possible solution?
The relevantHistory is not the right field to use, since that will only list older Provenance resources that hold relevant information. The description specifically says it does not hold the Provenance resource associated with the current version of the ServiceRequest (see http://hl7.org/fhir/servicerequest-definitions.html#ServiceRequest.relevantHistory).
I think Provenance can still help you. You would not search on a field in ServiceRequest, but find ServiceRequests that have a Provenance where you/user are the actor:
GET [base]/ServiceRequest?_has:Provenance:target:actor=[user_reference]
Or approach it the other way around, by looking for Provenance resources from the user, and including ServiceRequests that are the target of the Provenance.
Added after edit of original post:
As I mention in my comment, I think the way you are trying to use the relevantHistory field and one Provenance for multiple ServiceRequests is not according to how that field and resource type are supposed to be used.
If you are able to create a custom search parameter, why not use an extension on the ServiceRequest to indicate who created it, and then make that extension searchable?
If you want more discussion about this, please ask on https://chat.fhir.org, where more people from the FHIR community will be able to chime in.
We're building a web based self service for our employees, to speed up/improve everyones DevOps experience. The self service utilizes the Azure Devops REST API and most of it works fine but as I'm about to implement the branch policies I get stuck for lack of documentation (or my inability to find it).
I think I have found what documentation is available for creating policy configurations, like this article. There's just a general mention of "settings" needs to be a JObject and then seven examples for various scenarios but if there are any reference articles for the 14 supported policy types then I have missed it.
Am I just blind or did Microsoft just not bother with documenting how to form the JObjects for the different kinds of configurations?
Azure Devops REST API documentation for policies is missing?
For me, I am more inclined that the document does not explicitly point out the content of JObject.
When we check that REST API document Configurations - Create, we could get following info:
Indeed, it only states that its type is a JSON object without specific content or examples.
To get the content of this JSON object, I use the REST API Configurations - Get to get the content of the Response body, I could get following response body:
"settings": {
"minimumApproverCount": 2,
"creatorVoteCounts": false,
"allowDownvotes": false,
"resetOnSourcePush": false,
"requireVoteOnLastIteration": false,
"resetRejectionsOnSourcePush": false,
"blockLastPusherVote": false,
"scope": [
{
"refName": "refs/heads/Dev",
"matchKind": "Exact",
"repositoryId": "dcb40ef6-dae0-4e3c-b581-2f71c76e09a6"
}
]
},
So, we could to know the content is indeed a JSON object and it will be different due to the different policies we set.
Now, we move back to the samples in that document, we could find that there are many such settings, like:
Approval count policy:
{
"isEnabled": true,
"isBlocking": false,
"type": {
"id": "fa4e907d-c16b-4a4c-9dfa-4906e5d171dd"
},
"settings": {
"minimumApproverCount": 1,
"creatorVoteCounts": false,
"scope": [
{
"repositoryId": null,
"refName": "refs/heads/master",
"matchKind": "exact"
}
]
}
}
If we want to set any other supported policy types, we can manually set it on the UI, and then get the corresponding response body about it.
If I wanted to create (POST) a new resource linking two independent resources, what is the most proper - with respect to HATEOAS and REST principles - way to structure the entity of the request?
Any references in RFCs, W3C documents, Fielding's thesis, etc., about the proper way for a client to request two independent resources be linked together would be most valuable. Or, if what I'm interested in is simply outside the scope of REST, HATEOAS, an explanation of why would also be great.
Hopefully my question above is clear. If not, here's a scenario and some background to ground the question.
Let's say I have two independent resources: /customer and /item, and a third resource /order intended to the two.
If I'm representing these resource to the client in a HATEOAS-like way (say with JSON-LD), a customer might (minimally) look like:
{
"#id": "http://api.example.com/customer/1"
}
and similarly an item like:
{
"#id": "http://api.example.com/item/1"
}
I'm more concerned about what scheme the entity of the POST request should have, rather than the URL I'm addressing the request to. Assuming I'm addressing the request to /order, would POSTing the following run afoul of HATEOAS and REST principles in any way?
{
"customer": {"#id": "http://api.example.com/customer/1"},
"item": {"#id": "http://api.example.com/item/1"}
}
To me, this seems intuitively OK. However, I can't find much or any discussion of the right way to link two independent resources with a POST. I discovered the LINK and UNLINK HTTP methods, but these seem inappropriate for a public API.
The client does not build URIs, so this is wrong unless these resource identifiers or at least their template came from the service. It is okay to use the id numbers instead of the URIs until you describe this in the response which contains the POST link.
An example from the hydra documentation:
{
"#context": "http://www.w3.org/ns/hydra/context.jsonld",
"#id": "http://api.example.com/doc/#comments",
"#type": "Link",
"title": "Comments",
"description": "A link to comments with an operation to create a new comment.",
"supportedOperation": [
{
"#type": "CreateResourceOperation",
"title": "Creates a new comment",
"method": "POST",
"expects": "http://api.example.com/doc/#Comment",
"returns": "http://api.example.com/doc/#Comment",
"possibleStatus": [
... Statuses that should be expected and handled properly ...
]
}
]
}
The "http://api.example.com/doc/#Comment" contains the property descriptions.
{
"#context": "http://www.w3.org/ns/hydra/context.jsonld",
"#id": "http://api.example.com/doc/#Comment",
"#type": "Class",
"title": "The name of the class",
"description": "A short description of the class.",
"supportedProperty": [
... Properties known to be supported by the class ...
{
"#type": "SupportedProperty",
"property": "#property", // The property
"required": true, // Is the property required in a request to be valid?
"readable": false, // Can the client retrieve the property's value?
"writeable": true // Can the client change the property's value?
}
]
}
A supported property can have an rdfs:range, which describes the value constraints. This is not yet (2015.10.22.) added to the hydra vocab as far as I can tell, but I don't have time to follow the project. I think you still can use the rdfs:range instead of waiting for a hydra range.
So in your case you could add an item property with a range of http://api.example.com/doc/#Item and so on. I assume you could add the links of the alternatives, something like http://api.example.com/items/, so you could generate a select input box. Be aware that this technology is not stable yet.
So you can send a simple JSON as POST body {item: {id:1}, customer: {id:1}} or something like that, which you generate based on the POST link. The RDF is for the client not for the server. The server can understand the data structure it requires, it does not need RDF. You don't need a dictionary to understand yourself...