[Bug][AzureDevOps_GO plugin] Failure to read environment names and to detect prod deployments

[medhatfawzy]

Search before asking

• I had searched in the issues and found no similar issues.

What happened

I've set up the Azure DevOps plugin to scan four repos in my project. The plugin managed to read the pipeline runs successfully. However, it failed to read the environment name, and it failed to detect prod deployments. I've configured a scope config in order for the plugin to detect the prod deployments correctly, because the name of the prod environment is usually [a-z]{2,4}-prod

My Azure pipeline YAML file is a bit complex because the team uses some reusable templates that are modular and shared across different services. It consists of stages, and the deployment stage contains jobs like helm: deploy and terraform: deploy , but not a job with the env name. The env name is in the stage. However, there's a job called predeploy_.*_prod , which should be matched by the regex I am using. However, it wasn't and DevLake is failing to detect the names of the environments.

This is a picture of the pipeline:

And this is the structure of the pipeline YAML file:

resources:
  repositories:
  - repository: repo1
  - repository: repo2
trigger:
  branches:
    include:
    - main
parameters:
- name: operation
  displayName: Operation
  type: string
  default: Deploy
  values:
  - Deploy
  - Destroy
  - Helmrollback
variables:
- name: name1
  value: value1

stages:
- stage: prebuild
  isSkippable: false
  displayName: Prebuild
  dependsOn: []
  condition: succeeded()
  variables:
  - name: name1
    value: value1
  - name: name2
    value: value2
  jobs:
  - job: initialize_framework
    displayName: "Initialize framework"
    pool:
      name: server
  - job: job1
    timeoutInMinutes: 180
    pool:
      name: pool1
    steps:
    - task: xxxxxxxxxxxxxxxxxxxx@1
      condition: false
      inputs:
        alias: none
.....

- stage: predeploy_xxxx_prod
  displayName: 'Predeploy: xxxx-prod'
  dependsOn:
  jobs:
  - job: initialize_framework
    displayName: "Initialize framework"
    pool:
      name: server
  - job: predeploy_xxx_prod_variables
    pool:
      name: pool1
.....

- stage: deploy_xxxxx_prod
  displayName: 'Deploy: xxx-prod'
  dependsOn:
  - .xxxxxx
  condition: succeeded()
  variables:
  - name: name1
    value: value1
  jobs:
  - job: initialize_framework
    displayName: "Initialize framework"
    pool:
      name: server
  - deployment: deploy_xxxxx_prod_helm
    environment:
      name: xxxxx-prod
    pool:
      name: pool1
    timeoutInMinutes: 180
    strategy:
      runOnce:
        deploy:
          steps:
          - task: xxxxxxxx@1
            condition: false
            inputs:
              alias: none
.....

What do you expect to happen

When scanning ADO pipeline runs, it should fetch the environment names correctly and detect which deployment is a prod deployment.

How to reproduce

• Set up an ADO connection with an Azure pipeline for a service that has different environment names, like dev, test and prod.
• Add the connection to the project
• Run the pipeline
• Try to query production deployments

Anything else

I've tried multiple regex, but the problem kept happening

Version

v1.0.2@41c047d

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[dosubot]

Hi @medhatfawzy! I'm Dosu and I’m helping the incubator-devlake team.

The AzureDevOps_GO plugin currently detects environments and production deployments by applying your regex patterns only to pipeline or job names (and tags), not to stage display names or nested YAML fields. If your environment name appears only in the stage display name or within a complex YAML structure, the plugin won't detect it due to this limitation. This is a known gap—there’s an open feature request to extend detection to pipeline run names, which could help in the future (see #8653).

Right now, the only workaround is to ensure that your environment or deployment names are present in the pipeline or job names themselves, so your regex can match them. Adjusting your YAML or naming conventions to surface the environment name in job or deployment names is the most reliable way to get detection working with the current plugin logic.

If you want more robust detection (e.g., parsing stage display names or nested YAML), it would require a code change to the plugin to extract environment info from those fields. If you’re interested in contributing, focusing on expanding the matching logic in the plugin’s build conversion step would be the place to start.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}