## UI Updates for Perforce Depots and Git Repos
Fixes SRCH-530
**NOTE: This PR is a refactor of an earlier
[PR](https://github.com/sourcegraph/sourcegraph/pull/64014) that was
reverted. For that reason, the PR description is largely the same.**
This PR introduces changes to the UI to differentiate between Perforce
Depots and Git repositories. Below are the key changes included in this
commit:
### 1. Dynamic Top-Level Navigation
**For Perforce Depots:**
**For Git Repos:**
### 2. Tabs on Revision Picker
**For Perforce Depots:**
Since we only need one tab for changelists, no tabs are shown.
**For Git Repos:**
We have tabs for Branches, Tags, and Commits.
### 3. Commits/Changelists Page
**For Git Repos:**
The page displays Git commits.
**For Perforce Depots:**
The page displays Perforce changelists.
### 4. Vocabulary Adjustments
- We display either Git commit SHAs or Changelist IDs based on the
project type.
- For authorship, we use "submitted by" for Perforce and "committed by"
for Git.
- We refer to "Commits" for Git projects and "Changelists" for Perforce
projects.
**Examples:**
- **For Git Commits:**
- **For Perforce Changelists:**
### 5. URL Mapping
URLs are now structured differently based on the project type:
- **Commits Page:**
- Git: `/[repo-name]/-/commits`
- Perforce: `/[repo-name]/-/changelists`
- **Individual Item Page:**
- Git: `/[repo-name]/-/commit/[commit-hash]`
- Perforce: `/[depot-name]/-/changelist/[changelist-ID]`
When viewing a specific commit or changelist:
- **Git:** `/[repo-name]@[git-commit-hash]`
- **Perforce:** `/[repo-name]@changelist/[changelist-id]`
_NOTE: The value displayed in the search field will also change
accordingly._
### What is left to be done?
**On repo search results, when searching a revision, we still show the
git commit SHA instead of the changelist ID for perforce depots:**
I plan to make a follow-up issue for this and begin work on it
immediately. It's a little trickier than the other changes because in
the RepositoryMatch type, there is no value that can help us determine
whether a project is a depot or a repo. We need to find another way to
fetch that data.
### Request for reviewers:
1. Please try to break these new features and tell me what you find. I
stumbled on a number of little gotchas while working on this, and I'm
sure I've missed some.
## Test plan
<!-- REQUIRED; info at
https://docs-legacy.sourcegraph.com/dev/background-information/testing_principles
-->
- Manual/Visual testing
- Adjust e2e and integration tests to obtain a passing CI
- Test directly visiting a URL versus getting there via click
- Add unit tests for new/updated helper functions
---------
Co-authored-by: Camden Cheek <camden@ccheek.com>
Docs here: https://github.com/sourcegraph/docs/pull/561
This PR adds support for using Bitbucket Server OAuth2 application links
for sign-in and permission syncing.
When used for permission syncing, the user's oauth token is used to
fetch user permissions (and now permissions are fetched via the server).
## Test plan
Tests added and updated.
## Changelog
- Sourcegraph now supports Bitbucket Server OAuth2 application links for
user sign-in and permission syncing.
Closes #srch-906
This commit adds the cody chat page to svelte. This is simply reusing
the existing wrapper around the React component and renders it in a
standalone page.
When merged this will cause the cody chat page to be handled by new web
app on dotcom by default.
## Test plan
- Verified that chat loads and the tabs are clickable.
- Verified that the scroll behavior works as in the React app.
- Verified that the sidebar chat still works as expected (scroll
behavior, default context loading/switching)
What: This PR does the bare minimum to migrate the current community
search pages to Svelte. A better strategy for managing them is needed in
the medium/long term.
How: The community pages live at the root (e.g. `/kubernetes`) which
complicates things, but I'll get to that later. The page is implemented
as a single parameterized route. A parameter matcher is used to validate
the community name. Because these pages should only be accessible on
dotcom the matcher also validates whether or not we are on dotcom (if
not, the path will be matched against a different route).
The page config is stored in a separate module so that it's no included
in every page and so that it can be used in the integration test.
The loader and page implementation themselves are straightforward. I
made a couple of changes in other modules to make implementation easier:
- Extracted the parameter type of the `marked` function so that it can
be used as prop type.
- Added an `inline` option to `marked` that allows formatting markdown
as 'inline', i.e. without `p` wrapper.
- Added a `wrap` prop to `SyntaxHighlightedQuery.svelte` to configure
line wrapping of syntax highlighted search queries (instead of having to
overwrite styles with `:global`).
- Extended the route code generator to be able to handle single
parameter segments and the `communitySearchContext` matcher.
Because the community routes should only be available on dotcom I added
a new tag to the code generator that allows it include routes only for
dotcom.
Once we change how all this works and have community search pages live
under a different path we can simplify this again.
Result:
| React | Svelte |
|--------|--------|
|
|
|
## Test plan
- New integration tests.
- Verified that `/kubernetes` shows a 'repo not found error' when
running against S2.
- Verified that `/kubernetes` shows the community page when running
against dotcom.
- Verified that `window.context.svelteKit.enabledRoutes` contains the
community page route in enterprise mode but not in dotcom mode.
closes:
https://linear.app/sourcegraph/issue/SRCH-622/remove-old-cody-web-entirely
Removes the old Cody Web completely.
## Test plan
- sg start
- visit /cody/chat and you should see the new unified panel Cody Web
without having to turn on any feature flags.
- check the blob view sidebar for the same.
## Changelog
- The new Cody Web is enabled by default and the older version of Cody
Web is completely removed from both standalone chat and sidebar.
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
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
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.
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)
<!-- 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`.
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
-->
Closes SRCH-741
Closes SRCH-716
This PR removes the GitHub installation code from the redirect flow to a
webhook-based appraoch. We expect that the GitHub server calls the
webhook when the installation is ready, and therefore shouldn't see the
errors explained in the issues above.
To handle the potential delay until the webhook is called and the
credential is set up, I added a scrappy info notice that the user should
refresh their page:
<img width="928" alt="Screenshot 2024-07-24 at 13 48 24"
src="https://github.com/user-attachments/assets/4d298f2a-d7b8-423b-9e2f-2ae53fbce1ac">
Below is what you see after you refreshed (or if the webhook was called
faster than the user being redirected back to the settings):
<img width="929" alt="Screenshot 2024-07-24 at 13 50 14"
src="https://github.com/user-attachments/assets/b6826158-8561-476d-b20e-e36f8cfb86fd">
I'm able to create PRs for sourcegraph-testing with an app that was
created this way.
<img width="1171" alt="Screenshot 2024-07-24 at 16 16 06"
src="https://github.com/user-attachments/assets/86e20acb-136f-4a46-a33b-bdfdd0d51d71">
I'm seeing an error when getting an access token with a personal github
app to run a batch change, but that will be handled with another PR.
<img width="1053" alt="Screenshot 2024-07-24 at 16 38 38"
src="https://github.com/user-attachments/assets/5655ba91-1ae4-453a-8d5c-1bcdbe34bc17">
## Test plan
Manual testing locally, and more testing to be done on S2 where we have
a more production like environment
## Changelog
- When installing a GitHub app for batch changes, the instance now waits
for a callback from GitHub to complete the installation to avoid issues
from eventual consistency.
---------
Co-authored-by: Peter Guy <peter.guy@sourcegraph.com>
The current description doesn't do a good job of explaining why Search
Jobs is useful and how to create a job.
## Test plan:
visual inspection
Co-authored-by: Erik Seliger <erikseliger@me.com>
- Make it a React function component (not class componnt)
- Remove prop drilling for isSourcegraphDotCom to remove a bunch of code
- fix issue in Back button after clicking to an org from the site admin
orgs page. Repro: 1. Go to /site-admin/organizations. 2. Click on an
org. 3. Click the browser's back button. This was already being done for
the user routes.
## Test plan
Repro described above
This is the last bit of work before flipping the switch on dotcom.
Implemented based on the behavior @taiyab and I aligned on this morning.
Can definitely still use a little sparkle, but I'll let others follow up
on that.
It adds a toggle button to all pages that we have a svelte version of.
The toggle is off when you're in the react webapp and on when you're in
the svelte webapp. It also updates the copy of the popover to be more
appropriate for the dotcom crowd.
Anonymous visitors to Sourcegraph.com were unable to list all public
saved searches (at https://sourcegraph.com/saved-searches) and prompts
(at https://sourcegraph.com/prompts) for 2 reasons:
1. The namespace selector (filter) was broken for anonymous users and
returned an error. Fixed this by just handling this case.
2. The GraphQL resolvers for `savedSearches` and `prompts` prevented
anonymous users from listing items because there was no affiliated user
and thus the anonymous user was essentially trying to list all. Fixed
this by adding a new and well-tested code path for listing only public
saved searches or prompts.
## Test plan
In dotcom mode, visit those 2 pages (`/saved-searches` and `/prompts`).
Previously, organizations would be displayed using their `displayName`,
which was inconsistent and non-canonical. The `displayName` is also
longer, so it's not suited to display in select menus and other similar
places.
For example, when viewing the user menu or creating a batch change or
saved search, the dropdown will now show `sourcegraph` instead of
`Sourcegraph` (where the latter is the display name).
## Test plan
Go to create a batch change or saved search and confirm that org names
not displayNames are shown.
## Changelog
- The user menu and other filter menus now show the names of
organizations, not their "display names", to avoid ambiguity. For
example, these menus will now show `abc-corp` not `ABC Corp` (if the
latter was the `abc-corp`'s display name).
- Add spacing at bottom of page
- Fix viewerCanAdminister check to return `false` not an error when the
user is not an administrator of a saved search or prompt
- Improve display of prompt description
## Test plan
In dotcom mode, try loading a prompt or saved search in incognito mode.
For some reason, the indication that the text was copied was removed for
secrets. The indication does not show the secret value itself, so I
don't see why that change was made. It is helpful to the user to give
them feedback that the secret was in fact copied.
## Test plan
Click the copy button after creating an access token
We want to support orgs on dotcom for grouping prompts in the Prompt
Library. Note that creating orgs was never actually disabled in the API,
so this was ineffectual anyway.
## Test plan
View the user settings area sidebar in dotcom mode and ensure the new
org button is shown.
