Historically, sourcegraph.com has been the only instance. It was
connected to GitHub.com and GitLab.com only.
Configuration should be as simple as possible, and we wanted everyone to
try it on any repo. So public repos were added on-demand when browsed
from these code hosts.
Since, dotcom is no longer the only instance, and this is a special case
that only exists for sourcegraph.com.
This causes a bunch of additional complexity and various extra code
paths that we don't test well enough today.
We want to make dotcom simpler to understand, so we've made the decision
to disable that feature, and instead we will maintain a list of
repositories that we have on the instance.
We already disallowed several repos half a year ago, by restricting size
of repos with few stars heavily.
This is basically just a continuation of that.
In the diff, you'll mostly find deletions. This PR does not do much
other than removing the code paths that were only enabled in dotcom mode
in the repo syncer, and then removes code that became unused as a result
of that.
## Test plan
Ran a dotcom mode instance locally, it did not behave differently than a
regular instance wrt. repo cloning.
We will need to verify during the rollout that we're not suddenly
hitting code paths that don't scale to the dotcom size.
## Changelog
Dotcom no longer clones repos on demand.
It seems many of our doc links for code hosts are broken in production
due to a url changed from external_services to code_hosts. I did a find
an replace to update all the ones I could find.
We have a number of docs links in the product that point to the old doc site.
Method:
- Search the repo for `docs.sourcegraph.com`
- Exclude the `doc/` dir, all test fixtures, and `CHANGELOG.md`
- For each, replace `docs.sourcegraph.com` with `sourcegraph.com/docs`
- Navigate to the resulting URL ensuring it's not a dead link, updating the URL if necessary
Many of the URLs updated are just comments, but since I'm doing a manual audit of each URL anyways, I felt it was worth it to update these while I was at it.
## Description
Adds specific changes to support github app code host connections in
create and edit code host connections screens.
Added:
- github app selector in the edit screen
- github app installation selector in edit screen
- github app instructions which are different than standard ghe
instructions
- validation of JSON schema for code host connections and disabling the
`Add connection` or `Update configuration` buttons at the bottom of the
page if the JSONC doc does not adhere to the schema
## Video
[Loom
video](https://www.loom.com/share/48898711281b4f369ba58613c5c26ff9)
## Test plan
Tested locally, only UI changes.
## Description
- Fixed some glaring issues with whitespace not being good
- Fixed sidebar saying `Repository Permissions` instead of `Repository
permissions`
- Fixed links to permissions docs page from everywhere
- Made SLAs more prominent and defined SLAs for all 3 types of getting
permissions to sourcegraph
Old version:
https://docs.sourcegraph.com/admin/permissions
Version from this PR:
https://docs.sourcegraph.com/@milan_perms_docs_fixes/admin/permissions
## Test plan
Just docs or copy changes, so eyeballing. And verifying if the links
work.
* update schema with example for docs
* add note about token
* add token scope for permissions caching
* prettier
* schema update
* update repo token scope in schema
* Update doc/admin/repo/permissions.md
Co-authored-by: Robert Lin <robert@bobheadxi.dev>
Co-authored-by: Robert Lin <robert@bobheadxi.dev>
Extend the GitHub provider's FetchUserPermsByToken to use cached groups (orgs or teams) permissions to reduce API calls required to do a full permissions sync. Also introduces options for performing permission syncs that can be provided at various levels of permissions syncing. For now, this is only added to user permissions, and is primarily used to provide an InvalidateCaches flag that signals the Provider to invalidate caches encountered during the sync, which is currently only used by webhook handlers to invalidate caches when a team/org-related event is received. The ScheduleUserPermissionsSync mutation and some webhook handlers also take advantage of this.
Co-authored-by: ᴜɴᴋɴᴡᴏɴ <joe@sourcegraph.com>
When running with SOURCEGRAPHDOTCOM_MODE=true set we require that at
least one GitHub and GitLab external service have their cloud_default
flags set.
This change allows us to enforce this by setting the CloudDefault field
on config in dev-private.
This change just switches to using the new cloud_default column on the external_services table instead of external service config to choose our "default" sources on cloud.
Add CloudGlobal flag to GitHub and GitLab external services
Validate that only one site admin owned service on cloud can have this flag set as true.
A followup PR will use these values one this PR has been deployed and the appropriate external services have been flagged.
This follows on from our exclude fork work to allow excluding archived. This was
very recently requested by a customer, so would be nice to get out in 3.14.
I didn't add any end to end tests. It feels a bit overkill. Rather I think I
will look into making our exclude code more generic / unit testable in a future
commit.
* repo-updater: Add support for excluding forks from GitHub
This commit is an alternative implementation of #8861 that re-uses our
existing `exclude` setting.
* fixup! CHANGELOG
* fixup format
* schema: Validate GH & BBS config have repos OR repositoryQuery
This fixes#4322 by changing the validation of external service
configurations for GitHub and Bitbucket Server to validate that either
repositoryQuery OR repos are set.
* Remove GH & BBS SetDefaultRepositoryQueryMigrations
This change adds the `orgs` config option to GitHub external service config. This will allow site admins to explicitly select organizations to sync all repositories from as an alternative to `org:<org name>` in the `repositoryQuery` config option.
fix#4008
All JSON documents we use (for settings, site config, external services, and extension manifests) support trailing commas on the frontend and backend. However, an upgrade to monaco-editor unexpectedly caused the Monaco JSON editors in our UI to show red squiggly errors for trailing commas.
The (undocumented) way to do this is to add `allowComments` to the root of the JSON Schema. It is not sufficient to set `allowComments: true` in a `monaco.languages.json.jsonDefaults.setDiagnosticsOptions` call. I found this secret fix by finding https://github.com/microsoft/vscode/issues/19992#issuecomment-347124969 and then inferring what changes that might entail, to discover `allowComments` in the JSON Schema is responsible for ignoring trailing comma errors.
The documentation for the GitHub external service is a bit sparse for exclude
since it doesn't explain what you can put in the exclude field. By including
examples (and expanding on the description) in the schema it becomes better
documented both in our docs and in the editor.
* schema: Make (repository|project)Query required
We previously assumed that the default field would populate the
respective setting when unmarshaled, but this is not the case, so we
need to make this field required so that the migrations setting these
fields to ["none"] don't run one new configs.
Part of #2025
* fixup! Fix tests
* fixup! STYLE
- fix#2946 by implying that no "repo" scope is needed in the example JSON and explicitly mentioning it in the JSON Schema docs (the explicit mention is omitted from the example JSON for brevity, so that the "token" property is above the fold on an average-sized screen)
- use "repository" not "repo" per https://docs.sourcegraph.com/dev/style_guide
