azure cli 登陆_使用Azure CLI对构建进行排队

最新推荐文章于 2024-06-05 01:50:54 发布

weixin_26752759

最新推荐文章于 2024-06-05 01:50:54 发布

阅读量365

点赞数

文章标签： python

原文链接：https://medium.com/swlh/azure-devops-yaml-pipelines-nine-features-you-should-know-about-534f348fc67a

版权

azure cli 登陆

使用Azure CLI对构建进行排队 (Using the Azure CLI to queue builds)

Since there is no support for running pipelines locally, you need to commit each change to your repository and queue your pipeline to run within Azure DevOps. To queue a run, you have three options: you can manually queue a run via the Azure DevOps GUI, you can set up triggers on your pipeline to queue a run whenever you commit, or you can use the Azure DevOps CLI to queue a run.

由于不支持在本地运行管道，因此您需要将每个更改提交到存储库，并将管道排队以在Azure DevOps中运行。要对运行进行排队，可以使用以下三个选项：可以通过Azure DevOps GUI手动对运行进行排队；可以在管道上设置触发器，以便在每次提交时对运行进行排队；或者可以使用Azure DevOps CLI对运行进行排队。

Of the three options, I have found the CLI the easiest to work with. The GUI takes a bit too long to click through, and the automatic triggers still mean you have to navigate through the GUI to check whether your pipeline worked and retrieve any validation feedback.

在这三个选项中，我发现最易于使用的CLI。 GUI花费的时间过长，自动触发仍然意味着您必须在GUI中导航以检查管道是否正常工作并检索任何验证反馈。

Using the CLI means you can get some validation feedback (more on that below), re-run builds as required, and easily change the variables sent to the pipeline. Adding the — -openflag to the command will open the build results page in your browser, allowing you to monitor the pipeline’s progress as it runs. Finally, combining the Azure DevOps CLI with committing and pushing to Git via the command line gives you a fast and elegant workflow.

使用CLI意味着您可以获得一些验证反馈(更多内容请参见下文)，根据需要重新运行构建，并轻松更改发送到管道的变量。在命令中添加— -open标志将在浏览器中打开构建结果页面，使您可以在管道运行时监视管道的进度。最后，将Azure DevOps CLI与通过命令行提交和推送到Git相结合，可以为您提供快速而优雅的工作流。

Image for post — My standard workflow for queuing builds.

Documentation for using the pipeline CLI.

使用管道CLI的文档。

调试验证错误 (Debugging validation errors)

Occasionally, there will be an error in your pipeline’s YAML files that will prevent you from queuing builds and return the following uninformative message: Could not queue the build because there were validation errors or warnings. To help investigate what has caused the failure, you have a variety of options meaning you should never need to resort to trial and error or commenting and uncommenting code to find out where you went wrong.

有时，管道的YAML文件中会出现错误，这将阻止您对内部版本进行排队并返回以下无信息的消息： Could not queue the build because there were validation errors or warnings. 为了帮助调查导致故障的原因，您有多种选择，这意味着您永远不必求助于反复试验或注释和取消注释代码来找出错误所在。

The VSCode extension

VSCode扩展

The official VSCode extension for Azure Pipelines provides some schema and syntax validations. However, since detailed validation errors are available only after a build is queued within Azure DevOps, its helpfulness is limited.

Azure Pipelines的官方VSCode扩展提供了一些架构和语法验证。但是，由于只有在Azure DevOps中将生成放入队列后才有详细的验证错误，因此它的有用性受到限制。

For those of us familiar primarily with other IDEs, to enable the syntax checking within VSCode you need to switch the language of the file from YAML to Azure Pipelines in the bottom right.

对于那些主要熟悉其他IDE的人来说，要在VSCode中启用语法检查，您需要在右下方将文件的语言从YAML切换到Azure Pipelines 。

Using the editor available in the Azure DevOps GUI

使用Azure DevOps GUI中可用的编辑器

From the same area of Azure DevOps where you can view previous builds and queue new ones, there is also an option to edit your definition file. Not only do you get the same basic checks available with the VSCode extension, but you can also queue a build from the DevOps GUI and see the exact validation error message. The one disadvantage of using the GUI editor is that it only displays the parent pipeline file, not allowing you to see or edit any template files. The validation message itself is accurate, regardless of which file contains the error.

