时间戳

首页 > 解决方案 > 为什么我的 TeamCity 内部 NuGet 提要缺少部分 URL？

configuration - 为什么我的 TeamCity 内部 NuGet 提要缺少部分 URL？

问题描述

我的 TeamCity 服务器似乎为其内置的 NuGet 提要使用了损坏的 URL。

在此处输入图像描述

我正在使用官方 JetBrains 映像在 docker 容器中运行它。我不在反向代理后面。我已经配置了“服务器 URL”设置。

我可以使用完整的 URL（未经身份验证的访客访问）在 Visual Studio 中使用提要，这一切都很好。它从构建工件中添加包，Visual Studio 可以提取它们。

只是应该包含提要 URL 的 TeamCity 属性已损坏，如屏幕截图所示。所以我的构建失败是这样的：

/usr/share/dotnet/sdk/3.1.302/NuGet.targets(128,5)：错误：无法加载源 http://teamcity:8111/guestAuth/app/nuget/feed/TigraOss/ 的服务索引TigraOSS/v3/index.json。

这些是内部生成的，不是我编辑过的，所以我有点困惑。有想法该怎么解决这个吗？（显然，我已尝试重新启动服务器）。

更新

我认为这可能是因为一切都在 docker 容器中运行。稍后在参数屏幕中（在上面屏幕截图的底部）是另一行：

teamcity.serverUrl http://teamcity:8111

我认为这是来自我的docker-compose.yml文件：

  agent:
    image: jetbrains/teamcity-agent
    container_name: teamcity-agent
    restart: unless-stopped
    privileged: true
    user: "root"
    environment:
      - SERVER_URL=http://teamcity:8111
      - AGENT_NAME=ubuntu-ovh-vps-tigra
      - DOCKER_IN_DOCKER=start
    volumes:
      - agentconfig:/data/teamcity_agent/conf
      - agentwork:/opt/buildagent/work
      - agentsystem:/opt/buildagent/system
      - agent1_volumes:/var/lib/docker

我尝试更改docker-compose.yml文件中的 SERVER_URL 值并重新启动代理容器，但看起来一旦创建了代理配置文件，该值就是粘性的，我需要进入并手动编辑它。

现在我有代理使用服务器的完整 FQDN，所以我们将看看它是否有效。

标签： configurationnugetteamcity

解决方案

I think this is caused by my complicated docker-in-docker build. I am running TeamCity server and the linux build agent in docker containers built with docker-compose. Here's my docker-compose.yml file with secrets removed:

version: '3'

services:
  db:
    image: mariadb
    container_name: teamcity-db
    restart: unless-stopped
    env_file: .env
    volumes: 
      - mariadb:/var/lib/mysql
    command: --default-authentication-plugin=mysql_native_password

  teamcity:
    depends_on: 
      - db
    image: jetbrains/teamcity-server
    container_name: teamcity
    restart: unless-stopped
    environment:
      - TEAMCITY_SERVER_MEM_OPTS="-Xmx750m"
    volumes: 
      - datadir:/data/teamcity_server/datadir
      - logs:/opt/teamcity/logs
    ports:
      - "8111:8111"

  agent:
    image: jetbrains/teamcity-agent
    container_name: teamcity-agent
    restart: unless-stopped
    privileged: true
    user: "root"
    environment:
      SERVER_URL: http://fully.qualified.name:8111
      AGENT_NAME: my-agent-name
      DOCKER_IN_DOCKER: start
    volumes:
      - agentconfig:/data/teamcity_agent/conf
      - agentwork:/opt/buildagent/work
      - agentsystem:/opt/buildagent/system
      - agent1_volumes:/var/lib/docker

volumes:
  mariadb:
  datadir:
  logs:
  agentconfig:
  agentwork:
  agentsystem:
  agent1_volumes:

networks:
  default:

When I first created everything, I had the SERVER_URL variable set to `http://teamcity:8111". This works because Docker maps the host name to the service name, which is also 'teamcity' so that host is resolvable within the docker composition.

The problem comes when doing a build step inside yet another container. I am building .NET Core and the .NET SDK is not installed on the machine, so I have to run the build using the .NET Core SDK container.

The agent passes in the URL of the NuGet feeed, which is pointing to the docker service name, and the build container can't "see" that host name. I'm not sure why not. I tried passing in --network teamcity_default as a command line argument to docker run, but it says that network doesn't exist.

I found two ways to get things to work.

  1. Edit the build step to use the FQDN of the nuget feed, and don't use the teamcity built-in parameter %teamcity.nuget.feed.guestAuth.feed-id.v3%. I don't like this solution much because it sets me up for a breakage in the future.
  2. Find the docker volume where the teamcity agent config is stored. In my case, it was /var/lib/docker/volumes/teamcity_agentconfig/_data. Edit the buildAgent.properties file and set serverUrl=http\://fully.qualified.name\:8111. Then docker-compose restart agent. Then you can safely use %teamcity.nuget.feed.guestAuth.feed-id.v3% in containerized builds.

I haven't tested this, but I think you may be able to avoid all this in the first place by using a fully-qualified server name in the docker-compose.yml file. However you have to do this right from the start, because the moment you run docker-compose up the agent config filesystem is created and becomes permanent.

推荐阅读