Azure-pipelines-tasks: PowerShell version 2 (preview) Environment variables are not saved

Created on 21 Jun 2018  路  18Comments  路  Source: microsoft/azure-pipelines-tasks

In the The PowerShell version 2.* (preview).
The Environment variables, which you can use to set Env variables for use inside the script (im using inline type). Are not saved upon saving the Task.

Additionally exporting this Task to a Task group causes all kinds of wierd stuff in terms of automatic task-group variable detection. It seems that task groups do not respect the $() pattern. But instead match everything that starts with $.

Most helpful comment

That's correct. It affects all Release tasks which have the environment variables block. Build tasks are unaffected by the bug.

I will update once the fix has rolled out to all customers.

All 18 comments

I'm seeing the same symptom saving environment variables.

Still happening with the "non (preview)" version

@Danthar Can you please share an example where task group is matching with $ instead of $() pattern?

The saving of environment variables was a service side bug and has been fixed. It is rolling out to customers this week.
@bansalaseem hopefully can comment to the pattern matching issue.

This seems to be affecting the Command Line V2 task as well. No matter if you use task variables or hard coded values, also this seems to be affecting only the Release Templates and not the Build Templates where I am able to save Environment variables to the task

That's correct. It affects all Release tasks which have the environment variables block. Build tasks are unaffected by the bug.

I will update once the fix has rolled out to all customers.

Having the same issue on the Bash task in releases (build seems to work). Any update on when this would be deployed?

The last ring of users should be getting the fix this week. I will send an update once this happens.

The final ring of users have received the update. This fix is available for all users now.

I seem to be getting the same issue now, but only on Task Groups. When I use the task directly on a build or release it remembers my environment variables, but when I use Task Groups it forgets it on save.

Is this issue related?

I'm also seeing this problem in Task Groups when running with type inline-script. Also, if describe my powershell task environment variables with $() syntax they are not picked up as Task Group Parameters.

Thanks for the reports. I'll reopen the issue and look into it.

@samneirinck and @bryanbcook Are you using inline scripts in the tasks? or do the individual tasks reference script files?

In my case it references a script file. I ran against the issue again today, so I think it's still valid.

@samneirinck I am unable to repro with script files. I am able to create two tasks that reference script files. In the script files, I have Write-Host $env:foo. This saves, runs, and prints the given env var from the task. Then I create a task group out of these tasks. I go to the task group editor, and modify the environment variables in the tasks. I click save, and then queue a new build. The new values are printed successfully, and the Task Group UI stays in sync with my latest changes. Could you provide your specific repro steps?

@bryanbcook For inline scripts, when you reference environment variables via $() syntax, it looks like the task group overrides the "environmment variables" and prompts you for task group parameter values. Then when you modify the task group, the top level item has those parameters defined. You can modify them there. Unfortunately the environment variables are still listed in each seperate task too. I'll create a bug and see what we want to do here. Perhaps for task groups we will either hide the environment variables - or we will stop converting them into task group parameters. Either way, it doesn't sound like you are having a problem saving the values in UI, right? Could you also provide some explicit steps?

I am closing this issue, as these appear different from the original issue above. Please feel free to create a new issue with your specific repro steps, so we can track them.

@bradwillis thanks for taking the time to try this out. When I tried it again today, it works seamlessly, as you describe... Not sure how/why, but at least it's no longer an issue now.

@samneirinck No problem! Glad it is working.

Was this page helpful?
0 / 5 - 0 ratings