在Azure DevOps的同一区域中，您可以查看以前的版本并为新版本排队，还可以选择编辑定义文件。您不仅可以获得与VSCode扩展可用的相同的基本检查，而且还可以从DevOps GUI将构建排队，并查看确切的验证错误消息。使用GUI编辑器的一个缺点是它仅显示父管道文件，而不允许您查看或编辑任何模板文件。无论哪个文件包含错误，验证消息本身都是准确的。

Using the debug flag in the CLI

在CLI中使用调试标志

If you want to continue using the Azure DevOps CLI mentioned in the first section, you can add the — -debug flag. Adding this command will produce many irrelevant log lines, but somewhere near the end will be the same error message returned when you queue a build via the GUI.

如果要继续使用第一部分中提到的Azure DevOps CLI，则可以添加— -debug标志。添加此命令将产生许多不相关的日志行，但是当您通过GUI对构建进行排队时，将在末尾附近返回相同的错误消息。

显示自定义错误消息 (Displaying custom error messages)

If one of the scripts within your pipelines fails or throws an exception, the email communication and run summary page for the pipelines won’t show a useful error message. Instead, you will get something vague like PowerShell exited with code 1. While more information will be available within the build’s logs, if this is a known failure, you probably want to save others from having to go digging. For example, perhaps you have a pipeline that accepts user input via the `parameters` feature. You may want to validate that input and stop execution if there is a problem, returning an error to the user indicating the validation check that failed the build.

如果管道中的脚本之一失败或引发异常，则管道的电子邮件通信和运行摘要页面将不会显示有用的错误消息。相反，您会得到一些模糊不清的信息，例如PowerShell exited with code 1 。尽管将在构建日志中提供更多信息，但是如果这是已知的失败，则您可能希望避免其他人去挖掘。例如，也许您有一个通过“参数”功能接受用户输入的管道。您可能需要验证该输入，并在出现问题时停止执行，将错误返回给用户，指示使构建失败的验证检查。

Documentation for additional logging commands.

其他日志记录命令的文档。

并行运行任务 (Running tasks in parallel)

While Azure DevOps supports running stages and jobs in parallel, steps are currently limited to running in sequence. If you need to eke a little more performance out of your pipelines, you can work around this limitation by running your scripts’ contents in parallel using the built-in capabilities within Bash and PowerShell.

虽然天青的DevOps支持运行stages和jobs并行， steps目前只限于在运行序列。如果您需要从管道中获得更多性能，可以使用Bash和PowerShell中的内置功能并行运行脚本的内容来解决此限制。

缓存依赖 (Caching dependencies)

One of your build’s slowest steps is likely to be retrieving and installing all of your application dependencies. Since this step often needs to happen early in your build, it can really slow down your change/test loop.

构建过程中最慢的步骤之一可能是检索并安装所有应用程序依赖项。由于此步骤通常需要在构建的早期进行，因此确实会减慢您的更改/测试循环。

You can improve the speed of this step by using the Cache@2 task. On a successful build, the pipeline will store the directory that you have specified within a location managed by Azure DevOps. Subsequent builds using the same dependencies will download this cached folder instead of installing the dependencies manually. The download speed of the cached bundle can vary, but on average is much faster than installing the dependencies normally. Further, as the project size and dependency count increase, the cache retrieval time will increase at a slower rate.

您可以通过使用Cache@2任务来提高此步骤的速度。成功构建后，管道将在Azure DevOps管理的位置中存储您指定的目录。使用相同依赖关系的后续构建将下载此缓存的文件夹，而不是手动安装依赖关系。缓存捆绑软件的下载速度可能会有所不同，但平均而言，其速度要比正常情况下安装依赖项快得多。此外，随着项目规模和依赖性计数的增加，缓存检索时间将以较慢的速率增加。

Documentation for the Cache@2 task.

Cache @ 2任务的文档。

查看变量的当前状态 (Viewing the current state of your variables)

