Tags from sourcegraph

v5.1.5

2023-07-26T19:40:54Z

v5.1.5-rc.1

2023-07-26T18:28:54Z

v5.1.4

2023-07-17T23:07:39Z

v5.1.4-rc.1

2023-07-17T17:52:19Z

v5.1.3

2023-07-12T23:31:11Z

v5.1.3-rc.1

2023-07-12T22:38:24Z

app-v2023.7.11+1384.7d20a90ce7: graphqlbackend: update throttled to use Ctx stores (#54748)

2023-07-11T15:59:22Z

graphqlbackend: update throttled to use Ctx stores (sourcegraph#54748)

It seems we were using a weird version of throttled which I don't think
was actually based on the v2 series correctly. This updates us to the
latest version and moves us away from the removed struct GCRARateLimiter
and the deprecated interface GCRAStore.

I came across this while attempting to update deps and getting failing
compiles.

Test Plan: we have unit tests for this, so CI.

app-v2023.7.5+1333.e2d4e003e0: cody-gateway/events: do not let bufferedLogger.Stop time out (#54598)

2023-07-05T21:37:06Z

cody-gateway/events: do not let bufferedLogger.Stop time out (sourceg…

…raph#54598)

We want to make sure we ~never drop anything, so let's just allow
buffered events logger to work for longer to process all events.

## Test plan

n/a

app-v2023.7.4+1332.fc76a9c675: app: resolve port :9000 conflicts (change to :49000) (#54466)

2023-07-04T20:06:33Z

app: resolve port :9000 conflicts (change to :49000) (sourcegraph#54466)

Apparently VS Code's Python support uses port 9000, so as long as we use
it most VS Code Python devs can't run the app due to the port conflict
with our services.

This PR switches the app's blobstore to listen on `:49000` instead of
`:9000`. My thinking for now is that we can centralize all "default
endpoint" and "what host/port should I listen on?" into the `deploy`
package, and for now just change ports to have a `4` in front of them to
reduce the change of conflicts.

Later, once we have them centralized in the `deploy` package we can
easily modify that code to pick an unavailable port.

This also binds blobstore to `127.0.0.1` (more secure), previously it
was bound to `localhost`.

## Test plan

To test this I did the following:

1. [x] Methodically searched our codebase for `9000` and vetted each
instance, to ensure I didn't miss anything.
2. [x] Tested with `sg start app` and confirmed `sudo lsof -i -P | grep
LISTEN | grep :9000` reported nothing while `sudo lsof -i -P | grep
LISTEN | grep :49000` did.
3. [x] Created an app build with `./enterprise/dev/app/build.sh` and
tested it:
* [x] Confirmed embeddings generation (which get stored in blobstore)
still works through the setup wizard
4. [x] Confirmed `sg start enterprise-codeintel` starts and runs

Signed-off-by: Stephen Gutekanst <[email protected]>

v5.1.2

2023-07-03T19:33:47Z