I am trying to update release scoped variables for the existing release using API.
Issue: receiving exception on API call (PUT https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/releases/{releaseId}?api-version=5.1-preview.8)
Invoke-RestMethod : {"$id":"1","innerException":null,"message":"You are using an old copy of release. Refresh your copy and try
again.","typeName":"Microsoft.VisualStudio.Services.ReleaseManagement.Data.Exceptions.InvalidRequestException,
Microsoft.VisualStudio.Services.ReleaseManagement2.Data","typeKey":"InvalidRequestException","errorCode":0,"eventId":3000}
Steps to Recreate:
Create release from existing release definition without triggering any stages on the web portal: https://vsrm.dev.azure.com
Get release details by invoking:
GET https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/releases/{releaseId}?api-version=5.1-preview.8
Update response from step 2 with value for release scoped variable with "allowOverride" set to true
Update response from step 2 with "modifiedOn" property set to later date than existing value
Update response from step 2 with "definitionSnapshotRevision" property set to existing value incremented by 1
Update release by invoking:
PUT https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/releases/{releaseId}?api-version=5.1-preview.8
and providing json generated in steps 2-5
Observe above mentioned exception
I have updated 2 release properties (modifiedOn and definitionSnapshotRevision) because I saw that these values change if I update a release using web site (https://vsrm.dev.azure.com). It seems that I am still missing something. I cannot find any guidance in documentation on how to properly update a release deployment.
I used "Invoke-RestMethod" powershell commandlet to get release metadata. This commandlet returns custom ps object which I then updated, converted to json using "ConvertTo-Json" commandlet and provided in the body of the PUT HTTP request to DevOps to update the release. The issue is that Powershell serialization/de-serialization process of json does not result to the original json.
For example this json property:
"preDeploymentGatesSnapshot": {
"id": 0,
"gatesOptions": null,
"gates": []
},
becomes:
"preDeploymentGatesSnapshot": "#{id=0; gatesOptions=; gates=System.Object[]}"
After I used correct json in the body of the PUT request in the API call:
https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/releases/{releaseId}?api-version=5.1-preview.8
the release got successfully updated.
Related
We have an Azure pipeline building a static site. When there is a change in a content repository the site needs to be rebuilt. For that, we're using webhooks and Azure DevOps API. The request to queue the build is very simple and is illustrated for example here.
What I don't like about this is that int the build listing it says "Manually triggered for person XY", where the person XY is the one who generated the credentials used in the API request. It seems quite confusing because any API request seems strange to be labeled as "manually requested". What would be the best way how to achieve more semantically correct message?
I've found there is a reason property which can be sent in the request. But none of the values seems to represent what I want and some of them do not work (probably need additional properties and there is no documentation for that).
Based on my test, when you use the Rest API to queue a build and set the build reason, the reason could be shown in the Build(except：batchedCI and buildCompletion).
Here is the Rest API example:
Post https://dev.azure.com/Organization/Project/_apis/build/builds?api-version=4.1
Request Body:
{
"definition": {
"id": 372
},
"reason":"pullRequest"
}
The value : checkInShelveset individualCI pullRequest schedule could show their own names.
The value: manual and none could show manually trigger.
The other value(e.g. All, userCreated) will show Other Build Reason.
For the value: batchedCI and buildCompletion.
BatchedCI: Continuous integration (CI) triggered by a Git push or a TFVC check-in, and the Batch changes was selected.
This means that batch changes are required to achieve this trigger. So it doesn't support to queue build in Rest API .
buildCompletion: you could refer to this ticket This reason doesn't support in Rest API-queue Build.
Note: If you enter a custom value or misspelling, it will always display manual trigger.
In the end, I went with all value and also overriding the person via requestedFor property. This leads to the message "Other build reason", which seems usable to me.
{
"definition": {
"id": 17
},
"reason":"all",
"requestedFor": {
"id": "4f9ff423-0e0d-4bfb-9f6b-e76d2e9cd3ae"
}
}
However, I'm not sure if there aren't any unwanted consequences of this "All reasons" value.
I am in the process of converting some tasks inside numerous task groups we have to different tasks. Instead of doing this by hand I've opted for using Powershell along with the Rest API of Azure DevOps to update the JSON bodies of these task groups and send them to the API. The conversion of the tasks is working fine sofar.
sending a PUT to the rest API in order to update the current task group of the set works but I want to build in some retention / version history if some of the new tasks end up working different than expected. So just blatantly updating the existing Task Group under the same major version is not an option.
the UI of Azure DevOps has functionality where you can save changes to a task group as a 'draft' and then publish this draft as either a completely new version (major version + 1) or as a preview
I went ahead and attempted to send a PUT to the Rest API and upticking the major version using the following URI:
PUT https://dev.azure.com/{organization}/{project}/_apis/distributedtask/taskgroups/{taskGroupId}?api-version=5.1-preview.1
Along with the settings:
JSONObject.version.major = $currentversion + 1
JSONObject.preview = true
This results in the API returning an error saying:
Invoke-WebRequest : {"$id":"1","innerException":null,"message":"Task group {TaskGroupID} not found.","typeName":"Microsoft.TeamFoundation.DistributedTask.WebApi.MetaTaskDefinitionNotFoundException, Microsoft.TeamFoundation.DistributedTask.WebApi","type
Key":"MetaTaskDefinitionNotFoundException","errorCode":0,"eventId":3000}
I then went ahead and tried to see if I could create a draft version. When sending a POST to the following URI i was able to create a draft:
POST https://dev.azure.com/{organization}/{project}/_apis/distributedtask/taskgroups?api-version=5.1-preview.1
using the following settings in JSON:
JSONObject.version.major = 1
JSONObject.version.istest = true
JSONObject.id = $null
JSONObject.parentDefinitionId = {TaskGroupID of the taskgroup of which i am trying to make a draft}
This nets in a new Task group in draft state which i am able to view in the UI and modify and publish (with or without preview). When i export the created JSON from UI from a manually made draft and compare it versus the one coming from powershell i see no differences.
This last step is where I am stuck. I can't seem to convert the created draft into a new version of the {parentdefintionid} task group. I've tried the following settings:
Calling the taskgroupid URI of the parent with put while a draft is available
JSONObject.version.major = $currentversion + 1
JSONObject.version.isTest = false
JSONObject.preview = true
Removing ParentDefinitionID from JSONObject
is resulting in the same error where it states that it cannot find the ID of the parent:
Invoke-WebRequest : {"$id":"1","innerException":null,"message":"Task group {TaskGroupID} not found.","typeName":"Microsoft.TeamFoundation.DistributedTask.WebApi.MetaTaskDefinitionNotFoundException, Microsoft.TeamFoundation.DistributedTask.WebApi","type
Key":"MetaTaskDefinitionNotFoundException","errorCode":0,"eventId":3000}
The same is valid with above settings and calling the draftID URI
When i try to call the draftID task group URI with the following settings :
JSONObject.version.major = $currentversion + 1
JSONObject.version.isTest = false
JSONObject.preview = true
JSONObject.id = $ParentDefinitionID
Removing ParentDefinitionID from JSONObject
it results in the following error:
Invoke-WebRequest : {"$id":"1","innerException":null,"message":"The request specifies task group ID {parentTaskGroupID} but the supplied task group has ID {DraftTaskGroupID}.","typeName":"Microsoft.TeamFoundation.DistributedTask.WebApi.Task
GroupIdConflictException, Microsoft.TeamFoundation.DistributedTask.WebApi","typeKey":"TaskGroupIdConflictException","errorCode":0,"eventId":3000}
i've checked the actual JSONObject to an export of a published Task Group in UI and they match exactly so i'm quite positive that content is not the issue here.
The MS documentation is seriously lacking on API usage so i'm really in the dark there hoping to find some clues / solution here
Seems you were updating a already exist task group in Azure DevOps.
If you incremented the revision property to be 1 higher than what is currently deployed.
You need to submit the JSON with the same revision property that the server has.
I am trying to get existing manual test steps from ALM using the below REST API
https://almoctane-apj.saas.microfocus.com/api/shared_spaces/shared_space_id/workspaces/workspace_id/tests/manual_test_id/script
but I get the following result.
{
"creation_time": "2020-01-16T14:36:52Z",
"test_version": "{\"id\":1035,\"type\":\"test_version\"}",
"version_stamp": 5,
"last_modified": "2020-01-17T09:38:20Z",
"script": "- Open Browser\n- Type Username\n- Type PAssword\n- Submit\n- #2012 Call <ReqTest1>\n- Login using <Username> and <Password>\n- ?isLoginSuccesfull"
}
Is there a way to get existing manual test steps with details(like id, description, etc) through REST API?
i know that is six month late , but you could try calling entity test
http://URLdirection:PORT/api/shared_spaces//workspaces//tests?fields=id,latest_version&query=%22(id%3D%27yourTestId%27)%22
and once you have latest version you can call entity test_versions with attribute last_version that you got in the last request
http://URLdirection:PORT/api/shared_spaces//workspaces//test_versions?fields=id,script&query=%22(id%3D%27yourVersionID%27)%22
and there you will get the steps , also you have to consider that before doing this you need to have stablished connection (requested cookies, etc...) for avoiding 403 error and properly setted headers and parameters for the request. and if you're using microfocus library i didn't find any direct call for test_versions entity
EDIT: also you can request to http://URLdirection:PORT/api/shared_spaces//workspaces//test//script
I am trying to retrieve a value from a HTTP web service call in sharepoint designer. This should be simple. the Rest query is simple, and always returns only a single value:
https://Site.sharepoint.com/sites/aSiteName/_api/web/lists/getByTitle('MyListTitle')/items/?$select=Title&$top=1
In the Sharepoint Designer workflow, I'm setting the required Accept and Content-type header to the value of "application/json;odata=verbose
I am unable to get the value of the "Title" field that is returned by the call.
when I execute the REST query in the browser, I get the following data returned:
{"d":{"results":[{"__metadata":{"id":"af9697fe-9340-4bb5-9c75-e43e1fe20d30","uri":"https://site.sharepoint.com/sites/aSiteName/_api/Web/Lists(guid'6228d484-4250-455c-904d-6b7096fee573')/Items(5)","etag":"\"1\"","type":"SP.Data.MyListName"},"Title":"John Doe"}]}}
I've tried dozens of variations of the dictionary 'query', but they always return blank.
I'm using the 'get an item from a dictionary' action in SP Designer, using item name or path values like:
d/results(0)/Title
d/Title
d/results/Title
and literally dozens of other variations - but it always returns blank.
I'm writing the raw response from the webRequest to the list for debugging, and it shows the value like this:
{"odata.metadata":"https:\/\/site.sharepoint.com\/sites\/aSiteName\/_api\/$metadata#SP.ListData.MyListTitle&$select=Title","value":[{"odata.type":"SP.Data.MyListTitle","odata.id":"616ed0ed-ef1d-405b-8ea5-2682d9662b0a","odata.etag":"\"1\"","odata.editLink":"Web\/Lists(guid'6228d484-4250-455c-904d-6b7096fee573')\/Items(5)","Title":"John Doe"}]}
I must be doing something simple that is wrong?
Using "d/results(0)/Title" is right. Check the steps in article below to create a workflow.
CALLING THE SHAREPOINT 2013 REST API FROM A SHAREPOINT DESIGNER WORKFLOW
It working fine in my test workflow.
I faced the exact same issue. In my case the reason was that in the API call, the header was not set properly.
As you would have noticed many times, that if you type the variables inline when creating the "Call Http Web service" action, those might not get set properly. The surest way is to open the properties and set from there. In my case when i opened the properties i found that RequestHeaders was not set. Once i set it from there, i got the desired results.
Hope this helps to someone in future, this question being unanswered till now!!
tried dump those json called from sharepoint workflow into a list. Sometimes you'll get a different format than when you called that from browser. I experienced this issue when calling API projectserver (project online). When I called it using servistate (chrome extension) it returns d/results, but when I dump the value into the list I got value and yet I used same request header value.
So as a part of some tests to automatically accept / merge successful pipelines in our git repository i was running some tests to flag the "merge when pipeline succeeds" feature when the pipeline is still running:
So this button is available when the pipeline is still running and will convert to a green 'Accept merge' button when the pipeline succeeds:
(note that this picture was taken afterwards not to confuse the use-case)
additionally i have set these general settings:
So when checking the Gitlab API Documentation it says i should use the following endpoint:
PUT /projects/:id/merge_requests/:merge_request_iid/merge
when using the parameter ?merge_when_pipleline_succeeds=true it should flag the button.
However when i call this endpoint when the pipeline is still running (i built in a wait for 10 mins while testing this) i get the following result:
i am getting a Method Not Allowed. My assumption is that the endpoint i am using is correct because otherwise i would've gotten a bad request / not found return code.
when checking the gitlab merge request i am seeing that indeed the flag is not set to true:
However, when i manually click the blue button the mergerequest looks like this:
Also if i let the pipeline finish and then proceed to call the merge api (w/ or w/o the merge when pipeline succeeds flag) it will accept the merge. It just does not work when the pipeline is running (which is odd because even the button itself only shows when the pipeline is running)
so i am wondering what I am doing wrong here.
I am using a Powershell module to call the GitLab API. The Accept part of the module is not official and was made by myself because i found this feature missing.
I am using the same credentials for the API w/ a personal access token to authenticate to the API. Other functionality of the API work with this token like creating merge requests, retrieving status of a current MR and accepting a MR when the pipeline is finished.
I have tried the following variants :
Use the V3 api with merge_when_build_succeeds=true --> nets the same
result
Uncheck the "Only allow merge request to be merged if the
pipeline succeeds" --> nets the same result
Use ID of the merge request instead of IID
use /merge_when_pipeline_succeeds instead of ?merge_when_pipeline_succeeds=true
use True instead of true --> nets the same result
I get a similar issue with the python-gitlab library on v4. It works sometimes when I use:
mr.merge(merge_when_pipeline_succeeds=True)
Where mr is a ProjectMergeRequest object. However, if the MR has a merge conflict in it I get that 405 Method Not Allowed error back.
My best guess is to see if I can apply logic before calling mr.merge() to check for problems. Will update this if that works.
UPDATE: Looks like there is no feature to check for conflicts as of today. https://gitlab.com/gitlab-org/gitlab-ce/issues/41762
UPDATE 2: You can check merge_status when looking at the MR information, so either that attribute or an exception then mr.merge() fails would let you identify when it won't work.