Build Quality Checks - no repository found

[Magnuti]

Context

• Extension: BuildQualityChecks
• Environment: Azure DevOps
• Pipeline type: yaml pipeline

Expected behavior I want BuildQualityChecks to reject any pull request that increases the number of warnings. This should be done by comparing the number of warnings in the build of the current pull request of the feature branch to the number of warnings in the master branch.

The problem I added the Build Quality Checks extension to my Azure Devops project. However, when I add the task no repository is found in the GUI.

I attempted to define the task in a yaml definition instead, with no success. What should be defined in baseBranchRef if I want to compare the pull request to the build in master?

steps:
  - task: BuildQualityChecks@8
    inputs:
      checkWarnings: true
      warningFailOption: 'build'
      # showStatistics: true
      # includePartiallySucceeded: false
      # baseBranchRef: refs/heads/master
      baseBranchRef: $(System.PullRequest.TargetBranch)
    displayName: 'Check build quality'

However, I get this warning: [WARNING] The baseline build could not be found. All policies based on the previous build will pass.

2022-08-25T09:26:08.8058917Z ##[section]Starting: Check build quality
2022-08-25T09:26:08.8068149Z ==============================================================================
2022-08-25T09:26:08.8068419Z Task         : Build Quality Checks
2022-08-25T09:26:08.8068750Z Description  : Breaks a build based on quality metrics like number of warnings or code coverage.
2022-08-25T09:26:08.8069018Z Version      : 8.2.1
2022-08-25T09:26:08.8069165Z Author       : Microsoft
2022-08-25T09:26:08.8069560Z Help         : [[Docs]](https://github.com/MicrosoftPremier/VstsExtensions/blob/master/BuildQualityChecks/en-US/overview.md)
2022-08-25T09:26:08.8069957Z ==============================================================================
2022-08-25T09:26:09.3953176Z Using IdentifierJobResolver
2022-08-25T09:26:09.4575353Z Validating build warnings policy...
2022-08-25T09:26:09.8456009Z Running task warnings analysis...
2022-08-25T09:26:09.8462456Z Counting warnings from tasks:
2022-08-25T09:26:09.8463488Z   - dotnet restore
2022-08-25T09:26:09.8491486Z Waiting for log information of task 'dotnet restore'...
2022-08-25T09:26:18.7195930Z      Running generic task log analysis...
2022-08-25T09:26:18.7204442Z      Total warnings: 0, Filtered warnings: 0
2022-08-25T09:26:18.7205687Z   - dotnet build
2022-08-25T09:26:18.7229163Z Waiting for log information of task 'dotnet build'...
2022-08-25T09:26:19.0225314Z      Running generic task log analysis...
2022-08-25T09:26:19.0226233Z      Total warnings: 105, Filtered warnings: 105
2022-08-25T09:26:19.0227135Z   - dotnet test
2022-08-25T09:26:24.0274334Z Waiting for log information of task 'dotnet test'...
2022-08-25T09:26:24.4908239Z Waiting for log information of task 'dotnet test'...
2022-08-25T09:26:24.6417167Z      Running generic task log analysis...
2022-08-25T09:26:24.6418000Z      Total warnings: 0, Filtered warnings: 0
2022-08-25T09:26:24.6423775Z Overall total warnings: 105
2022-08-25T09:26:24.6424963Z Overall filtered warnings: 105
2022-08-25T09:26:24.7465011Z [WARNING] The baseline build could not be found. All policies based on the previous build will pass.
2022-08-25T09:26:24.7466925Z ##[warning]The baseline build could not be found. All policies based on the previous build will pass.
2022-08-25T09:26:24.7470949Z [SUCCESS] Warnings policy passed with 105 warning(s).
2022-08-25T09:26:24.7481140Z Statistics generation took 0.084ms
2022-08-25T09:26:25.0816116Z ##[section]Finishing: Check build quality

[ReneSchumacher]

Hi @Magnuti,

can you give me more information about your specific setup? Most importantly: do you have only one pipeline that runs for your PR and your master branch or are there two pipelines?

In general, BQC only compares to baseline builds from the same build definition. Thus, if you have a definition that you use, e.g., with a CI trigger on master and you use that definition as a validation build in your branch policy so that is runs for every PR to master, BQC automatically picks up the baseline build. However, if you are using two different definitions (one for master and one for PR validation), you must also specify the definition ID (baseDefinitionId yaml parameter) in combination with the baseBranchRef.

Btw: the UI only populates the repository after you have selected the build definition.

[Magnuti]

Hi @ReneSchumacher,

It seems I cannot select a build definition in the UI.

I will get back to you with information about the pipeline(s) since I'll have to check with my organization.

[jd4ds]

Hello there, ever since a couple of days ago I started to see the same behaviour with all our existing pipeline definitions. Exisiting definitions were only showing IDs in the Build Definition, Repository and Branch Git Fields not the labels like before. Also there is now drop-down listing any Builds, Repositories or Git Branches anymore. This is a problem for us since it makes it kind of hard to edit our existing pipelines. Do you have any idea what causes this problem? Thanks, Janis

[ReneSchumacher]

Thanks for letting us know. There apparently was a change in the backend that broke the UI. I'll look into it and provide a fixed version as soon as possible.

[MikeWilliams-UK]

I have the same too I cloned a build pipeline and want to point this task to the correct repo and branch. On existing pipelines I see a guid instead of the repo data

[MikeWilliams-UK]

I even tried changing the task version all the way down to 4.* and there is no difference, nothing can be selected!

[ReneSchumacher]

@MikeWilliams-UK That makes sense because the issue is not in the task or task version. The UI needs to make an API call back to Azure DevOps for reading the data that is shown in the drop-down lists. However, that call is blocked or the connection that was used in the past seems to be unavailable now. I'm in contact with the Azure DevOps teams already to see what's going on and how to fix it.

[gioce90]

I'm in contact with the Azure DevOps teams already to see what's going on and how to fix it.

Okay @ReneSchumacher , we will wait news from you :)

