[BUG]: pipeline behaviour has changed % is now encoded as %AZP25

[pniederlag]

What happened?

We have an azure devops pipeline that has been operational for about 3 years. The pipeline was not changed in any way.

We have now tracked down a problem to have occured since a couple of weeks where an environment_variable that contains a '%' is recoded to '%AZP25'.

This is an - unwanted - change in behaviour.

google revealed something that was documented ~3years ago and seems to be related:

https://github.com/microsoft/azure-pipelines-agent/blob/master/docs/design/percentEncoding.md?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=de

Versions

azure-devops platform

Environment type (Please select at least one enviroment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Operation system

No response

Version controll system

No response

Relevant log output

No response

[max-zaytsev]

Hi @pniederlag thanks for reporting!

We have an azure devops pipeline that has been operational for about 3 years.

where an environment_variable that contains a '%' is recoded to '%AZP25'.

Do I understand correctly that environment_variable used to contain %? Can you please provide a minimal repro project?
What version of the agent is used in your pipeline?

[CAN1D]

I just encountered the same problem: I have an azure devops git repo wherein the repo path has spaces in the name because some non-developer set everything up in the first place.
That space in the url gets encoded as %20 and azure devops then converts it to %AZP2520; I have added one repo as a submodule on another repo and then discovered this problem:
the end result is that I can't find my submodule because the path is obviously wrong.

Will this be a thing I need to mitigate myself in my pipeline? Will MS fix their bug? Should I just move to Bitbucket instead?

[pniederlag]

Hi @pniederlag thanks for reporting!

We have an azure devops pipeline that has been operational for about 3 years.

where an environment_variable that contains a '%' is recoded to '%AZP25'.

Do I understand correctly that environment_variable used to contain %? Can you please provide a minimal repro project? What version of the agent is used in your pipeline?

Maybe you can try with a most simple pipeline that just does "export MYVAR=Some%Weirdness; echo $MYVAR"... to be honest, I dont use devops anymore except for this legacy pipeline and as such it would take me ages to setup a test for this. Still, this is a very subtile and bad bug that could cause all kind of weird and unknown troubles. I could probably share details with MS-Support if requested via private channel.

[github-actions]

This issue has had no activity in 180 days. Please comment if it is not actually stale

[bas001]

Having the same Issue when checking out a repo that exists in a project which has a whitespace in the name. Pipeline is running if the Pipeline is defined within the project itself but the checkout fails if the pipeline gets created in an different project.
Reason: %20 (whitespace) gets encoded like %AZP2520

[sanjeev40084]

Try turning off 'Limit job authorization scope to current project for non-release pipelines' under project settings > settings > general. I had the same issue as @bas001, that somehow fixed the issue.

[Sean-Taitano-CPP]

I am up against something similar. We use an extension to pull passwords from Delinea Secret Server. If the password to retrieve has a '%' in it, it comes through in devops as '%AZP25'

Since the extension is open source: https://github.com/DelineaXPM/SS-ADO-BuildTask
I cloned and modified it.

it uses azure-pipelines-task-lib

import tl = require('azure-pipelines-task-lib/task');

then some http calls for a token and then queries an endpoint and retrieves values. I have tested these endpoints and they are returning appropriate values when called, both in this extension (logged output direct to console), and from C# boilerplate.

the username, password, and domain are then set as variables using tl.setVariable, setting secret values as appropriate for the password.

to test this issue, I simply added some additional setVariable calls with hardcoded percent symbols.

and tested from a yaml pipeline:

and received this output from IIS on the application pool:

Now I'm sure I could build a smaller extension repro repo, but I have a hard time believing this is the expected behavior. What am I doing wrong?

Azure Devops Server 2020 Update 1.2 (18.181.32404.7) Agent Version 2.181.2. Everything is on-prem.

[github-actions]

This issue has had no activity in 180 days. Please comment if it is not actually stale