Using variables in Azure DevOps can be a little complicated. Depending on the syntax you use to expand them, they can function as templating variables replaced either during the script’s compilation or before the execution of each step. Alternatively, they can be used within your scripts as environment variables, but their value is set before each task is run.

在Azure DevOps中使用变量可能会有些复杂。根据您用来扩展它们的语法，它们可以充当模板变量，可以在脚本编译期间或执行每个步骤之前替换它们。或者，它们可以在脚本中用作环境变量，但是在运行每个任务之前设置它们的值。

Since all variables are available as environment variables, on a Linux build agent, you can use the printenv command to print a list of all the available variables and their current values. Note that when used in the format of environment variables, Azure DevOps capitalizes the name and replaces dots with underscores.

由于所有变量都可以用作环境变量，因此在Linux构建代理上，您可以使用printenv命令来打印所有可用变量及其当前值的列表。请注意，当以环境变量的格式使用时，Azure DevOps将名称大写，并用下划线替换点。

Documentation for declaring and using variables.

声明和使用变量的文档。

启用详细诊断 (Enabling detailed diagnostics)

When queuing builds via the GUI, there is an option to enable logging additional debug information for each step. You can also enable this feature within your YAML script. The advantage of setting it within your YAML files is that it will be available until it is turned off again.

通过GUI对构建进行排队时，有一个选项可启用为每个步骤记录其他调试信息。您还可以在YAML脚本中启用此功能。在您的YAML文件中进行设置的好处是，在再次将其关闭之前，它将一直可用。

Documentation for logging commands.

记录命令的文档。

使用模板重用代码 (Using templates to reuse code)

Pipeline templates are a powerful way to reduce code duplication, whether you need to call the same block of code multiple times within a single pipeline or want to share a block of code between multiple pipelines. For example, you may have a multi-stage release pipeline, but the instructions for releasing to each environment are almost identical. Or perhaps you have two different builds with similar steps, one that is triggered off pull requests, and another that runs nightly integration builds.

管道模板是减少代码重复的有效方法，无论您是需要在单个管道中多次调用同一代码块还是要在多个管道之间共享代码块。例如，您可能有一个多阶段发布管道，但是发布到每个环境的说明几乎相同。或者，您可能有两个具有相似步骤的不同构建，一个是从请求请求触发的，另一个是夜间运行的集成构建。

Documentation for using templates in your pipelines.

在管道中使用模板的文档。

从管道内部访问Azure DevOps CLI (Accessing the Azure DevOps CLI from within the pipeline)

Accessing the Azure CLI is quite straightforward; all you need to do is set up a service connection and place your script inside the AzureCLI@2 task. However, accessing the Azure DevOps CLI requires an extra step.

访问Azure CLI非常简单；您需要做的就是建立服务连接，并将脚本放置在AzureCLI@2任务中。但是，访问Azure DevOps CLI需要额外的步骤。

There are a couple of methods, but the simplest is to provide the AZURE_DEVOPS_EXT_PAT environment variable to an AzureCLI@2 task. This approach’s advantage is that you can use an access token that has already been configured by the pipeline and does not require you to set up a new personal access token or pass it to the pipeline yourself.

有两种方法，但最简单的方法是为AzureCLI@2任务提供AZURE_DEVOPS_EXT_PAT环境变量。这种方法的优势在于，您可以使用管道已配置的访问令牌，而无需您设置新的个人访问令牌或将其自己传递给管道。

Documentation for using the Azure DevOps CLI in Azure Pipelines.

在Azure Pipelines中使用Azure DevOps CLI的文档。

While I have been impressed by how powerful Azure DevOps pipelines are, the volume of features, combined with the lack of examples, has meant that I often found myself discovering features days or weeks after they would have been helpful. When it comes to Azure DevOps pipelines, if you think you should be able to something, you probably can — it's just a matter of finding the right documentation.

尽管我对Azure DevOps管道的强大功能印象深刻，但功能的数量加上缺少示例的情况，意味着我经常发现自己在有用的几天或几周后发现了功能。当涉及到Azure DevOps管道时，如果您认为应该能够做到，则可能会—仅是找到正确的文档即可。