[MikeWilliams-UK]

Thanks for the update

[Magnuti]

Hi @ReneSchumacher, how is it going? Are there any updates on the issue from the DevOps team?

[gioce90]

Hi @ReneSchumacher, how is it going? Are there any updates on the issue from the DevOps team?

Same question

[ReneSchumacher]

Hi all,

I'm still waiting for the analysis done by the product group. Took some time to find the right person, now they are investigating. Unfortunately, there is no workaround for the UI issue. You can use the tasks from a YAML pipeline without any issues, though.

[MikeWilliams-UK]

Thanks for the update. I too have had difficulties in getting hold of the "right person" for Azure / Office 365 Tennacy issues in the past so I sympathise with you.

[ReneSchumacher]

Short update: PG apparently found out that this problem only affects the cloud but not the on-prem version of Azure DevOps. They are now investigating what has changed on the cloud side. I'll keep you posted and sorry for the slow turnaround!

[gioce90]

Short update: PG apparently found out that this problem only affects the cloud but not the on-prem version of Azure DevOps. They are now investigating what has changed on the cloud side. I'll keep you posted and sorry for the slow turnaround!

Thank you @ReneSchumacher for keeping us informed.

[MikeWilliams-UK]

Is there any update on a resolution for this?

[ReneSchumacher]

Thanks @MikeWilliams-UK for asking. I'm still discussing with the PG. There is currently a team investigating. However, there were many changes where people moved around (from AzDO to GitHub and other teams, now slowly moving back to AzDO) and this makes analysis a bit harder than it should be. I was on vacation last week and will try to push this now that I'm back.

[ReneSchumacher]

Hi all,

I'm still waiting for the PG to fix the underlying issue 😞 Here's what we know:

• The issue only affects classic pipelines UI which connects back to Azure DevOps to read some data.
• It only affects Azure DevOps Services, all server versions seem to work fine (so far).
• There is no workaround other than switching to YAML where the UI logic is not used.
• The issue affects all tasks using a sourceDefinition in the task.json - unfortunately, most of my task (Build Quality Checks and Create Work Item) do so.

I'll update this issue regularly (or at least I try to).

[MichaelReitsma]

Hi Rene, We are experiencing the same issue. I can not change our classic pipelines to include this task or modify existing pipelines. This task is crucial for auditing purposes. Using YAML is NOT an option for us (what is it with MS that keep tryiing to push that to their customers). I am worried that this issue apparently drags on from august without an solution in sight. FYI the endpoint url that doesnt work is https://dev.azure.com/asr-nl/_apis/distributedtask/endpoint

Why is it not possible to modify this widget so that the chooser is optional ? That way we can just copy paste the proper value in the without having to use the dropdown. You have done that in the past with other fields such as Area Path, Iteration Path as well.

Hope to hear from you soon. Regards

Endpoint: url with response 400 https://dev.azure.com/asr-nl/_apis/distributedtask/endpoint

