I have a bamboo plan that runs on every commit to a github pull request. In that bamboo plan there are a few custom variables on it such as Git Sha, Github Pull Request Number, etc.
I want to write a script that stops all previous builds (multiple concurrent builds) that have the same pull request number -- same custom variable value.
The reason for this is that if someone makes a quick change to their pull request (comments on the review, etc) that we don't have multiple builds running when only the last one is necessary.
I know it is possible to stop a build with a rest request, but I need a way to be able to get all running builds with custom variable value = 27 (pull request number). Once I know this, I can proceed.
At the time of writing, the REST API documentation doesn't list any method of querying the running builds for a particular build variable.
A solution would be to create your own plugin for Bamboo that exposes a REST service that does this query for you, but I don't know which of the Java APIs you would need to use in order to perform that query.
Here is how I solved this ...
You can call /rest/api/latest/result/<plankey>-latest?includeAllStates=true&expand=variables where plankey is the key for the specific Bamboo build plan.
You then loop through the results you get back, looking for a lifeCycleState value that is not Finished, and a custom variable with the desired name to see if it matches the PR number you have.
Related
Is there a way to list multi-stage automated test run results, on a per stage basis, using Azure DevOps GET Api?
If you call /_apis/pipelines/{pl_def_id}/runs , you will get a list of builds from a defined pipeline.
If you get the latest build from that list, and if that build is multi-stage, the test runs do not seem to be hierarchically beneath the latest build, as you might expect.
To get the test runs, when you call /_apis/test/runs, ( https://learn.microsoft.com/en-us/rest/api/azure/devops/test/runs/list ) it only can give you the list of ALL runs within your org+project. There does not seem to be an id that references the multi-staged "test runs" tasks back to the "parent pipeline" having a "build id".
I looked at timeline queries, but they don't seem to have that info either.
HOW can this be achieved with ADO GET api? Am I overlooking the answer?
There is a parameter buildUri in the run list API as you mentioned the doc:Run List
You can use buildUri to get test runs from a specified build of pipeline.
However, if you want to get multi-stage automated test run results on a per stage, I’m afraid that there’s no supported API to achieve it.
You may submit a feature request at website below:
feature request
I've been looking at organisation and project settings but I can't see a setting that would prevent users from creating work items in an Azure DevOps project.
I have a number of users who refuse to follow the guidelines we set out for our projects so I'd like to inconvenience them and the wider project team so that they find it better to follow the guidelines than not - at the moment we've got one-word user stories and/or tasks with estimates of 60-70 hours which isn't reflective of the way that we should be planning.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
The Azure DevOps Aggregator project allows you to write simple scripts that get triggered when a work item is created or updated. It uses a service hook to trigger when such an event occurs and abstracts most of the API specific stuff away, providing you with an instance of the work item to directly interact with.
You can't block the creation or update from, such a policy, Azure DevOps will inform the aggregator too late in the creation process to do so, but you can revert changes, close the work item etc. There are also a few utility functions to send email.
You need to install the aggregator somewhere, it can be hosted in Azure Functions and we provide a docker container you can spin up anywhere you want. Then link it to Azure DevOps using a PAT token with sufficient permissions and write your first policy.
A few sample rules can be found in the aggregator docs.
store.DeleteWorkItem(self);
should put the work item in the Recycle Bin in Azure DevOps. You can create a code snippet around it that checks the creator of the work item (self.CreatedBy.Id) against a list of known bad identities.
Be mindful that when Azure DevOps creates a new work item the Created and Updated event may fire in rapid succession (this is caused by the mechanism that sets the backlog order on work items), so you may need to find a way to detect what metadata tells you a work item should be deleted. I generally check for a low Revision number (like, < 5) and the last few revisions didn't change any field other than Backlog Priority.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
I am afraid there is no such out of setting to do this.
That because the current permission settings for the workitem have not yet been subdivided to apply to the current scenario.
There is a setting about this is that:
Project Settings->Team configuration->Area->Security:
Set this value to Deny, it will prevent users from creating new work items. But it also prevent users from modify the workitem.
For your request, you could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions.
This may really be more a QA question. I'm sort of hamstrung in my organization, I don't have API access for some of the Azure REST calls. I've got a number of test plans with various suites, and reporting the overall current status in terms of passed, failed, etc. is straightforward.
What I'm not able to do easily is get a historical view of all the runs of a given test case. So I can't seem to easily get a metric that says (as an example) we had to run this test case 12 times before we got a pass. Most of the help I'm seeing online references some great ways to get all test IDs if you have API access, I'm not sure if there's another way outside of it.
There is New Test Plans Page in azure devops Previous Features, which allows you to view the historical test result of a test case.
First you need go to "User setting-->Previous Features of your azure devops and Turn on New Test Plans Page
Then Go to your Test plan-->Go to Execute page-->Click 3dot-->Choose View execution History
Then you will see the historical test results in a new page. You can also filter the execution
history as below highlighted
I want to get releases, which state is only
in progress, but when I send request https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/releases?definitionId={definitionId}&api-version=5.1 to get all releases and see, which field is responsible for release state I see, that all releases have status active.
I thought I must use https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/releases?definitionId={definitionId}&statusFilter=active&api-version=5.1, but that is wrong way for my target task.
What should I use? Thanks you in advance!
That's because you're looking at the wrong API. You need to use the deployments API and specify deploymentStatus for querying the status of deployments.
The API you're using queries the overall status of a given release, not the individual stages. The JSON returned contains information about the stages, but you can't filter the stages based on their current status with that API.
What information are we able to query on a workflow job? Anything regarding a particular build's stage status (succeeded, failed, hasn't reached yet, aborted, etc.)? I see we can interact with the input step using this method, but where can we find what metadata, if anything, can be obtained about our builds?
The REST exported API for builds (…/job/…/…/api/json?tree=…) is not very extensive yet. You can get some information about nodes in the flow graph (steps, and some associated block nodes—the stuff you see in Workflow Steps). It is possible to extract some information about stages from that, albeit not easily. Much more is available from the Java API.