BUG: VSTS Release definition Rest API PUT call removes phases - azure-devops

I am trying to Get a RD and then call a PUT operation on the release object after updating some Variables in it.
The PUT operation is successful, the variables get updated in the RD, but all the other phases in the environment gets removed, except the 1st phase.
My RD has only one env I have not tried with more than one ENV for this operation.
Please suggest how can I update the RD through Rest call without loosing data.
URLs tried for GET:
The below URL don’t give Deployphases but PUT is successful with deleted phases
https://xxxxxxx.vsrm.visualstudio.com/xxxxxxx/_apis/Release/definitions/2016?api-version=4.1-preview.1
The below URL gives Deployphases but PUT fails with error that Deployphases should not be used rather Deploy step should be used.
https://xxxxxxx.vsrm.visualstudio.com/xxxxxxx/_apis/Release/definitions/2016
URLs tried for PUT:
behavior is same for both the URLs
https://xxxxxxxx.vsrm.visualstudio.com/xxxxxxx/_apis/Release/definitions?api-version=4.1-preview.1
https://xxxxxxxx.vsrm.visualstudio.com/xxxxxxx/_apis/Release/definitions/2016?api-version=4.1-preview.1

It's not a bug, you should use api-version=4.0-preview.3:
https://xxxx.vsrm.visualstudio.com/xxxx/_apis/Release/definitions?api-version=4.0-preview.3

Related

Can I automatically add comments to Azure DevOps PR based on code changes

Occasionally in our codebase we need to use an //eslint-disable to bypass a styleguide rule on a line. I would like to somehow automatically add a comment on each new instance of that in PRs, requiring the developer to explain why they bypassed the styleguide.
I've found this question referencing how to create a comment programmatically, but what I'm not sure how to do is identify the new code and parse it for a certain piece of text, then add comments on those particular lines where the text was found.
This is one of the approaches to ingest scripts & achieve what you want, wherein Expected outcome is:
On every pull request, a pre build validation pipeline kicks off & adds comments on the PR.
Create a script (powershell/python/bash) with following logic:
Find file names in the given branch which contains //eslint-disable
In the files above (1.), get the location/line number of //eslint-disable
Foreach file.LineNumber (wrote like that just for representation): add comment on file.LineNumber using Pull Request Threads API. See line parameter
Create a pipeline containing above script & add that pipeline as build validation or if you have an existing build validation process, add these scripts as tasks in that pipeline.
Hope this helps :)

How to reset VSTS counter?

We have a need to reset VSTS counter. I do not see any way to do this through UI. There is a way to do it by directly invoking reset build counter REST API, but in order to do this, you need to know the counter id, which you should be able to find out by invoking get a definition REST API. Unfortunately, no matter what I do get a definition call does not return build definition counter.
What am I missing?
Scott Dallamura from Microsoft wrote this thread:
the counters feature was experimental and removed back in March of
this year. I'm not sure how it even got into the documentation, but
I'll make sure it gets cleaned up.
I also didn't success to get the counterId in an API call.
At workaround, you can reset the revision of the build number if you change the build definition name, you can just add/remove a character.
Instead of trying to reset the counter variable, you could create a new variable with a GUID prefix.
This solution creates duplicate counters which might not be ideal but this gives you the ability to revert back to the previous counter values, if necessary.
Please see the following YAML code snippet
variables:
...
#Change this Guid if you require a reset seed on the same value.
resetCounterGuid: 'efa9f3f5-57fb-4254-8a7a-06d5bb365173'
buildrevision: $[counter(format('{0}\\{1}',variables['resetCounterGuid'],variables['YOUR_DEFINED_VARIABLE']),0)]
...

Unable to run experiment on Azure ML Studio after copying from different workspace

