[go: up one dir, main page]

Go Module Proxy Fails to Serve Correct Metadata for Nested Subprojects (Still Present in 17.10.3-ee)

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Description I’m encountering an issue with GitLab’s Go module proxying for a repository in a nested subproject. When querying a module in a nested namespace (e.g., group/subgroup/subproject), GitLab returns go-import metadata for the parent namespace (group/subgroup), resulting in a 404 error when Go attempts to fetch the module. This matches the behavior described in an existing issue: #390287 (closed), which remains unresolved as of GitLab 17.10.3-ee.

This issue is blocking my CI/CD pipeline, as Go cannot resolve the module dependency.

  1. Set up a GitLab instance (version 17.10.3-ee) with a nested project structure:

    • Create a group group.
    • Create a subgroup subgroup under group.
    • Create a project subproject under group/subgroup, so the full path is group/subgroup/subproject.

  2. In the subproject repository, create a Go module with the following go.mod:

    module gitlab.example.com/group/subgroup/subproject

go 1.22.5

  3. Tag the repository with a version, e.g.,v1.0.0.

  4. Query the Go module metadata:

    curl https://gitlab.example.com/group/subgroup/subproject?go-get=1

  5. In a separate Go project, add a dependency on the module:

    require gitlab.example.com/group/subgroup/subproject v1.0.0

  6. Attempt to download the module in a CI/CD pipeline using a Dockerfile:

    FROM golang:1.22.5-alpine

RUN apk update && apk add --no-cache curl git bash make

WORKDIR /auth

COPY go.mod ./
COPY go.sum ./

ENV GOPRIVATE=gitlab.example.com/*
ENV GOPROXY=https://proxy.golang.org,direct

ARG GITLAB_DEPLOY_TOKEN
RUN echo "machine gitlab.example.com login deploy-token-user password ${GITLAB_DEPLOY_TOKEN}" > ~/.netrc \
    && chmod 600 ~/.netrc
RUN git config --global url."https://deploy-token-user:${GITLAB_DEPLOY_TOKEN}@gitlab.example.com".insteadOf "https://gitlab.example.com"

RUN go mod download

COPY . .
WORKDIR /auth/engine/grpc
RUN go mod tidy
RUN go build -o /app
ENTRYPOINT ["/app"]

Expected Behavior

  • The curl command should return metadata for the full path:

    <meta name="go-import" content="gitlab.example.com/group/subgroup/subproject git https://gitlab.example.com/group/subgroup/subproject.git">

  • The go mod download command in the CI/CD pipeline should successfully fetch the module.

Actual Behavior

  • The curl command returns metadata for the parent namespace (group/subgroup):

    <html><head><meta name="go-import" content="gitlab.example.com/group/subgroup git https://gitlab.example.com/group/subgroup.git"></head><body>go get gitlab.example.com/group/subgroup</body></html>

  • The go mod download command fails with a 404 error:

     go: gitlab.example.com/group/subgroup/subproject@v1.0.0: unrecognized import path "gitlab.example.com/group/subgroup/subproject": reading https://gitlab.example.com/group/subgroup/subproject?go-get=1: 404 Not Found

Workaround

I moved the repository to a top-level namespace (group/subproject), which resolved the issue:

curl https://gitlab.example.com/group/subproject?go-get=1

Returns

<html><head><meta name="go-import" content="gitlab.example.com/group/subproject git https://gitlab.example.com/group/subproject.git"></head><body>go get gitlab.example.com/group/subproject</body></html>

However, this is not ideal, as I’d prefer to keep the repository under group/subgroup/subproject for organizational purposes.

Environment

  • GitLab Version: 17.10.3-ee
  • Revision: ed705b29
  • Operating System: Ubuntu 24.04
  • Ruby Version: 3.2.5
  • Go Version: 1.22.5 (used in the CI/CD pipeline)
  • External URL: https://gitlab.example.com (configured in /etc/gitlab/gitlab.rb)
  • Repository Storage: unix:/var/opt/gitlab/gitaly/gitaly.socket

Additional Context

  • This issue matches #390287 (closed), which was reported in February 2023 and remains unresolved.
  • Clearing the GitLab cache (sudo gitlab-rake cache:clear) and reconfiguring (sudo gitlab-ctl reconfigure) did not resolve the issue.
  • The repository group/subgroup/subproject exists and is correctly configured, with the go.mod declaring the correct module path.

Suggested Fix

GitLab should update its Go module proxying logic to correctly handle nested subprojects, ensuring the go-import metadata reflects the full repository path (group/subgroup/subproject) rather than resolving to the parent namespace (group/subgroup).

Priority

This issue is blocking CI/CD pipelines for projects relying on Go modules in nested subprojects, requiring users to reorganize their repository structure or use replace directives in go.mod as workarounds. A fix would improve the developer experience for Go users on GitLab.

Edited by 🤖 GitLab Bot 🤖