This PR is on top of #54517
---
This PR rework how we handle the docsite and some of its related tasks:
- While we _could_ avoid committing the generated files to disk, the way
that docsite currently works, requires to have all files available in
git, so the docsite can serve various versions.
- `bazel run //doc/cli/references:write_doc_files` handles this (and
it's umbreall `//dev:write_all_generated`.
- Its generation is now handled by `//doc/cli/references:generate_doc`
and its associated test.
- `sg run docsite` now calls `bazel run //doc:serve`, we don't need to
install the docsite directly anymore (but it's available under `bazel
run //dev/tools:docsite` if needed).
As a byproduct, we can now run `src-cli` with `bazel run
//dev/tools:src-cli` which will pick the correct binary for your machine
transparently.
## Test plan
<!-- All pull requests REQUIRE a test plan:
https://docs.sourcegraph.com/dev/background-information/testing_principles
-->
Locally tested + CI
Shaves about 30/40s from `sg lint` where docs are detected as well as
all builds on `main`, as doc changes are pretty rare, and we're
unecessarily testing those in every commit reaching `main`.
## Test plan
<!-- All pull requests REQUIRE a test plan:
https://docs.sourcegraph.com/dev/background-information/testing_principles
-->
Locally tested + CI
Reverts sourcegraph/sourcegraph#53718
This broke main because `src-cli` 5.1.0 is not yet released on its GH
release page, but executor docker images are trying to download this
release already.
## Test plan
CI go green
Closes
https://github.com/orgs/sourcegraph/projects/240?pane=issue&itemId=18474973
This PR does a few things:
1. Automates the significant versions (major / minor) src-cli release
2. Automates the src-cli changelog
3. Provides a command to validate all distribution channels have the
updated version
There is some sequencing trouble in how src-cli is released that is
worth explaining here. So when we perform a release of sourcegraph we
also bake in a minimum src-cli version constant, as well as the
documentation for that version of src-cli. This documentation is
actually generated from the src-cli tool itself, and naively requires
the latest version is available on github.
That's something I don't want to interrupt the release process, so in
this PR we do something slightly different. First, we assume that the
head of main is the release commit, which is reasonable since we are the
ones performing the release. Second, we checkout src-cli and use the
local checkout to bake the documentation into the sourcegraph release.
Third, we perform the src-cli release by tagging the build and pushing
the tag.
To do that this PR also adds a new optional flag into the go program
that installs the software to pass a local path instead of downloading
the latest release.
For some quality of life we autodetect the latest src-cli version from
the src-cli repo instead of assuming it's always the same as the
Sourcegraph version. This is just to hedge against any future
divergence.
Here is an example
[PR](https://github.com/sourcegraph/sourcegraph/pull/48573) after
running the update command (the diff won't necessarily reflect a real
diff)
Using the validate command we can check that github, brew, and npm all
have the latest release that matches the expected version.
## Test plan
To test this I had to do a few janky things:
1. replace the clone path with a constant src-cli path (I just cloned it
once, then grabbed the directory)
2. replace the actual ./release.sh script with something that won't
release. I just edited the script to echo and return early after all the
validations in the same repo above
Here is the output showing the diff and the release script
<img width="1112" alt="image"
src="https://user-images.githubusercontent.com/5090588/222289405-bc1a0632-6af0-4e72-b883-a1cf786f0aec.png">
<!-- All pull requests REQUIRE a test plan:
https://docs.sourcegraph.com/dev/background-information/testing_principles
-->
To test verify-src-cli simply run the command:
<img width="953" alt="CleanShot 2023-03-02 at 11 35 35@2x"
src="https://user-images.githubusercontent.com/5090588/222552782-72ae3e9f-03dd-4433-9a2b-7356df33849c.png">
And finally a minified example of the full flow
<img width="944" alt="CleanShot 2023-03-02 at 13 55 11@2x"
src="https://user-images.githubusercontent.com/5090588/222552934-7b49aa80-a2ad-4f54-9f27-ab8bf3d1408a.png">
- Add pagination to org members page
- Improve UI by adding avatar and user role
- Remove version of org members page which was available under a feature flag but not used.
Removes the extension registry UI and the GraphQL API that is necessary for the registry extension UI.
Any extensions that already exist locally or remotely can still be used with the enableLegacyExtensions site config flag and by enabling the extensions in your user settings.
This change is an intermediate step toward removing the extension registry (except the endpoint that's needed to support pre-4.0 Sourcegraph instances).
I think this PR has a 99% chance of going into the 4.4 release (2023-01-20) and not needing to be reverted. Subsequent PRs that actually make it impossible to use local or custom legacy extensions are still pending customer communication and confirmation. I hope we can merge other future PRs there as well, but there is a greater chance we'd need to revert them before 4.4. By making this PR first, it means less of a revert and more progress regardless of what we learn from customers.
* Add "site.users" GraphQL API query endpoint
* Add "invalidateSessionsByUserIDs" GraphQL API bulk mutation endpoint
* Add "deleteUsers" GraphQL API bulk mutation endpoint. It handles both hard and soft deletion of users, similar to the existing mutation "deleteUser" API endpoint.
This PR turns on repo cloning in executors for batch changes. It clones the repo into the workspace, adds cache files and the input and spawns the execution from that. [This requires a change in src-cli](https://github.com/sourcegraph/src-cli/pull/768) and makes the repo fetching process faster, more resilient (in my testing) and enables to run on the largest repos without bigger problems. Also, we have a grafana dashboard for executor cloning performance.
**Stats for nerds**
Ran on my Mac:
---
120 workspaces total, some of them are workspaces in subdirectories with `onlyFetchWorkspaces` on.
Total execution time: Before: 03:35 minutes, after: 01:09 minutes.
Also, in the 03:35 minute run the mac would start heating up a lot, it stayed mostly cool in the 01:09 minute run.
---
sgtest/megarepo:
Setting up the workspace before: ~8 minutes, now 2 minutes.
---
Also, see this: https://github.com/sourcegraph/sourcegraph/pull/37299 PR; it's the follow-up for post-3.41 cut to remove the access_token_id column from the database as well.
Now that we require go1.18, we can use a builtin type alias for
"interface{}": "any". I've updated all code except lib, which can be
imported by external modules. That is currently pinned at go1.16.
Additionally I had to rerun generate since rewriting generated go code
will fail CI.
find -name '*.go' | xargs gofmt -s -r 'interface{} -> any' -w
git checkout lib
go generate ./...
Test Plan: CI will exercise that the code still compiles. Otherwise this
is a noop.
go1.18 doesn't support go get to install a binary anymore. go install
still doesn't work due to the replace directive. So I have over
engineered something which instead fetches the latest release of src-cli
and runs that.
Test Plan: go generate ./doc/cli/references
* reset account link
* added unit tests to unlock account url generation
* fixed lint and prettier issues
* fixing mock for handle sign in test
* fixed linter error
* comment iteration on PR
* comment iteration on PR
* comment iteration on PR
* comment iteration on PR
* renamed it
- Spelled as Npm or NPM depending on local case convention.
For local variables and in types, Npm should be preferred.
For fully uppercase spellings, NPM should be used.
- Default to spelling it as npm otherwise.
This matches the convention in the npm/cli code and the
recommendation in the npm/cli README.
* added search users autocomplete API
* added autocomplete control first version
* autocomplete user search
* fixed styles
* optimized ux while loading search results
* fixed css lint
* added db test for autocomplete search
* moved method into org membership
* reverted md file
* added ut
The resultCount field was marked as deprecated back in 2019, but is
still seeing new uses. This removes remaining references to it and
removes it since all clients should now be using `matchCount`.
This confuses some tools since you end up with a main package with no
main function. I don't really see the point of having the ignore build
tag, since it won't run unless someone explicitly runs it.
Additionally I remove gen.go since we can just have the go generate
command inside of the file.
In this commit, along with moving to
github.com/cockroachdb/errors, we update a few tests and some
error checks in non-test code.
List of files that have code changes apart from changes in the
error package import:
enterprise/internal/batches/sources/gitlab.go
enterprise/internal/batches/sources/gitlab_test.go
internal/conf/client.go
internal/store/store_test.go
Co-authored-by: ᴜɴᴋɴᴡᴏɴ <joe@sourcegraph.com>
