【问题标题】:Gitlab-Runner Windows service: build with administrative priviledgesGitlab-Runner Windows 服务:使用管理权限构建
【发布时间】:2022-01-03 10:49:48
【问题描述】:

问题

  • 如果在本地终端中运行以“以管理员身份运行”开始,则构建服务器上 Powershell 中的 gitlab-runner 成功完成(vb6.exe、devenv.com、msbuild.exe),而在配置为 Windows 服务运行时出现错误作为本地管理员

期望的行为

  • 通过 gitlab-runner 作为 Windows 服务在隔离的构建服务器上构建具有管理权限的项目(vb6.exe、devenv.com、msbuild.exe)

配置

  • Windows Server 2019,Gitlab-Runner v.14.3.2 64bit,powershell 模式,使用本地管理员帐户运行服务
  • Visual Studio (VS) 版本需要管理员权限才能实现 VB6 UI (VS VB98) 和 VB6/C# (VS 2019) 项目之间的互操作性。如果在 VS 解决方案的子项目中选择了 interopt-mode,则在构建 VS 时会在 Windows 注册表中写入(因此必须具有管理员权限)。

试用

  • 安装了 gitlab-runner 作为https://docs.gitlab.com/runner/install/windows.html推荐的服务

  • 暂时停用用户帐户控制但未成功

  • 改编 gitlab-ci.yml 以使用 Powershell 命令 Start-Process -Verb runAs -Wait devenv.com ... 调用 vb6.exe、devenv.com 和 msbuild.exe,但由于 Start-Process 似乎只接受带有 @987654326 的应用程序而导致 devenv.com 出错@ 作为文件结尾。 devenv.exe 正在工作,但没有通过 Start-Process 返回/关闭新的终端会话,最终导致挂起的 gitlab-ci-build-script。此外,构建脚本的终端消息不再可见,因为它们正在由Start-Process 创建的新终端会话中运行。

  • 停用 gitlab-runner 服务并通过 Windows 自动启动文件夹启动:运行 Powershell 脚本:Start-Process -FilePath D:\development\gitlab-runner\gitlab-runner -ArgumentList 'run --working-directory D:\development\gitlab-runner --config D:\development\gitlab-runner\config.toml --service gitlab-runner --syslog' -Verb runAs -Wait,但配置的用户需要在每次系统启动时登录,这不是构建服务器的预期行为。

  • gitlab-runner.exe/vb6.exe/devenv.exe/msbuild.exe - 右键单击​​ - 属性 - 兼容性 - 更改所有用户的设置 - 复选框:为所有激活的用户以管理员身份运行 - 没有改变描述的行为

gitlab-ci.yml

stages:
  - deploy

variables:
  PLATFORM: 'x86'
  CONFIGURATION: 'Release'

myproject:
  stage: deploy
  when: manual
  tags: [deploying]
  script:
    - Start-Process MSBuild.exe -Wait -Verb runAs -Argument 'AutomatedSetupBuild.proj'
    - Start-Process devenv.com -Wait -Verb runAs -ArgumentList ".\mysolution.sln /Rebuild `"$CONFIGURATION|$PLATFORM`" /Project .\myproject\myproject.vbproj /ProjectConfig `"$CONFIGURATION|$PLATFORM`" /Log"
    - Start-Process vb6.exe -Wait -Verb runAs -ArgumentList "/make `".\vbproject.vbp`" /out `"$env:TEMP/vb6-buildoutput.log`""

【问题讨论】:

  • 您是否尝试过将服务作为内置 SYSTEM 主体运行?
  • 是的,按照docs.gitlab.com/runner/install/windows.html 的说明,如果 gitlab-runner 从带有“以管理员身份运行”的 shell 启动,则内置系统帐户步骤仅适用,但所需的行为是让它作为服务运行,目前 gitlab-runner 由于缺少管理权限而在错误中运行(在项目构建期间)
  • 在服务面板的服务属性-> 登录选项卡-- 服务登录是如何配置的?它应该设置为使用系统主体(或具有适当权限的管理员用户帐户)。
  • 我们都试过了,安装为本地管理员,没有在服务选项卡中进行登录配置,但没有成功。只有当我们使用 D:\development\gitlab-runner\gitlab-runner run --working-directory D:\development\gitlab-runner --config D:\development\gitlab-runner\config.toml --service gitlab-runner --syslog 在提升的 shell 中手动启动服务时,它仍然有效。

标签: windows-services gitlab-ci gitlab-ci-runner administrator


【解决方案1】:

对我有用的是给我打算安装运行器的用户作为服务登录的权利。转到控制面板 -> 管理工具 -> 本地安全策略 -> 安全设置 -> 本地策略 -> 用户权限分配 -> 作为服务登录。你需要将你安装gitlab-runner的用户添加到列表中,包括本地域,然后根据https://docs.gitlab.com/runner/install/windows.html安装runner,同样使用带域的完整用户名。

【讨论】:

  • 非常感谢您的支持!现在构建继续进行,直到 > 错误 MSB6006: "lc.exe" exited with code -1 如果我使用管理权限构建,则不会发生这种情况。在我看来,构建用户在作为 Windows 服务运行时仍然没有足够的权限。
  • 听起来您可能在使用 GUI 应用程序时遇到了问题?如果您探索权限,可能有一个更彻底的解决方案,但我快速而肮脏的技巧是使用与安装 gitlab 运行器相同的凭据登录到构建机器。
猜你喜欢
  • 1970-01-01
  • 2020-09-13
  • 2018-03-02
  • 1970-01-01
  • 2011-04-27
  • 2014-05-31
  • 2019-11-21
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多