My simple experiment reads from an Azure Storage Table, Selects a few columns and writes to another Azure Storage Table. This experiment runs fine on the Workspace (Let's call it workspace1).
Now I need to move this experiment as is to another workspace(Call it WorkSpace2) using Powershell and need to be able to run the experiment.
I am currently using this Library - https://github.com/hning86/azuremlps
Problem :
When I Copy the experiment using 'Copy-AmlExperiment' from WorkSpace 1 to WorkSpace 2, the experiment and all it's properties get copied except the Azure Table Account Key.
Now, this experiment runs fine if I manually enter the account Key for the Import/Export Modules on studio.azureml.net
But I am unable to perform this via powershell. If I Export(Export-AmlExperimentGraph) the copied experiment from WorkSpace2 as a JSON and insert the AccountKey into the JSON file and Import(Import-AmlExperiment) it into WorkSpace 2. The experiment fails to run.
On PowerShell I get an "Internal Server Error : 500".
While running on studio.azureml.net, I get the notification as "Your experiment cannot be run because it has been updated in another session. Please re-open this experiment to see the latest version."
Is there anyway to move an experiment with external dependencies to another workspace and run it?
Edit : I think the problem is something to do with how the experiment handles the AccountKey. When I enter it manually, it's converted into a JSON array comprising of RecordKey and IndexInRecord. But when I upload the JSON experiment with the accountKey, it continues to remain the same and does not get resolved into RecordKey and IndexInRecord.
For me publishing the experiment as a private experiment for the cortana gallery is one of the most useful options. Only the people with the link can see and add the experiment for the gallery. On the below link I've explained the steps I followed.
https://naadispeaks.wordpress.com/2017/08/14/copying-migrating-azureml-experiments/
When the experiment is copied, the pwd is wiped for security reasons. If you want to programmatically inject it back, you have to set another metadata field to signal that this is a plain-text password, not an encrypted password that you are setting. If you export the experiment in JSON format, you can easily figure this out.
I think I found the issue why you are unable to export the credentials back.
Export the JSON graph into your local disk, then update whatever parameter has to be updated.
Also, you will notice that the credentials are stored as 'Placeholders' instead of 'Literals'. Hence it makes sense to change them to Literals instead of placeholders.
This you can do by traversing through the JSON to find the relevant parameters you need to update.
Here is a brief illustration.
Changing the Placeholder to a Literal:

Cleanup for running spec files in series in Protractor

I am running multiple specs using a Protractor configuration file as follows:
...
specs: [abc.js , xyz.js]
...
After abc.js is finished I want to reset my App to an initial state from where the next spec xyz.js can kick off.
Is there a well defined way of doing so in Protractor? I'm using Jasmine as a test framework.
You can use something like this:
specs: ['*.js']
But I recommend you to separate the specs with a suffix, such as abc-spec.js and xyz-spec.js. Thus your specs will be like this:
specs: ['*-spec.js']
This is done to avoiding the config file to be 'run'/tested if you put the config file in the same folder as your tests/spec files.
Also there is downside that the test will be run in 0 -> 9 and A -> Z order. E.g. abc-spec.js will run first then xyz-spec.js. If you want to define your custom execution order, you may prefix your spec files' names, for instance: 00-xyz-spec.js and 01-abc-spec.js.
To restart the app, sadly there is no common way (source) but you need to work around to achieve it. Use something like
browser.get('http://localhost:3030/');
browser.waitForAngular();
whenever you need to reload your app. It will force the page to be reloaded. But if your app uses cookie, you will also need to clean it out in order to make it completely reset.
I used a different approach and it worked for me. Inside my first spec I am adding Logout testcase which logouts from the app and on reaching the log in page, just clear the cookie before login again using following:
browser.driver.manage().deleteAllCookies();
The flag named restartBrowserBetweenTests can also be specified in a configuration file. However, this comes with a valid warning from the Protractor team:
// If [set to] true, protractor will restart the browser between each test.
// CAUTION: This will cause your tests to slow down drastically.
If the speed penalty is of no concern, this could help.
If the above doesn't help and you absolutely want to be sure that the state of the app (and browser!) is clean between specs, you need to roll out your own shellscript which gathers all your *_spec.js files and calls protractor --specs [currentSpec from a spec list/test suite].

TeamCity REST API get list of pending changes

Is there a REST API endpoint to get a collection of changes that are pending for a build in TeamCity?
We have the build set to manual and it is triggered outside TeamCity and would like to show a bullet point list of commits that'd be in that build.
In the user interface you can see this under the "Pending Changes (X)" tab.
I can't find any examples of doing this and the closest I've found is:
http://<server>/httpAuth/app/rest/changes/buildType:<build type id>
This seems to return the last change though.
Anyone done this before?
I just found a working solution thanks to this question. I'll show it here in case other people are looking for a full solution :
You need to know the buildTypeId of the build on which you want to get the pending changes. In this case lets say buildTypeId=bt85
1
http://<server>/httpAuth/app/rest/buildTypes/id:bt85/builds/
// Get the last build from the XML returned.
// Lets say last build id = 14000
2
http://<server>/httpAuth/app/rest/changes?build=id:14000
// The newest change returned is the one you need.
// Lets say newest change id = 15000
3
http://<server>/httpAuth/app/rest/changes?buildType=id:bt85&sinceChange=15000
// You're now looking at the pending changes list of the buildType bt85
My eventual solution in a work around kind of way is to:
Find the latest change ID from my database of builds outside of TeamCity (I guess you could query the TeamCity API to find the last successful build and pull it from there)
Then call:
http://<server>/httpAuth/app/rest/changes?buildId=id:<build id>&sinceChange=id:<last change id>
Then fetch each individual change from that list.
A bit of a workaround but I couldn't see anyway otherwise to get the list of pending changes.