我需要我的CI开始的PR号。我正在使用System.PullRequest.PullRequestNumber,但当我的CI运行时,它显示空字符串。
Write-Host“PR Number is:-”$env:System.PullRequest.PullRequestNumber
我没有通过保存和队列运行此配置项。完成PR流程后。
kh212irz1#
如何从Azure构建管道(CI)中的预定义变量获取拉取请求编号首先,就像文档System variables状态一样:
变量System.PullRequest.PullRequestNumber来自GitHub。我们应该使用System.PullRequest.PullRequestId。因此,我们可以使用语法$(System.PullRequest.PullRequestId)来获取值:
System.PullRequest.PullRequestNumber
System.PullRequest.PullRequestId
$(System.PullRequest.PullRequestId)
Write-Host "PR ID is:-" $(System.PullRequest.PullRequestId)
此外,基于Understand变量语法文档当变量转换为环境变量时,变量名变为大写,句点变为下划线。例如,变量any.variable变为$ANY_VARIABLE因此,如果您获取环境变量$env:System_PullRequest_PullRequestId而不是$(System.PullRequest.PullRequestId)因此,脚本应该是:
$env:System_PullRequest_PullRequestId
Write-Host "PR ID is:-" $env:System_PullRequest_PullRequestId
这就是为什么System.PullRequest.PullRequestId不适合你的原因。希望这能帮上忙。
fruv7luv2#
试试这个:写入主机“PR编号为:-”$(System.PullRequest.PullRequestId)
编辑
根据documentation,System.PullRequest.PullRequestNumber是从GitHub填充的,你确定你需要这个吗?和System.PullRequest.PullRequestId:导致此生成的拉取请求的ID。例如:17.(只有当构建由于受分支策略影响的Git PR而运行时,此变量才会初始化。)
sg3maiej3#
$(System.PullRequest.PullRequestId)仅在构建由于受分支策略影响的Git PR而运行时初始化。根据documentation,该变量也仅在经典管道(而不是YAML)中可用。您可以从以下位置提取PullRequestId:
PullRequestId
"$(RELEASE.ARTIFACTS.*YOURARTIFACTNAME*.SOURCEBRANCH)"
gajydyqb4#
您可以通过System.PullRequest.PullRequestNumber获取PR号码。例如,我在GitHub上有一个pull request,其编号为:
对于此PR Write-Host $(System.PullRequest.PullRequestId),返回了1030194803Write-Host $(System.PullRequest.PullRequestNumber)返回63。
Write-Host $(System.PullRequest.PullRequestId)
Write-Host $(System.PullRequest.PullRequestNumber)
ddhy6vgd5#
只有在GitHub上运行由PR触发的构建时,这才对我有效。如果您的构建是在PR上下文之外触发的,例如在合并PR之后,则此变量将不可用。发生这种情况是因为在Azure DevOps上,无法在PR合并时触发构建:Azure DevOps上的PR触发器仅在创建和更新PR时起作用。因此,在上面的示例中,当您合并到master时,实际触发构建的是CI触发器。如果你的代码托管在GitHub上,就像我的例子一样,你可以在GitHub上创建一个工作流,只在PR合并时触发,然后在那里执行你想要的逻辑。
on: pull_request: types: - closed branches: - master jobs: merged-pr: if: github.event.pull_request.merged == true runs-on: ubuntu-latest steps: - run: | echo This is the PR ${{ github.event.number }}
重要的是要理解,此管道将在PR合并到主服务器时触发,而Azure管道上的CI触发器也将在您推送到主服务器时触发-如果以这种方式配置。因此,当合并到master时,Azure DevOps管道和GitHub工作流将同时触发。如果这不正常,您可以通过关闭管道上的CI触发器并从GitHub工作流触发构建来防止这种情况发生。这可以通过以下命令实现:
az pipelines build queue --definition-name $azure_devops_pipeline_name --organization $azure_devops_organisation_url --project $project_name --branch master
在我的例子中,我需要Azure DevOps管道上的PR号,所以我使用了一个变量组。在触发管道之前,我在GitHub工作流上运行的逻辑就是在一个组变量中更新这个数字。下面的命令应该可以做到这一点。
az pipelines variable-group variable update --organization $azure_devops_organisation_url --project $project_name --group-id $azure_devops_variable_group_id --name $azure_devops_variable_name --value ${{ github.event.number }}
5条答案
按热度按时间kh212irz1#
如何从Azure构建管道(CI)中的预定义变量获取拉取请求编号
首先,就像文档System variables状态一样:
变量
System.PullRequest.PullRequestNumber
来自GitHub。我们应该使用System.PullRequest.PullRequestId
。因此,我们可以使用语法
$(System.PullRequest.PullRequestId)
来获取值:此外,基于Understand变量语法文档
当变量转换为环境变量时,变量名变为大写,句点变为下划线。例如,变量any.variable变为$ANY_VARIABLE
因此,如果您获取环境变量
$env:System_PullRequest_PullRequestId
而不是$(System.PullRequest.PullRequestId)
因此,脚本应该是:
这就是为什么
System.PullRequest.PullRequestId
不适合你的原因。希望这能帮上忙。
fruv7luv2#
试试这个:
写入主机“PR编号为:-”$(System.PullRequest.PullRequestId)
编辑
根据documentation,System.PullRequest.PullRequestNumber是从GitHub填充的,你确定你需要这个吗?
和System.PullRequest.PullRequestId:
导致此生成的拉取请求的ID。例如:17.(只有当构建由于受分支策略影响的Git PR而运行时,此变量才会初始化。)
sg3maiej3#
$(System.PullRequest.PullRequestId)
仅在构建由于受分支策略影响的Git PR而运行时初始化。根据documentation,该变量也仅在经典管道(而不是YAML)中可用。您可以从以下位置提取
PullRequestId
:gajydyqb4#
您可以通过
System.PullRequest.PullRequestNumber
获取PR号码。例如,我在GitHub上有一个pull request,其编号为:
对于此PR
Write-Host $(System.PullRequest.PullRequestId)
,返回了1030194803Write-Host $(System.PullRequest.PullRequestNumber)
返回63。ddhy6vgd5#
只有在GitHub上运行由PR触发的构建时,这才对我有效。如果您的构建是在PR上下文之外触发的,例如在合并PR之后,则此变量将不可用。
发生这种情况是因为在Azure DevOps上,无法在PR合并时触发构建:Azure DevOps上的PR触发器仅在创建和更新PR时起作用。
因此,在上面的示例中,当您合并到master时,实际触发构建的是CI触发器。
如果你的代码托管在GitHub上,就像我的例子一样,你可以在GitHub上创建一个工作流,只在PR合并时触发,然后在那里执行你想要的逻辑。
重要的是要理解,此管道将在PR合并到主服务器时触发,而Azure管道上的CI触发器也将在您推送到主服务器时触发-如果以这种方式配置。因此,当合并到master时,Azure DevOps管道和GitHub工作流将同时触发。
如果这不正常,您可以通过关闭管道上的CI触发器并从GitHub工作流触发构建来防止这种情况发生。这可以通过以下命令实现:
在我的例子中,我需要Azure DevOps管道上的PR号,所以我使用了一个变量组。在触发管道之前,我在GitHub工作流上运行的逻辑就是在一个组变量中更新这个数字。下面的命令应该可以做到这一点。