The Prompt Library lets you create, share, and browse chat prompts for
use with Cody. Prompts are owned by users or organizations, and site
admins can make prompts public so that all users on the instance can see
and use them.
A prompt is just plain text for now, and you can see a list of prompts
in your Prompt Library from within Cody chat
(https://github.com/sourcegraph/cody/pull/4903).
See https://www.loom.com/share/f3124269300c481ebfcbd0a1e300be1b.
Depends on https://github.com/sourcegraph/cody/pull/4903.
## Test plan
Add a prompt on the web. Ensure you can access it from Cody.
## Changelog
- The Prompt Library lets you create, share, and browse chat prompts for
use with Cody. Prompts are owned by users or organizations, and site
admins can make prompts public so that all users on the instance can see
and use them. To use a prompt from your Prompt Library in Cody, select
it in the **Prompts** dropdown in the Cody chat message field.
This updates the consts that control upgradeReadiness i.e. banners and
latest version indicators
<!-- 💡 To write a useful PR description, make sure that your description
covers:
- WHAT this PR is changing:
- How was it PREVIOUSLY.
- How it will be from NOW on.
- WHY this PR is needed.
- CONTEXT, i.e. to which initiative, project or RFC it belongs.
The structure of the description doesn't matter as much as covering
these points, so use
your best judgement based on your context.
Learn how to write good pull request description:
https://www.notion.so/sourcegraph/Write-a-good-pull-request-description-610a7fd3e613496eb76f450db5a49b6e?pvs=4
-->
## Test plan
no test
<!-- All pull requests REQUIRE a test plan:
https://docs-legacy.sourcegraph.com/dev/background-information/testing_principles
-->
## Changelog
- tmp process: update release consts to 5.4.5099
<!--
1. Ensure your pull request title is formatted as: $type($domain): $what
2. Add bullet list items for each additional detail you want to cover
(see example below)
3. You can edit this after the pull request was merged, as long as
release shipping it hasn't been promoted to the public.
4. For more information, please see this how-to
https://www.notion.so/sourcegraph/Writing-a-changelog-entry-dd997f411d524caabf0d8d38a24a878c?
Audience: TS/CSE > Customers > Teammates (in that order).
Cheat sheet: $type = chore|fix|feat $domain:
source|search|ci|release|plg|cody|local|...
-->
<!--
Example:
Title: fix(search): parse quotes with the appropriate context
Changelog section:
## Changelog
- When a quote is used with regexp pattern type, then ...
- Refactored underlying code.
-->
* Anish's post pairing suggestions modified
* Check first version in migrations, propegate first version through upgradeReadinessCheck
* get the version from the db instead of the frontend version string from build
* display only migrations which are not deprecated before the insances initialization
* sg bazel configure
* fix isRequired test
* fix graphql imports
* fix SiteAdminMigrationsPage.story.tsx
* capitulate to eslints biases
* address review feedback
* resolve branch conflict in import
* add clarifying comment
* fix resolver variables
Go 1.22 changes loop variables to have more sensible
semantics where the variable is not reused across iterations
by the codegen, so we can simplify a bunch of code
working around that counterintuitive behavior.
I noticed the `telemetry.constString` type was wrongly exported in a previous PR (https://github.com/sourcegraph/sourcegraph/pull/61134). This type is intentionally unexported to prevent the exact use case the PR used the exported type for - this scenario (list keys and include it in metadata) is exactly the scenario where something bad might unexpectedly show up in our telemetry (an unexpected Redis key is matched, an unexpected value is provided to be stored, etc - the cause of multiple data leakage incidents in the past)
However, given the format I was unable to quickly come up with a better alternative. Moving it to private metadata is also not possible, as because judging from the description of #61134 we need this to be exported from on-prem as a business need.
For now:
1. Add loud warnings on the various intentionally-internal types to not export them
2. Add a constructor `telemetry.SafeMetadataKey(...)` to support the current use case, with warnings - callers more or less "sign off" on owning problems here if there are any. In the future if we have any regex strategy we want to apply we can add them to these constructors as well.
3. Add CODEOWNERS to make sure changes to telemetry do not go without adequate review
## Test plan
CI
Simple refactor, moved the methods into internal/dotcom so that we don't import across package boundaries.
Simply moved code, existing test suites will find issues.
Cody no longer needs it and it is obsolete now!
Since App added a non-insignificant amount of new concepts and alternative code paths, I decided to take some time and remove it from out codebase.
This PR removes ~21k lines of code. If we ever want parts of single binary (app), the redis kv alternatives, or the release pipeline for a native mac app back, we can look back at this PR and revert parts of it, but maintaining 21k lines of code and many code paths for which I had to delete a surprisingly small amount of tests justifies this move for me very well.
Technically, to some extent SG App and Cody App both still existed in the codebase, but we don't distribute either of them anymore, so IMO we shouldn't keep this weight in our code.
So.. here we go.
This should not affect any of the existing deployments, we only remove functionality that was special-cased for app.
We currently don't call `Stop` on the pub/sub client, which is pretty important because I think it actually does buffering by default: https://sourcegraph.com/github.com/googleapis/google-cloud-go@6eb769621618a965abeabf11e6315bdb8be9b050/-/blob/pubsub/topic.go?L122-137
This change adds a `TopicPublisher` interface with write-only methods so that we don't accidentally Stop the client at callsites, and adds a Stop to telemetry-gateway. I'll follow up with another change to update Pings to the MSP runtime and apply a Stop there as well
This change adds standard godoc deprecation warnings (`// Deprecated: ...`) on the _many_ legacy event-logging entry points in the backend. These are rendered prominently in VSCode (and presumably other IDEs) and will also trigger a CI failure if a deprecated function is used without a `//lint:ignore SA1019` directive ([`SA1019` is the error code for deprecated function usage](https://staticcheck.dev/docs/checks/#SA1019)). The goal is primarily to discourage new usages, and mark existing usages that will need to be migrated, so this PR adds `//lint:ignore SA1019` docstrings at all existing callsites.
I've also added a deprecation warning on the `logEvent` and `logEvents` mutations in the GraphQL schema.
Closes https://github.com/sourcegraph/sourcegraph/issues/56973 - in the web app and Cody repo, we already use JSDoc deprecation notices.
* log: remove use of description paramter in Scoped
* temporarily point to sglog branch
* bazel configure + gazelle
* remove additional use of description param
* use latest versions of zoekt,log,mountinfo
* go.mod
This updates variable names, property names, env var names, etc., to call it "Cody App".
The entire diff was created by running the following commands:
```
fastmod -e go SourcegraphAppMode CodyAppMode
fastmod -e go,ts,tsx sourcegraphAppMode codyAppMode
fastmod -e ts,tsx isSourcegraphApp isCodyApp
fastmod -e ts,tsx,go,yaml,sh,js SOURCEGRAPH_APP CODY_APP
fastmod -e ts,tsx,go,json,mod,graphql,md,js 'Sourcegraph App\b' 'Cody App'
fastmod -e ts,tsx,go,json,mod,graphql,md,js 'Sourcegraph app\b' 'Cody app' # with a few changes skipped
```
The content of this file is the size of all repos combined per shard. We update it in the janitor after all repos are processed, but at the same time we collect the same sizes per repo and write them to gitserver_repos.repo_size_bytes. This didn't exist back when the file was introduced, but nowadays, they are pretty much equal. An additional benefit is that other processes that update the repo size in the DB will also reflect faster in the value read here. This removes a bunch of complexity around managing that file, maintaining endpoints to retrieve that data, and around talking to every gitserver to get the cumulated value.
Proof: On dotcom, where 1 gitserver holds roughly 15.5TB of repo data, the calculated value in the file and the value from the DB only differ by 175MB (0.001076729067%).
Please let me know if I am missing some nuance here and those numbers are not actually the same!
With quarterly releases, we can only remove some of the remaining endpoints code in 5.3, to keep compatibility.
There are exactly two things that use this endpoint:
A GraphQL resolver that returns the total git size
If the frontend comes up first, it just uses the DB, which is already populated correctly long ago
If the new gitserver comes up first, it will still have the endpoints but read from the DB, so no problem here
The usagestats code, that collects pings data regularly
If the frontend comes up first, this is not a problem as the DB is already populated correctly and it's read from there
If the gitserver comes up first, it will still have the endpoints but read from the DB, so no problem here
After recent changes, I don't think we will have the capacity to move this over the finish line and it doesn't seem to be a high priority. Let's close this out for now and revisit later if needed.
We'll have all the writeups we made and this diff for future inspiration.
This PR refactors the `internal/updatecheck` package a bit so that the
global state to store the Pub/Sub client is removed (the result of the
preceding PR https://github.com/sourcegraph/sourcegraph/pull/55524), and
can be pass down to lower-level helper function as an argument.
This is necessary for
https://github.com/sourcegraph/sourcegraph/pull/55467 to hold a Pub/Sub
client on the call site in order to use `pubsub.TopicClient`'s helper
functions (i.e. `Ping`) while still being able to reuse most of the code
logic from the `internal/updatecheck` package.
## Test plan
CI
This removes a bunch of properties from the list of ones that will show
the site-admin a banner that they need to restart their server, because
they don't actually do (anymore).
This hopefully reduces the number of times an admin has to interrupt
their workflow to go into the infra and restart. This will also benefit
cloud ops where the customer cannot do it themselves.
Reasoning for removal: **Please help me vet that I am not wrong here!!**
- `gitHubApp`: This property is deprecated and not used anymore.
- `codeIntelAutoIndexing.enabled`: This one does not require a server
restart, all the background jobs will be running, but return early. The
next run they will just work as expected. It does require a page
refresh, but that's handled in the SiteAdminConfigurationPage.
- `extensions`: Property no longer exists.
- `auth.sessionExpiry`: This value is used in conf.ContributeValidator
and on the request path for SetActor, it's reading the value dynamically
so this should not require a restart.
- `auth.accessTokens`: Always read dynamically in resolvers/http
handlers. Requires a page refresh, but not a server restart.
- `auth.userOrgMap`: Just used on the user create request path, read
dynamically.
- `update.channel`: Fixed by reading the value on each iteration vs not
starting the ticker.
- `git.cloneURLToRepositoryName`: Uses conf.Cached, should not require a
server restart. None of the accessors of the value seem to cache it
anyhow.
- `searchScopes`: Changelog says this was removed, and it doesn't exist
anymore in the site.schema.json file.
Maybe next time we can get rid of the remaining ones and entirely
eliminate this mechanism for our admins!
## Test plan
Read code carefully to verify that these properties actually don't
require a server restart.
