Fixes srch-858
Currently the menu icon rotates when hovering over it. The animation
should only target the Sourcegraph logo.
Additional changes:
- Move icon color style prop into CSS declaration (avoids inserting an
additional element)
- Let the animation target the link instead of the icon. There doesn't
seem to be reason why we actually need to target the `svg` element via
`:global`.
## Test plan
Manual testing.
There currently isn't a 'one step' way to start a local Sourcegraph
instance with the SvelteKit app.
This commit adds `sg start enterprise-sveltekit` to fix that.
The changes in https://github.com/sourcegraph/sourcegraph/pull/64272
allow us to run the vite dev server in front of the Sourcegraph
instance, instead of building the assets and having them served by
frontend.
This gives us the benefit of hot module reloading and in general seems
to be a less fragile approach.
It's basically the same what we do with the React app in development
mode.
## Test plan
`sg start enterprise-sveltekit` starts the vite dev server as well as
the sourcegraph instance. Navigating to
`https://sourcegraph.test:3443/search` opens the Svelte app (when
enabled and logged in). Making a change in a source file updates the web
page immediately.
`sg start web-sveltekit-standalone` still works
I don't know why but having `overflow-x` causes the content of the
hovercard to not fully expand to the edges. It has something to do with
the sizing of the `hr` element.
## Test plan
Manual testing.
This commit adds the necessary logic to open the explorer tab for
multiple references and for implementations. I basically copied what
@camdencheek did for the references tab.
## Test plan
Hover over `adapt` in
http://localhost:5173/github.com/sveltejs/kit@65931f276ac2102032e3032c864a472eee19b7bb/-/blob/packages/kit/src/exports/vite/index.js?L890
and click 'got to definition'. The explore panel with should open with
the definitions tab selected.
I wasn't able to test the find implementations logic because I don't
know for which language we have this implemented.
The screenshot images for the welcome overlay (both in Svelte and React)
are quite large.
In Svelte specifically, because they are implemented as Svelte
components, this adds a lot of code to the root layout and makes the
bundle quite large.
This commit converts the Svelte components to image files and passes
them (and the React ones) through [svgo](https://github.com/svg/svgo).
On one hand that makes the images much smaller, on the other hand in
Svelte the images are now independent of the JS code and can be loaded
separately (the React app was already using an `img` element).
Before svgo:
```
$ ls src/lib/assets/
total 3.1M
5.1K Aug 7 18:45 sourcegraph-logo.svg
1.5M Aug 7 18:46 welcome-screenshot-dark.svg
1.6M Aug 7 18:46 welcome-screenshot-light.svg
```
After svgo:
```
$ ls src/lib/assets/
total 1.4M
5.1K Aug 7 18:45 sourcegraph-logo.svg
667K Aug 7 18:50 welcome-screenshot-dark.svg
667K Aug 7 18:50 welcome-screenshot-light.svg
```
## Test plan
I temporarily changed the code so that the welcome dialog is always
shown in the Svelte app and inspected the image. It still seems to look
the same.
This makes some requested changes to the welcome banner.
Notably:
- We no longer show the dialog unless the user switches into the svelte
version from react
- We don't show the dialog on every switch
- The dialog is accessible in the React via the "Learn more" button in
the menu
- Copy is updated to be less verbose
- The request for feedback is only shown once when switching out of the
svelte webapp
Fixes srch-851
A consequence of https://github.com/sourcegraph/sourcegraph/pull/64272
is that redirecting to the cody marketing page on dotcom didn't work.
That's because `/cody` is not provided by the server as a known page.
A simple fix would be to mark the link as external, but we'd have to
keep in mind to do this in all places (present and future).
A more "central" fix is to add this page to a hardcoded list of known
pages that are not provided by the server.
## Test plan
Manual testing
Currently the link element doesn't extend to the full width of the
sidebar. You can click outside of the actual text to navigate to the
file, but it won't be preloaded.
Now the link occupies the full width.
## Test plan
Manual testing.
Closes srch-838
This commit extends the search progress popover and adds the search jobs
section.
In the React version the UI for the popover differs slightly when search
jobs are enabled vs not enabled.
I decided to ignore the differences and only impolemented the style used
for the 'search jobs enabled' version, which makes the popover a bit
more compact.
The logic for validating and creating a search job is encapsulated in a
class which makes it easy to conditionally show the search jobs UI.
Additional changes:
- Skipped items is now a list and uses `<details>` elements which is
semantically more correct. We loose the styling of the chevron but I
think that's OK.
- LoadingSpinner was updated to work inline.
- Logging was fixed (?) in the React version to send the correct
meta-data.
- Added integration tests for the search job popover behavior
## Test plan
Integration tests and manual testing.
I noticed that non-svelte repo subpages haven't been redirected to the
React app in local development (it works as expected in production).
That's because the proxy doesn't know about them since they are not part
of `knownRoutes`.
We could update the server code to include those routes as well but that
seems heavey handed just to make local development work.
I think in this case it's fine to have manual entries for the handful of
repo subpages that have not been migrated to Svelte yet.
## Test plan
Manual testing.
tl;dr: Everything is derived from `window.context.svelteKit.knownRoutes`
*buckle up*
### Context
After the new web app was enabled by default on dotcom I looked at
dotcom data in Sentry to see if there was anything out of the ordinary.
I noticed a high number of errors related to resolving repository
information. The most common non-existing repository that was reported
was `-/sign-out`.
Of course this shouldn't happen. `/-/sign-out` is the sign out URL and
shouldn't be interpreted as a repository.
Currently we prevent SvelteKit from interpreting specific paths as
repositories by using the `reporev` parameter validator:
```ts
// src/params/reporev.ts
const topLevelPaths = [
'insights',
'search-jobs',
'saved-searches',
// ... many more here
]
const topLevelPathRegex = new RegExp(`^(${topLevelPaths.join('|')})($|/)`)
// This ensures that we never consider paths containing /-/ and pointing
// to non-existing pages as repo name
export const match: ParamMatcher = param => {
// Note: param doesn't have a leading slash
return !topLevelPathRegex.test(param) && !param.includes('/-/')
}
```
`-/sign-out` was not in that list, including others which have been
added since this file was originally created.
Adding it would have been the simple solution but having to maintain
this list manually has always irked me. Now we have a better way...
### Production changes
#### Client side
It turns out we are already sending a list of known routes to the client
in `window.context.svelteKit.knownRoutes` to basically do the same
thing: test whether a given path is a page or a repository.
```ts
// src/lib/navigation.ts
let knownRoutesRegex: RegExp | undefined
function getKnownRoutesRegex(): RegExp {
if (!knownRoutesRegex) {
knownRoutesRegex = new RegExp(`(${window.context?.svelteKit?.knownRoutes?.join(')|(')})`)
}
return knownRoutesRegex
}
// ...
export function isRouteEnabled(pathname: string): boolean {
let foundRoute: SvelteKitRoute | undefined
// [...]
if (foundRoute) {
if (foundRoute.isRepoRoot) {
// Check known routes to see if there is a more specific route than the repo root.
// If yes then we should load the React app (if the more specific route was enabled
// it would have been found above).
return !getKnownRoutesRegex().test(pathname)
}
return true
}
return false
}
```
Why do we have the `reporev` validator and `isRouteEnabled`? They
basically do the same thing (check whether a path is a known page or a
repository) the first (`reporev`) is used by SvelteKit to determine
which route a path corresponds to (i.e. to navigate to the repository
page or whether the page doesn't exist) and the second one
(`isRouteEnabled`) is used after the route resolution but before route
loading. It's used to trigger a full page refresh to fetch the React
version if necessary.
Anyways, since we already have a list of known pages from the server,
the parameter validator should just use it too. Except it didn't work,
which made the following server side changes necessary.
#### Server
We register routes in multiple places. Right now `knownRoutes` is
populated from the router created in
`cmd/frontend/internal/app/ui/router.go`, but this does not include
`/-/sign-out`. This route (and others) are defined in
`cmd/frontend/internal/app/router/router.go` (I don't know what the
difference is). I extended the sveltekit route registration code so
that's possible to register routes from multiple routers.
I couldn't test it yet however because I currently can't get Sourcegraph
to run locally (Camden tested it; it works).
### Development mode changes
After the above changes, navigating to a React only page in development,
e.g. `/insights` would show a 'repo not found error' because
`window.context.svelteKit.knownRoutes` was empty in development. So
every non-existing page would be interpreted as missing repository.
Hardcoding a list of known pages *again* just for development seemed to
be a step backwards. So I spent quite a bit of time to find a way to
extract the JS context object from the HTML page returned by the origin
server and inject it into the HTML page generated by SvelteKit, similar
to how we do it for the React app.
Additionally the value of `window.context.svelteKit.knownRoutes` is now
used to setup the proxy to non-supported pages from the server, so we
don't have to maintain this regex anymore either:
```ts
// Proxy requests to specific endpoints to a real Sourcegraph
// instance.
'^(/sign-(in|out)|/.assets|/-|/.api|/.auth|/search/stream|/users|/notebooks|/insights|/batch-changes|/contexts)|/-/(raw|own|code-graph|batch-changes|settings)(/|$)': { ... }
```
This means that requesting non-svelte pages will also return the
corresponding React version in development.
## Test plan
Manual testing.
Relates to #64186
With this PR we only show `83 out of 120 tasks` if the search job is
currently processing. In all other states, we don't show this stat. This
is a consequence of the janitor job I recently added, because after
aggregation, this data is not available anymore. User's can still
inspect the logs and download results to get a detailed view of which
revisions were searched.
I also remove an unnecessary dependency of the download links on the job
state.
## Test plan:
I ran a search job locally and confirmed that the progress message is
only visible while the job is processing and that logs and downloads are
always available.
## Changelog
- Show detailed progress only while job is in status "processing"
- Remove dependency of download links on job state
When I added this, for some reason I thought it was site admin only. As
it turns out, it shouldn't be gated to site admins only, and it makes it
particularly annoying on dotcom.
Reverts sourcegraph/sourcegraph#64014
We decided that including this in the August 7th release would be rushed
after diving deeper into the project. Reverting this in order to
re-write the functionality, especially the data loading components.
## Test Plan
- this is a revert PR. Everything will work as before.
There is no need to have a separate image file for dark mode. The SVG
file can handle color switching itself.
## Test plan
Switched theme in the user menu and in the browser dev tools.
Introduces basic (and incomplete) UI support for perforce, including displaying changelist ids,
listing changelists, and removing references to commits and branches.
The URL path for streaming blame is ambiguous when the file path
contains `/stream/`. The pattern looks like
`/blame/<repo_name>@<revision>/stream/file/path.txt`. However, if the
file contains `/stream/`, the revision is matched greedily up until the
last stream, so we end up with a revision that looks like
`81af3g/stream/my/path`, which is in invalid revision that results in a
404.
This makes the URL pattern unambiguous by adding a `/-/` element after
the revision, which is not allowed in a revision name and acts as a path
separator. So now, the pattern looks like
`/blame/<repo_name>@<revision>/-/stream/file/path.txt`.
Note, this is a public-facing breaking change, but I don't think it
really matters since I don't expect any customers use our streaming
blame API
With SRCH-802 we saw error messages when batch changes may still retry
and resolve the problem. To give a better distinction between resolvable
and non-resolvable errors, I'm changing the colour variation from error
to warning if the changeset has not been marked as `FAILED` yet.
Before:
<img width="913" alt="Screenshot 2024-08-02 at 12 44 27"
src="https://github.com/user-attachments/assets/b192c5e9-d23b-460c-82a7-a039edbca3f5">
After:
<img width="1355" alt="Screenshot 2024-08-02 at 12 36 23"
src="https://github.com/user-attachments/assets/02e231a7-168a-4fe9-bd3b-014d810fd236">
## Test plan
Manual testing
## Changelog
- Batch changes that are still retrying now show a warning instead of an
error.
Closes
https://linear.app/sourcegraph/issue/SRCH-561/add-support-for-file-ranges-in-cody-web
## Test plan
- Check that you can mention files with ranges
- Check that as you open Cody chat on the blob UI page and you have
selected lines in blob UI then chat should have an initial context
mention with line range
- Check that as you change line selection it updates mention file chip
range (only if you don't have any other text)
This PR brings the most recent version of @sourcegraph/cody-web package
- Improvements in how we fetch providers and debounce logic for their
query
- Fix with switching-chat actions and providers list
## Test plan
- Manual checks over cody web (React and Svelte version)
<!-- PR description tips:
https://www.notion.so/sourcegraph/Write-a-good-pull-request-description-610a7fd3e613496eb76f450db5a49b6e
-->
This PR resolves
[REL-300](https://linear.app/sourcegraph/issue/REL-300/put-update-redirect-into-current-sourcegraph-admin-panel).
We point the Update button in the SiteAdmin sidebar to point to a
different URL (Currently appliance localhost port, needs to be changed)
based on the `APPLIANCE_MANAGED` env var.
Most of the PR is tracking types / config down to the backend. There, a
simple function checks for the existence of this env var and if it
exists returns it's value.
I may have updated extra unnecessary types (not certain) but I was
following the compiler.
Second commit is just updating the storybook type values
We'll need another PR to the Helm chart to activate the env var once we
want to switch people over to pointing to the appliance maintenance UI.
@DaedalusG brought up the good point that even when managed by
Appliance, the Upgrades page still provides valuable information to
administrators, and so we may or may not actually want to leave this the
way it is.
TODO:
- [ ] Change the URL that is pointed to when the env var is active
(listed in a comment)
## Test plan
<!-- REQUIRED; info at
https://docs-legacy.sourcegraph.com/dev/background-information/testing_principles
-->
Tested manually
## Changelog
<!-- OPTIONAL; info at
https://www.notion.so/sourcegraph/Writing-a-changelog-entry-dd997f411d524caabf0d8d38a24a878c
-->
- **feat(appliance): change update endpoint based on env var**
- **misc: add type to storybook**
---------
Co-authored-by: Craig Furman <craig.furman@sourcegraph.com>
* Frontend no longer embeds the assets intead it reads from the local
filesystem assets.
* Generally the frontend and server cmd targets will use the
`//client/web/dist:copy_bundle` target to create a tarball for the
oci_image. `copy_bundle` puts all the assets at `assets-dist`
* For integration tests, frontend and server have the `no_client_bundle`
target variants. For these oci_images, instead of the `tar_bundle` which
is just a tar'd `copy_bundle` we use the `tar_dummy_manifest` which is
just a tar that contains a dummy manifest.
* By default we expect assets to be at `/assets-dist`
* Renamed DevProvider to DirProvider
## Why
By 'breaking' the dependency of frontend requiring assets to be built we
essentially stop a common cache invalidation scenario that happens:
- someone makes a frontend change = assets need to be rebuilt
By decoupling assets from the frontend binary and moving the packing of
assets to the building of the frontend and server images we will have a
better cache hit rate (theoretically).
Thus with this change, when:
* client/web is change and nothing else ... only assets will have to
rebuilt and cached versions of the backend will be used
* if only backend code has changed ... cached assets will be used
Closes DINF-115
## Test plan
✅ sg start - web app opens and can search. Local dev assets get loaded
✅ sg test bazel-integration-test - server image gets built with **only**
dummy web manifest. Also verified by running `sg bazel run
//cmd/server:no_client_bundle.image` and then inspect container
✅ sg test bazel-e2e - server image gets built with bundle and all tests
pass
✅ [main dry
run](https://buildkite.com/sourcegraph/sourcegraph/builds/284042#0190e54c-14d9-419e-95ca-1198dc682048)
## Changelog
- frontend: assets are no longer bundled with binary through `go:embed`.
Instead assets are now added to the frontend container at `assets-dist`.
The same changes that we did in
https://github.com/sourcegraph/sourcegraph/pull/64149
but for the Svelte version of the app.
- Update cody web to the `@sourcegraph/cody-web:0.3.0`
- Fix the telemetry name
- Rendering improvements in cody chat UI
- Change status from experimental to beta
## Test plan
- Manual checks over cody web in the svelte version
A few things this PR does
- Update cody web to the most updated version and package name which is
(`@sourcegraph/cody-web`)
- Support custom telemetry name for cody web events (on dotcom it should
be `dotcom.web` and `server.web` on the enterprise instance
- The most updated release of Cody Web includes
- fixes for remote LLM models on enterprise
- improvements for performance rendering Chat UI
- telemetry fixes
## Test plan
- Manual checks over Cody Web chat UI (standalone chat page and the blob
UI side panel chat)
When there is already a global token, then the notice after installing a
personal app is wrong. This PR handles this issue, so that the notice
shows up as expected.
We also fix an alignment issue, where the call to refresh the page would
be in a distinct column, instead of what we'd expect.
## Test plan
Manual testing
## Changelog
<!-- OPTIONAL; info at
https://www.notion.so/sourcegraph/Writing-a-changelog-entry-dd997f411d524caabf0d8d38a24a878c
-->
