Is there a standard url that always shows the latest running build of a particular pipeline?
In this one build Id is needed.
https://dev.azure.com/myOrg/MyPrj/_build/results?buildId=**1029**&view=results
So Always I am forced to go builds list and pick the one on top. Two clicking and two page loads. Would be nice if I can always reach here on one click.
The answer is Yes.
You can go the latest running build of a particular pipeline by clicking below url:
https://dev.azure.com/{org}/{proj}/_build/latest?definitionId={definitionId}
The DefinitionID is id of the pipeline. Yon can get it on the address bar when you click the pipeline.
Update:
Above url is not documented. I just tested it on my pipeline and found it was working.
If it was working in your case, You can click this url https://dev.azure.com/{org}/{proj}/_build?definitionId={definitionId} to go to the pipeline history page. But you will have to manual pick the one on top in this way.
You can also submit a use voice for this standard url to microsoft development team. Hope they add this to azure devops pipeline.
Related
In an Azure Devops project, I see all the "Recent" pipeline runs under the Recent tab.
The list includes pipelines not run for 16 months - as well as those run this week, for example.
How do I customise the list to show only those run in the past month (for example)?
NOTES:
I am NOT talking about the lifetime of the releases themselves, which I know can be customised in the Project Properties --> Pipelines.
I do not want to delete the old pipelines - just not see them in the "Recent" list.
It shows 50（default value） pipelines in recent tab according to our backend API test. I am afraid that you can't customise the list to show.
I am wondering why my build pipeline for Azure DevOps is getting practically all the changes instead of just the most recent one?
I only made one change to 1 file, that didn't have an associated work item. This is what the change looks like. As you can see I have only changed one file. So why is it detecting all the changes?
I thought maybe it was because I didn't have this option enabled.
But even with that option enabled on a pipeline setup the EXACT same way all the changes are still pulled. Am I missing something subtle here?
There's an option on the pipeline to automatically link work items that are completed in a run.
You can edit the Pipeline and in the settings, tick Automatically link work items included in this run. You can pick * for all branches, or a specific branch.
Not sure what you did for your pipeline. Every time you change the files of repos for pipeline and then re-run the pipeline, it lists the changes for each build for the current project. This depends on how many changes you have made to the repo project since the last pipeline.
The below shows:
Then, click into the latest pipeline, and that is true, it will list all changes compared to the previous pipeline.
Click into it and you could get the detailed every single change.
UPDATE: I think this question was based on a fundamental misunderstanding. When creating the build pipeline definition, I would pick the saved service connection ("GitHub-iQmetrixService" in the screenshot), and then later Azure DevOps would continue to prompt for access to my personal account. This made me think that the build pipeline was linked to my personal account somehow, such that if my account is ever in the future gone or otherwise unable to access the repository, the build pipeline would stop working.
As far as I now understand, this is not the case. The build pipeline definition itself is in fact associated with the service connection, and the reason that Azure DevOps prompts for my personal login is because the integrated YAML editor is going to want to make commits back to the repo, and those commits need to happen "as me". When co-workers go to the pipeline editor, they too are prompted for their personal login.
I'm still a little bit nervous about this understanding, because I can't see anything in the UI that shows what service connection Azure DevOps is using primarily to process the build pipeline, nor can I see any way to change it should that ever be necessary.
When creating a new Build Pipeline, if I tell Azure DevOps that my repository is in GitHub, I am immediately redirected to GitHub to authorize access to my personal GitHub account (to which I have an ambient login). If I instead pick "Other Git", then the next step in the flow lets me say that the source is GitHub, at which point the screen says:
This authorization, set up by someone else in my organization, works just fine, and I can view all of the organization's repositories and set up a new pipeline. But then, if I close the window and try to re-open the pipeline editor, I am immediately redirected once again to the GitHub page to authorize access to my personal account. Editing the pipeline created based on the "GitHub-iQmetrixService" connection does not use the connection and instead wants to establish a new connection based on whatever individual accounts I have access to.
How can I edit the pipeline without creating a connection to the repository that is linked to my own personal account?
As work around, you can take advantage of the browser sessions and cookies.
Configure the browser to let it retain and keep the session. And do not clear the session and cookie data once you close the browser.
For me, I am using Edge. So, I go Settings -> Privacy and Security -> Choose what to clear, then disable the option
After configure this, I do not need input my account, password and Verification code again while I close the windows, re-open and re-edit the pipeline,
If you want to make some configuration changes on this pipeline, please go right corner-> three dots, and choose the Triggers.
After located to the Triggers page, please change to YAML tab.
Then you can do the modified on this pipeline
To provide some clarity, it appears what's going on here is that for YAML build definitions, Azure DevOps doesn't actually go to the build pipeline definition editor when you select "Edit". The YAML text editor it takes you to is in place of the build pipeline definition editor. But, the definition editor can still be reached. #Merlin Liang - MSFT's answer provides (after the horizontal rule) the steps to take to do this. I didn't understand why those steps, though. I created the following graphic to explain specifically the aspect that wasn't clear in my head:
I'm currently using AppCenter to Test my Xamarin app. The complete suite is being run at night. But I'm currently looking for a way to make this part of my CI builds to introduce an extra quality gate before features get merged.
However, we would need to slim down the amount of tests that need to be run otherwise this would become unmanageable. For this we can specify categories on our App Center test build step. When queued manually I'm able to specify the categories, however when we make this CI Build part of a branch policy and use a manual trigger for our build validation we are unable to specify the categories as we don't get the popup when queuing.
Any suggestions on how to adres this issue differently?
Seems you want to set build variables in pull requests when you queue the build under policies.
Unfortunately, this could not be achieved by now. It will not pop up the dialog when you queue the build. There has been a related uservoice, you could vote up and follow it, TFS PM will kindly review your suggestion.
Allow Setting Build Variables in Pull Requests
https://developercommunity.visualstudio.com/idea/365725/allow-setting-build-variables-in-pull-requests.html
The only workaround for now is editing the build definitions and add the variable under variables directly, then queue again. You could clone the original build definition first.
I'm trying to execute a bit different build steps in VSTS based on type how build was started: automatically or manually.
I'm especially interested in accessing that information from powershell script. But so far was not able to find suitable solution or workaround.
Did someone faced similar requirement before? How did you solved it? I would appreciate your help!
Seems you want to know whether the project build is happening through TFS triggered build or manually triggered build.
There is no such feature for vnext build for now. About this , you could submit your uservoice to this link, TFS Product Team is listening to your voice there.
As a workaround either to use two build definitions through different version patterns or manually add a specifical tag after a manually build finished. Through using tags to set some labels on the build to distinguish manual and automatic builds. But this is a manual action, it would be better if we can do this automatically.
It seems to be I've managed to find an option that allows to determine wherever build was triggered automatically or manually.
All builds started manually have actual user in $Env:BUILD_QUEUEDBY variable, while automatic builds have system account there. My value was [********]\Project Collection Service Accounts.
I don't know how reliable it is, but for me so far following code did the job:
# Identifying who triggered the build
$OwnerId = $Env:BUILD_QUEUEDBY;
$OwnerId = $OwnerId.ToUpper();
if ($OwnerId.EndsWith("PROJECT COLLECTION SERVICE ACCOUNTS"))
{
Write-Host "Build was triggered automatically. Resulting files considered 'BETA'"
}
else
{
Write-Host "Build was triggered manually. Resulting files considered 'STABLE'"
}