Payload: {url: "/_apis/wit/workitemrelationtypes?api-version=3.2", selector: "jsonpath:$.value[].name",…} connectionId: "tfs:00025394-6065-48CA-87D9-7F5672854EF7" keySelector: "jsonpath:$.value[].referenceName" scope: "8038f888-11c3-48f7-a1bd-2f918305dfe9" selector: "jsonpath:$.value[*].name" taskId: "92979e78-16ed-4e27-b008-001d2d58bf74" url: "/_apis/wit/workitemrelationtypes?api-version=3.2"

Response: $id: "1" errorCode: 0 eventId: 3000 innerException: null message: "No service connection found with identifier tfs:00025394-6065-48CA-87D9-7F5672854EF7." typeKey: "EndpointNotFoundException" typeName: "Microsoft.TeamFoundation.DistributedTask.WebApi.EndpointNotFoundException, Microsoft.TeamFoundation.DistributedTask.WebApi"

[ReneSchumacher]

Hi all,

I can only apologize for the long turnaround here. The issue is caused by a bug in Azure DevOps Services which I cannot fix myself and the product group is currently quite slow picking this up. So, let me go over the options you and I have here:

1. Switch to YAML
   I do understand that some customers do not want to move away from classic pipelines, and we want to fully support classic pipelines as long as they are supported in Azure DevOps itself. Just keep in mind that classic pipelines don't receive any new functionality anymore. All new features that might be coming will very likely only apply to YAML pipelines as has been the case for many months already. Still, I do respect the decision not to move off of classic to YAML.
2. Manually enter the data
   This is currently possible for most fields in the tasks. Here is what you have to do:
   • Build Quality Checks
     • Baseline - Build Definition: Manually enter the build definition ID to use.
     • Baseline - Repository: You can ignore this field and not enter a value.
     • Baseline - Branch (Git): Manually enter the full Git branch ref (e.g., refs/heads/master) to use.
   • Create Work Item
     • Team Project: Manually enter the team project name to use.
     • Work Item Type: The task editor for selecting the work item type should work. If it doesn't, manually enter the work item type name to use.
     • Area Path: The task editor for selecting the area path should work. If it doesn't, manually enter the area path in the format \[\...]
     • Iteration Path: The task editor for selecting the iteration path should work. If it doesn't, manually enter the iteration path in the format \[\...] pr use @currentIteration to specify a team's current iteration.
     • Additional Fields: The task editor for specifying additional fields should work. If it doesn't, manually enter the additional field as described in the documentation
     • Linking - Link Type: Unfortunately, this field currently does not allow manual values. I will update the task so you can enter the link type manually as described in the documentation for YAML.
3. Fix the underlying issue
   As mentioned, I as the task owner cannot fix the underlying issue in Azure DevOps Services. However, I will try to push this with the product group, so we hopefully will have a true fix in the future.

[ReneSchumacher]

Hi again,

I'm currently pushing the new version 1.17.1 of the Create Work Item extension to the marketplace. It should be available in a couple minutes. This version allows manually specifying the link type for work item linking which should complete the workarounds described above.

If you hit additional obstacles, please let me know.

[MichaelReitsma]

Hi Rene,

Thanx for the update. Glad to see there is a intermediate solutiuon. Many thanx for efforts you put in this. I will test this asap.

rgrds

[jd4ds]

Hi Rene, thank you for adding some info about how to work around this issue. Just one question, I can not seem to find out how to find out about the "build definition ID". Can you tell me how to obtain it from Azure DevOps? Thank you!

[MikeWilliams-UK]

It's at the end of the URL when you edit the build definition

[gioce90]

Hi @ReneSchumacher ,

Thank you for the update. I think this is a good workaround but I have tested "Create Work Item" right now using this configuration:

... sadly I'm not sure this works.

In my test, I want to create a "Release" work item with references to all the work items "released". So, I was expected to see just one link to one work item:

(this is a release on my Release Pipeline).

But how you can see, in my new Release workItem there are A LOT of:

Maybe I'm doing something wrong. Initially I believed that the list would be limited to only the work items included in the release.

[ReneSchumacher]

Hi @gioce90,

the task works different than the UI. When you go to the release UI, select a stage, and then list the associated work items, the UI first queries the build that has been deployed to that particular stage and then lists the work items associated with that build. However, our task simply queries all work items associated with the release, which should return all work items associated with all builds that have been deployed by the release.

We essentially use this API: https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/releases/{releaseId}/workitems

[ReneSchumacher]

Hi all,

I have by now received an update from the product group. Apparently, a new feature flag was enabled that changed the way service connection access is authenticated. Unfortunately, this breaks the usage from the task UI and the PG does not have a final solution for this yet. Imho, the work arounds should be sufficient for now, but I'll post an update when there's more to share.

[ReneSchumacher]

Issue was fixed - forgot to close this.