go-get=1 404 response on private golang modules

[ajhcpt]

Hi, I've run into another issue with our privately hosted go modules. Our setup is:

• Self hosted instance of Artifactory
• Proxy for both external and our own internally build modules

As per this diagram:

our own interally build dependencies have a path like: "test.net/validation".

Renovate gets the version list using the GOPROXY environment variable:
https://private.artificatory.test.net/artifactory/api/go/go-remote-repo/test.net/validation/@v/list

Then it tries to get the Datasource via:

  private static async goGetDatasource(
    goModule: string
  ): Promise<DataSource | null> {
    const pkgUrl = `https://${goModule}?go-get=1`;
    // GitHub Enterprise only returns a go-import meta
    const res = (await BaseGoDatasource.http.get(pkgUrl)).body;
    return (
      BaseGoDatasource.goSourceHeader(res, goModule) ??
      BaseGoDatasource.goImportHeader(res, goModule)
    );
  }

the pkgUrl that is built up is https://test.net/validation?go-get=1. However we are not serving anything at this URL and so the request times out.

Is there a way to workaround this with configuration?

[rarkins]

From a quick code review it looks like Renovate is trying to fetch directly in order to get the sourceUrl for the package, which is so that it can fetch release notes.

What is the impact of it timing out? Does it error quickly or slowly? And does it result in the job being aborted, or continuing?

[ajhcpt]

Hi @rarkins, the timeout takes the full 60 seconds its allowed, but I'm not too concerned about that now. The job as a whole completes, but it gives up on trying to identify the dependencies for all of our internal dependencies i.e test.net/mymodule. No PRs are created for these specific dependencies and we get this error on the dashboard:

⚠ Dependency Lookup Warnings ⚠

• Renovate failed to look up the following dependencies: test.net/validation, test.net/http-middleware/v2, test.net/logging

Files affected: go.mod

---

[rarkins]

You should be able to reduce the timeout by setting a hostRules entry with matchHost and timeout, but that will of course just speed up the error.

If we are only using this failing query for getting the sourceUrl, I think it should be safe to try/catch it and keep going. You would be welcome to submit a feature request or Pull Request along these lines

[ajhcpt]

Thanks. I'll try put together a PR sometime this week, if I'm not successful I'll log a feature request.