The created work item either has *** in the title or in content in the work item

[ossentoo]

Hi

I'm using the CreateWorkItem@1 extension and for the most part it works as described, so thanks for that.

The issue is that when a work item is created, it has in the title (or in other fields that we use), in place of the desired text. the behaviour is not consist though because it seems like for most pipelines where the yaml is run, I get the expected output. However, there are some instances where the appear, and I can't trace why because the yaml is the same as what we have in those instances where the functionality works.

For example:

- task: CreateWorkItem@1 displayName: Create PRD work item inputs: teamProject: Project1 workItemType: User Story title: $(System.TeamProject) $(Build.DefinitionName) $(Build.BuildNumber) assignedTo: $(Build.RequestedForId) areaPath: Project1 iterationPath: Project1 fieldMappings: | State=Resolved Acceptance Criteria=$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_build/results?buildId=$(Build.BuildId) associate: true

In some cases produces a work item with the title:

*** *** 2024.1.30.3

and in other cases will produce:

Project1 Deploy 2024.1.30.3

there are other cases where I have also seen:

CompanyDepartment-*** *** 2024.1.30.3

bottom line, I am expecting:

Project1 Deploy 2024.1.30.3 in all cases.

Is there an option that I can disable in the yaml task to turn off this behaviour?

I don't think this behaviour is due to the length of the title. I think it's may be about obfuscation. However, I would like to disable it if possible.

Where the build definition name as the company prefix in it. We are using Azure DevOps cloud edition.

the agent versions we are using are 3.232.3 (however this issue seems to persist across agent types). We mostly use Windows agents, although I have also confirmed that this issue happens on Linux agents to. Our agents are self hosted. We use yaml mostly.

Describe the problem and expected behavior Tell us what you wanted to achieve and what unexpected behavior actually happened. Add any concrete error messages you see in your pipeline. Add any additional information or screenshots that describe your problem in more detail.

Task logs Run your pipeline with the following variables:

• For BuildQualityChecks: System.Debug and BQC.LogRawData set to true
• For CreateWorkItem: System.Debug set to true
• For PostBuildCleanup: System.Debug and PBC.LogRawData set to true

Send the task log to PSGerExtSupport@microsoft.com and reference your GitHub issue.

Attention: The log file may contain sensitive data (e.g., server or organization names, project names, variable information). Please do not attach the log to your GitHub issue and or remove the information from the log file before attaching or sending.

[ReneSchumacher]

Hi @ossentoo,

the reason for seeing the three asterisks is most likely that the value is set as secret. We must ensure that our task cannot be used to extract the content of secret variables. Thus, every value that is set it put through a variable resolver that resolves the variables (if any) in the value and then masks all secrets with three asterisks.

My guess is that you have secret variables with the same values as $(System.TeamProject) or $(Build.DefinitionName). If that is the case, our masking does a simple search and replace (similar to what the agent does when logging strings) for all known secret values, which then also replaces the built-in variable values.

I have seen this from one other customer who was using terraform and had secret variables for terraform that were set to the value of (e.g.) $(System.TeamProject). This creates this behavior. We have discussed this internally and decided to keep this behavior instead of risking the leak a secret.

[ReneSchumacher]

Hi @ossentoo,

I'm closing the issue for now as I didn't receive any feedback to my comment. If the issue still exists, please comment, and I will reopen the issue.