3

我尽可能地遵循持续交付的基本原则：“构建一次，随处部署”。

TL;博士：

在 Azure Devops Release Pipeline 的 SWA 步骤中：有没有办法让 Oryx 不构建 api 或识别它是一个 dotnet 项目？

我更喜欢 Azure Devops 进行部署，而不是目前的任何其他产品，因为 Release Pipeline 易于使用，产品所有者或项目经理可以批准和控制何时在不同环境中进行部署。此外，这些批准者可以免费获得“利益相关者”许可证。即使 GitHub 操作通过此功能毕业，我仍然必须向用户颁发企业许可证。

我宁愿为 Azure 静态 Web 应用程序 (SWA) 提供一个工作流，就像我为其他所有事情做的那样：

  1. 将代码推送到 GitHub 存储库中的“主”分支
  2. Azure Devops CI Pipeline 启动构建
  3. 构建 Angular 前端代码并将其保存到目录$(Build.ArtifactStagingDirectory)/web
  4. 构建dotnet函数后端代码并保存到目录$(Build.ArtifactStagingDirectory)/api
  5. 发布可用于发布管道的构建工件
  6. 发布管道 (CD) SWA 步骤将获取工件并将它们部署到 Azure SWA 环境

我知道 Azure DevOps 中的 SWA 发布步骤仍处于 0.X 版中，并且注意到它会随着时间的推移而发展。让我描述一下我的经历以及它是如何演变的：

  1. 大约一个月前，由于 Azure SWA 令牌不可用，它无法工作
  2. 这个问题已经解决了，我注意到它只能在 Linux 主机上运行（没什么大不了的）
  3. 运行 SWA 步骤的 docker 容器会出现以下错误：

泊坞窗：来自守护进程的错误响应：OCI 运行时创建失败：安装无效 {Destination::/working_dir Type:bind Source:/var/lib/docker/volumes/3b6743ba34608e986186d5057ae6cd4ed36a773d5ca9c9f2cb5fa8894f411c6d/_data 选项：[rbind]}：安装目标：/working_dir not绝对：未知。

  1. 要解决此问题，只需使用此代码在 SWA 步骤之前添加一个 Bash 步骤：（在此处归功于 Claire Novotny：https ://github.com/microsoft/azure-pipelines-tasks/pull/14807#issuecomment-868593099 ）
# Set this variable as the AzureStaticWebApp task is hard coded to read it.
echo '##vso[task.setvariable variable=BUILD_SOURCESDIRECTORY]$(System.DefaultWorkingDirectory)'
  1. 我认为最后一个问题是Microsoft Oryx（发布管道中 SWA 步骤背后的构建引擎）想要构建api 或识别已编译的语言。无论我做什么，我都无法让 Oryx 识别它是一个 dotnet 项目，并且它默认为节点：

Oryx 无法确定构建步骤。继续假设此文件夹中的资产已构建。如果这是意外行为，请联系支持人员。

无法检测到函数语言。语言将默认为节点。

这里有 Oryx 的文档：https ://github.com/microsoft/Oryx/blob/master/doc/configuration.md#oryx-configuration确实指出了 Oryx 可以被告知它是什么项目类型的可能性（在我的案例 dotnet）查看PLATFORM_NAME和PLATFORM_VERSION设置。我假设我将它放在发布管道的“ Api Build Command ”字段中，看起来 Oryx 识别它，但仍然想要识别模式并默认返回节点。

--platform dotnet --platform-version 3.1

我现在的解决方法是不在 CI 管道中构建 dotnet 函数应用程序，而是让 Oryx 每次我需要它作为 CD 管道的一部分部署到环境时构建它。这打破了我通过任何其他 Azure 资源部署实现的持续交付的“一次构建，随处部署”原则，并且想知道如何让 Oryx 不构建它，而是重用已经构建和编译的工件。

4

0 回答 0