0

图形编辑器 UI 似乎允许添加 Workflow Runbook(仅;不显示本机 PS),但是,这会破坏 GraphRunbook 定义/执行。

当我尝试测试或发布 Runbook 时,我收到图像中的错误。(同样奇怪的是,这条错误消息的前半部分是西班牙语,后半部分是英语。)

自动化帐户中的其他运行手册在技术上是否不受支持.. 尚未?

1]

测试二代码:

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

    write-output "testtwo runbook output"       
}
4

2 回答 2

1

您收到的错误消息来自我们目前正在积极解决的现场问题。

于 2016-03-03T22:08:30.653 回答
0

我设法让它以一种相对违反直觉的方式工作。(至少,对于如何解析非图形工作流运行手册以进行依赖执行以将运行手册复制到工作人员,这与直觉相反)。

我没有将 Runbook 添加到画布,而是简单地将调用添加到 MyCodeActivity 的代码编辑器配置中的另一个 Runbook。


基于与 Orchestrator.GraphRunbook.Model.dll(Azure 自动化图形创作 SDK)捆绑的 ReadMe.docx,结合这里的学习经验,特别是 WRT InlineScript 活动(其中,afaik 本质上是 Code Activity 翻译成的内容),我不希望能够从 InlineScript 的上下文中执行另一个运行手册,因为(来自自述文件)..

执行引擎会将提供的块视为黑盒,并且不会尝试分析其内容,除了非常基本的语法检查。

.. 在 Native PS Runbook 的情况下,这意味着它们不会被复制到工作人员。不幸的是,我从未测试过执行对等工作流运行手册(未在其他地方引用,因此它们将被复制到工作人员),部分原因是假设 InlineScripts 中的代码不会针对依赖运行手册进行解析,但也许这仅适用于本机引用(似乎对我来说是一个可疑的区别)?

无论如何,以上似乎是一种解决方法。

但是,我希望运行手册在设计画布(以及由此产生的序列化模型中)上被视为一等公民,而不是被锁定在脚本活动中,因为我正在努力从按依赖顺序自动部署 CI/CD 的定义。(也就是说,我已经粗略地检查了普通脚本的依赖项,所以这就足够了——只是意味着更多的解析。)

于 2016-03-03T21:23:27.613 回答