TFS 2015 Могут ли переменные сборки получать доступ к другим переменным сборки?

Когда я определяю пользовательскую переменную в новой сборке команды TFS 2015 следующим образом:
Имя: SomeOutput
Значение: $(System.DefaultWorkingDirectory)\Some

...похоже, он не расширяется $(System.DefaultWorkingDirectory).
Есть ли способ обойти это?

EDIT:
По крайней мере, кажется, что это не везде.

Например, в MSBuild-Arguments /p:OUTPUT="$(SomeOutput)" расширяется до /p:OUTPUT="C:\TfsData\BuildAgents\_work\3\s\Some", но когда я добавляю задачу сборки строки cmd с набором инструментов cmd и параметром /k set, она печатает
SOMEOUTPUT=$(System.DefaultWorkingDirectory)\Some

РЕДАКТИРОВАТЬ 2: Вот мои переменные
переменные

Это этап моего рабочего процесса
рабочий процесс

Вот что выводит сборка
вывод сборки


tfs azure-pipelines variables tfs-2015 tfsbuild
person Suchiman    schedule 02.12.2015    source источник
comment
Как вы использовали его через cmd? Какая строка cmd? Не могли бы вы предоставить более подробную информацию, например скриншот cmd.   -  person PatrickLu-MSFT    schedule 03.12.2015

Ответы (3)


arrow_upward
10
arrow_downward

Вы можете использовать расширение переменных задач VSTS из визуального Студийная биржа.

Когда вы определяете переменную на экране «Переменные» и используете другие переменные в качестве значения, они не будут расширены (как вы могли ожидать). Вместо этого литеральный текст передается задачам в рабочем процессе. Без этой небольшой задачи следующая конфигурация не будет работать:

Variable              Value
Build.DropLocation    \\share\drops\$(Build.DefinitionName)\$(Build.BuildNumber)

Добавив задачу «Расширить переменные» в начало рабочего процесса, она позаботится о расширении, поэтому любая задача под ней получит нужное вам значение.

https://github.com/jessehouwing/vsts-variable-tasks/wiki/Expand-Variable

PS: Новый агент (версия 2.x) теперь автоматически расширяет переменные.

person AHMED EL-HAROUNY    schedule 14.04.2016

arrow_upward
4
arrow_downward

Этого можно достичь.

Вам может понадобиться использовать % % вместо $ для вызова переменных в cmd для печати результата. Также необходимо добавить call перед командой. Вот простой пример: пример запроса расширения переменных cmd

Примечание. System.DefaultWorkingDirectory недоступен в cmd (не знаю почему); вместо этого вам нужно использовать System_DefaultWorkingDirectory. Подробности можно посмотреть в логах.

person PatrickLu-MSFT    schedule 03.12.2015
comment
Привет. извините, если я не был ясен. Я добавил запрошенные изображения в свой вопрос. Проблема в том, что это не работает в том же определении сборки, где эта переменная экспортируется как переменная среды на этапе сборки. Название должно было относиться к использованию переменных сборки из той же сборки в определении другой переменной. - person Suchiman; 03.12.2015
comment
Приходите к тому же результату в моей среде. Не уверен, что это поддерживается в CMD. Завтра дважды проверю и обновлю свой ответ. - person PatrickLu-MSFT; 03.12.2015
comment
привет, это почти завтра :) есть какие-нибудь новости, чтобы поделиться? - person Suchiman; 10.12.2015
comment
к этому (не знаю почему) это объясняется здесь: msdn.microsoft.com/en-us/Library/vs/alm/Build/scripts/variables (см. абзац выше «Секретные переменные»). Действительно, я вижу, как это работает, но я все еще думаю, что это обходной путь. Мне пришлось бы объявить Some как %BUILD_STAGINGDIRECTORY%\Some, что не позволило бы использовать эту переменную вне контекста скрипта. Я думаю, агент сборки должен попытаться расширить все переменные $(...) перед их экспортом в среду. - person Suchiman; 10.12.2015
comment
@Suchiman Кажется, нет. По крайней мере, результаты тестов соответствуют этому. Агент сборки будет расширять только $(Some), поскольку Some= $XX и $XX будут расширяться в среде, в которой вы его используете. Потому что $ не поддерживается в cmd, поэтому cmd считает $XX просто $XX и распечатывает его. И MsBuild поддерживает $. Вот почему вы можете получить правильный результат. Мне было интересно, не является ли причина того, что агент Vnext Build работает шаг за шагом, до шага «выполнить cmd» агент не будет использовать $ XX и, конечно же, не расширит его. - person PatrickLu-MSFT; 10.12.2015
comment
спасибо пока. Однако я хочу сказать, что это работает не только в msbuild, но и в текстовых полях агента сборки. Например: если вы создадите этап пакетной сборки скрипта и передадите $(Some) в качестве аргумента, он получит правильный результат "C:\a\1\a\Some" вместо $(Build.StagingDirectory)\Some. Заставить это также работать при экспорте переменных среды кажется интуитивно понятным. - person Suchiman; 10.12.2015
comment
Поскольку я заблудился, пытаясь найти TFS / VSTS при подключении, я нахмурился с предложением заставить это работать. - person Suchiman; 10.12.2015

arrow_upward
2
arrow_downward

У меня была та же проблема - я хотел собрать путь, состоящий из нескольких встроенных переменных, и передать его сценарию PS.

Обходной путь. В итоге я объединил переменные в фактическом скрипте с соответствующими сгенерированными переменными среды (например, $env:BUILD_SOURCESDIRECTORY).

Не то, что я имел в виду изначально, но, по крайней мере, это работает. Недостаток — если мне нужно изменить путь, мне всегда приходится менять PS-скрипт вместо переменной сборки.

person knipp    schedule 03.12.2015