Skip to content

frontend: add a dot-com API endpoint caching src versions by branch

Warren Gifford requested to merge aharvey/version-cache-backend into main

Created by: LawnGnome

This PR adds a simple version cache to the unauthenticated external REST API that reports the most recent version of src-cli for the given branch. This is the backend that will address #39468, but #40828 also has to be merged for this to be fully fixed.

The intention is that the sourcegraph.com deployment will enable the cache, and no other deployments will ever configure it.

The minimal configuration that will be required on sourcegraph.com will be:

{
  "dotcom": {
    "srcCliVersionCache": {
      "enabled": true,
      "github": {
        "token": "TOKEN",
        "webhookSecret": "WEBHOOK_SECRET"
      }
    }
  }
}

This will need to be combined with a GitHub webhook on https://github.com/sourcegraph/src-cli that points to https://sourcegraph.com/.api/src-cli/versions/webhook, configured with the same WEBHOOK_SECRET and with the release event type enabled.

Probable questions

Why not use the SOURCEGRAPHDOTCOM_MODE environment variable?

This PR adds a small configuration section to the dotcom site configuration object that enables and configures the cache, but does not use the SOURCEGRAPHDOTCOM_MODE environment variable.

This is both to simplify testing and reduce the matrix of possible configuration options. With this implementation, there are only two possible states: configuration present and enabled, in which case this API will respond, and literally anything else, in which case this API will 404 like any other unknown endpoint.

Why is the handler always installed?

Originally, I had the handler only conditionally hooked up if the configuration was enabled. However, it's considerably simpler if it's always present, since it means we can handle all the enable/disable behaviour in a single configuration watcher, and from a user perspective the disabled handler is indistinguishable from the route not existing in the router.

Test plan

This has (IMHO) good test coverage, and I've given it a pretty good hammering in the last day or so locally as part of developing this and #40828.

Merge request reports