I can enable notifications for completed builds and failed builds but is there a way to
have notification for fixed builds?
That would mean builds that failed in the previous commit but does not fail in the most current one.
According to the About notifications documentation, there are only notifications for completed builds and failed builds.
Looks like the closest we can get out of the box would be to create a Service hook to notify a Service of a successful build.
A solution closer to your needs would be to build your own API, call that from the Service hook and determine if the build has been fixed there.
Related
I'm doing Visual Studio builds on a self hosted agent, which are currently being triggered by the Continuous Integration setting in an Azure Devops pipeline.
When a build completes, it shows: Triggered by Microsoft.VisualStudio.Services.TFS
It also shows the repository, branch and revision number.
However, it is expected it would show Triggered by , If not showing the correct Azure Devops user, at least showing the Subversion user name, that would be something.
There was an expectation it would be possible to send email notifications to the user of the commit. (Not fool proof that they caused the problem, but the most convenient way to give the responsibility to somebody to make sure any build error gets resolved)
Does anybody know if a solution exists?
In both Classic and yaml pipelines, you can specify a condition for a pipeline step. If you want it to run when the pipeline fails, it will be condition: failed() (in yaml), or Control Options -> Run this task -> Only when a previous task has failed (in Classic). Alternativel, you can check Agent.JobStatus variable.
there's no predefined variable for current committer, but you can easily determine the last commit's author by using svn command, then log it. (any other version control system will have its own CLI that should allow it).
In yaml, it could look like this (using git instead of svn):
steps:
... (your build)
- bash: |
author=`git log -1 --pretty=format:'%ae'` # get last commit author from git
echo "last commiter: $author"
# TODO: send email or other kind of notification
condition: failed()
In classic one:
You are using wrong tool for you task. CI build will be triggered after changes was committed to branch. In that case it is not possible to fix those changes. As a result you will have history where a lot of revisions are not stable.
It might be more suitable for you to use PR policy build. It is designed to validate incoming changes so target branch will be always stable and ready to some deploy. In this case, policy build will be triggered by PR creator so he will be informed about it's result. That can be configured in personal notification settings.
In the end I couldn't Continuous Integration triggers to reliably work. They would always stop working after a short time. I'm surprised I have ran into so many issues with this, but I guess it just isn't that well supported.
Instead, now, I am queue the build via an svn post-commit hook which uses the azure devops REST API.
the REST API has setting, requestedFor":{"id":""}, where you can add the user id (which I also needed a rest api command to find)
A lot of messing around to get to this point, for a feature I expected to 'just work', hopefully this keeps working
With the classic build pipelines and classic triggers, it was easy enough to track builds that were triggered by completion of other builds by just polling for builds requested by the same user.
Now, with resource triggers, the requested by property switching to the build service account instead of the original author of the triggering commit.
I have been going through the documentation to try and find another way to see triggered builds from the original build ID but have not found anything.
There is an "Associated Pipelines" tab on the build summary page that at least has the pipelines containing the triggered builds, but I cannot find anything to get that by API either.
According to your description, you can first call the REST API to get all the running build pipelines in the definition, and then use the powershell script to loop check the id in the parameter triggeredByBuild in the request body in the specific build so that you can see triggered builds from the original buildId.
Note: The id marked in the attachment is the original buildId that triggered another build pipeline.
Is it possible to target the previous build in a custom condition?
What I try to accomplish:
Post a message to Slack when build fails (this is easy)
Post a message to Slack when a build changes status from failed to success (I don't want all successful builds posted to Slack, only the first one after a failed build)
No, it's not able to target the previous build in a custom condition. Custom condition can only target in the same build. You can add a task to use REST API checking the previous build result and current build result, and determine whether to post a message to Slack.
One way would be to retrieve the latest build and read the build status using the Rest API. The Slack message would then be conditional on previous BuildResult == succeeded & current BuildResult == failed.
You can get information about the previous build using the azure-devops rest API here:
Azure DevOps Services Rest API GET Builds List
We are migrating from old XAML build definition to new TFS 2015 build. In old we have gated-check in that is working fine. In new one we have such option on "Triggers" tab. However I want use commit ID that trigger build.
The variable $(Build.SourceVersion) is responsible for this, but for gated-check in it is not being set.
It looks right, because commit was not accepted by TFS yet.
The question is how to grab this commit ID either during gated-check in or following CI ?
Should I create just another build for gated check-in that just compile our solution and only if succeeded will trigger CI ?
There is no way to get the changeset id that hasn't checked in during gated check-in. Please check the screenshot below, checking in gated changes is in the very last step in the build process, which can't be controlled. After the build completes, the variable $(Build.SourceVersion) will update automatically. So we are not able to get the changeset id that hasn't checked in until the build completes.
You would need to use TFS REST API to get the build that has completed, then fetch the "sourceVersion":
GET http://{instance}/DefaultCollection/{project}/_apis/build/builds/{buildId}?api-version={version}
So far, I end up with not clean workaround, but it were accepted by our management.
I created two build definitions: one for gated-check in, one for CI.
Once someone checked in something gated check-in fires. If it completed successfully, CI build would be triggered. Please note corresponding checkbox on UI:
This is not so clean solution, but it works for me.
As far as I can tell from the current interface provided for setting up e-mail alerts for builds in visual studio team services, there is no way to set a condition on the status of the previous build.
I expect this is relevant to many development teams as teams will typically have a build server churning out builds frequently throughout the day and will want e-mail alerts of a failure. Following a failed build, it is useful to also have a success email for the next build. However, you don't want an e-mail for every successful build as you are only interested in this after a failure, the rest is just white noise.
So is there any way to create alerts conditional upon the previous build in visual studio team services, or more specifically to just get success e-mails after a failed build?
There isn't any way to do this with the alerts feature in VSTS for now. You can submit a feature request on VSTS User Voice.
And the alternative way to achieve this feature would be create an application/service to track the build event and send out email notification base on the build status you want via VSTS Rest API or TFS API.