Open ggilmore opened 6 years ago
Yeah this is not good, this is all debt from when we used sourcegraph-server-gen. We used to have all the data center options inside the site config, but that should no longer be the case / we should move away from that approach going forward.
I suspect that unfortunately Uber is probably relying on these options currently, cc @beyang to confirm. I'm not sure if other customers would be.
I think the longer term solution is to make xlang-java be able to read these options over workspace/configuration.
I agree 👍
Also note that we have something that configures the language server itself (rather than the workspace), which can act a bit quicker in the langserver's startup procedure. You can set arbitrary initialize
request parameters via the site config here:
(I'm fine with either immediate solution, as long as we avoid breaking anyone's data center deployment that relies on these)
Yes, Uber currently uses them (and Lyft might also use them). Before they are removed, we will need (1) an alternate way to get these values into xlang-java (probably through workspace/configuration
or initialize
params as @ggilmore suggests); and (2) migration instructions for Uber.
Action item is to add info to our migration doc in our yaml branch on deploy-sourcegraph
Then in 2.12 (or whenever existing customers update), we can fully remove these from site config
This issue has not had any recent activity. To keep our open issue list representative of our actual priorities, it will be closed if no further activity occurs. If this issue should stay open, simply remove the stale label. Thank you for your contributions.
PrivateArtifactRepoUsername
PrivateArtifactRepoID
PrivateArtifactRepoURL
PrivateArtifactRepoPassword
ExecuteGradleOriginalRootPaths
All of the above are configuration options that are only used by
deploy-sourcegraph
's templating logic in order to set environment variables for thexlang-java
deployment. These have no effect onsourcegraph/sourcegraph
's logic (i.e., these options do nothing forsourcegraph:server
). Since we aren't using the templating logic for the pure yaml language server deployments (sourcegraph/deploy-sourcegraph#68), we won't be able to rely on this.I think the longer term solution is to make
xlang-java
be able to read these options over workspace/configuration. For now though, I think it's fine to:xlang-java