Unable to upload project by build token

After running lhci wizard successfully, I get the resulting build token to use for uploading. Collecting data with lhci autorun works as expected except the get project by token API doesn’t work (404):

// client cli config
upload: {
      target: 'lhci',
      serverBaseUrl: 'https://custom-server.com/lighthouse',
      token: TOKEN,
      basicAuth: {
        username,
        password
      }
    }

✅  .lighthouseci/ directory writable
✅  Configuration file found
✅  Chrome installation found
✅  Ancestor hash determinable
✅  LHCI server reachable
⚠️   LHCI server not API-compatible
⚠️   LHCI server token invalid
✅  LHCI server unique build for this hash
Healthcheck passed!

....successful audit completes

Error: Could not find active project with provided token
    at runLHCITarget (/Users/jflayhart/.nvm/versions/node/v13.12.0/lib/node_modules/@lhci/cli/src/upload/upload.js:380:11)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async Object.runCommand (/Users/jflayhart/.nvm/versions/node/v13.12.0/lib/node_modules/@lhci/cli/src/upload/upload.js:572:16)
    at async run (/Users/jflayhart/.nvm/versions/node/v13.12.0/lib/node_modules/@lhci/cli/src/cli.js:92:7)
WARNING: upload command failed.
assert command failed. Exiting with status code 1.

I have curl’d some project endpoints y’all use in your source code and /projects returns this:

// GET https://custom-server.com/lighthouse/v1/projects
[
    {
        "id": "123-abc",
        "name": "repo-name",
        "token": "", // empty!
        "adminToken": "", // empty (although not set in GUI)
        ...
    }
]

Any ideas what could be going on with project creation? I am definitely using the correct build token that was provided from wizard and PostGres is stable.

EDIT: I just found you clear the tokens in response intentionally, which is sane: https://github.com/GoogleChrome/lighthouse-ci/blob/master/packages/server/src/api/routes/projects.js#L27

So I tried POST https://custom-server.com/lighthouse/v1/projects/lookup with token and get 200:

{
    "id": "123-abc",
    "name": "repo-name",
    "token": "ACTUAL TOKEN",
    ...
}

lol what gives?

[patrickhulce]

is it assuming that the client config and server config co-exist in one rc file?

No, not necessarily. Just that by far the predominant deployment method has people accessing the UI through the same origin that they upload to.

e.g. we use https://lhci-canary.herokuapp.com we go to that URL to see the UI and it’s the same URL that the server uploads to. There’s no real fancy split in the LHCI server code for the backend and the UI, so it’s always hitting the same server and most people thusfar use the same URL when using both. Because of that we don’t want to enable a configuration early on that will inevitably break later when they try to look at their data.

The VPN setup is very cool though, and it makes sense. I’m open to enabling this if we just document how to accomplish the other half so people don’t end up shooting themselves in the foot.

[jflayhart]

Help me understand something, but is it assuming that the client config and server config co-exist in one rc file? Cause then I think I get your point, if we set a serverBaseUrl for both client CLI and server, the server needs to access the origin for reasons (ie static assets). but even then, If I create a url override, I would expect it to honor that.

Although I am operating under multiple client-side projects connecting to this separate CI server where the baseUrl config per client is decoupled from lhci server setup; at that point, I would argue serverBaseUrl should be used in its entirety (the full url, not just origin). I’m not understanding why we need the origin or host for the CLI use case? Can’t it just use what we tell it to use by setting serverBaseUrl? Trying to understand that bit…