Графический модуль Runbook для автоматизации Azure - не удается выполнить другие модули Runbook в учетной записи автоматизации как отдельные действия холста?

Пользовательский интерфейс графического редактора позволяет добавлять модули Runbook рабочих процессов (только; собственные PS не отображаются), однако это нарушает определение / выполнение GraphRunbook.

Когда я пытаюсь протестировать или опубликовать модуль Runbook, я получаю сообщение об ошибке в образе. (Также странно, это сообщение об ошибке отображалось с комбинацией испанского для первой части и английского для второй части.)

Другие модули Runbook в учетной записи автоматизации технически не поддерживаются ..?

1]

код testtwo:

workflow testtwo
{
    [outputtype([string])]
    [cmdletbinding()]
    param()

    write-output "testtwo runbook output"       
}

azure powershell azure-automation powershell-workflow
person JoeBrockhaus    schedule 03.03.2016    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Сообщение об ошибке, которое вы получаете, связано с проблемой действующего сайта, над решением которой мы в настоящее время активно работаем.

person Community    schedule 03.03.2016
comment
Спасибо за предупреждение, Крис! - person JoeBrockhaus; 04.03.2016

arrow_upward
0
arrow_downward

Мне удалось заставить это работать относительно нелогичным образом. (По крайней мере, это противоречит интуиции относительно того, как модули Runbook рабочих процессов без графа анализируются на предмет выполнения зависимостей для копирования модулей Runbook в рабочие).

Вместо того, чтобы добавлять модуль Runbook на холст, я просто добавил вызов другого модуля Runbook в конфигурации редактора кода для MyCodeActivity.

На основе ReadMe.docx в комплекте с Orchestrator.GraphRunbook.Model.dll (пакет SDK для графической разработки для автоматизации Azure) в сочетании с опытом обучения здесь, в частности, действия WRT InlineScript (которые, afaik, по сути, являются тем, во что переводится действие кода), я не ожидал, что смогу выполнить другой модуль Runbook из контекста InlineScript, потому что (из ReadMe) ..

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

.. что в случае собственных модулей Runbook PS означает, что они не копируются в рабочую среду. К сожалению, я никогда не тестировал выполнение одноранговых модулей Runbook рабочих процессов (на которые не ссылались в другом месте, чтобы они были скопированы в worker), отчасти потому, что предполагалось, что код внутри InlineScripts не анализируется для зависимых модулей Runbook, но, возможно, это только для собственных ссылок (кажется сомнительное различие для меня)?

В любом случае, вышеуказанное, похоже, является временным решением.

Однако я надеялся, что модули Runbook будут рассматриваться как первоклассные на холсте дизайна (и в результирующей сериализованной модели), а не будут заблокированы внутри действия сценария, потому что я работаю над поиском зависимостей вне определение автоматического развертывания CI / CD в порядке зависимости. (Тем не менее, у меня уже есть грубый проход по проверке зависимостей для обычных сценариев, так что этого должно быть достаточно - просто означает больше синтаксического анализа.)

person JoeBrockhaus    schedule 03.03.2016