I think at some point this script created the release and attached
assets but that's not the case anymore.
For some reason this would error with undefined variable reference for
joe but bash doesn't complain for me or Asher.
Not sure what the difference is.
Any json or urlencoded request bodies were being consumed by body-parser
before they could be proxied. That's why requests without Content-Type
were proxied correctly as body-parser would not consume their body.
This allows the http-proxy package to passthrough the request body correctly
in all instances.
Closes#2377
This breaks --proxy-path-passthrough
However, we still need this when that code is disabled as many apps will
issue absolute redirects and expect the proxy to rewrite as appropriate.
e.g. Go's http.Redirect will rewrite relative redirects as absolute!
See https://golang.org/pkg/net/http/#Redirect
Modify the tsconfig.json in lib/vscode/src/build.
This adds the flag skipLibCheck: true to tell TypeScript
to not type-check the declaration files at build time.
We need to add this because otherwise it checks the declaration
files and reports an error of duplicate type definitions
because we use Jest for our tests and they use Mocha and they
both use the global namespace "test" in their .d.ts files.
This had me very confused for quite a while until I did a binary search
inspection on route/index.ts. Only with the heart.beat line commented
out did my tests pass without leaking.
They weren't leaking fds but just this heartbeat timer and node of
course prints just fds that are active when it detects some sort of leak
I guess and that made the whole thing very confusing. These fds are not
leaked and will close when node's event loop detects there are no more
callbacks to run.
no of handles 3
tcp stream {
fd: 20,
readable: false,
writable: true,
address: {},
serverAddr: null
}
tcp stream {
fd: 22,
readable: false,
writable: true,
address: {},
serverAddr: null
}
tcp stream {
fd: 23,
readable: true,
writable: false,
address: {},
serverAddr: null
}
It kept printing the above text again and again for 60s and then the
test binary times out I think. I'm not sure if it was node printing the
stuff above or if it was a mocha thing. But it was really confusing...
cc @code-asher for thoughts on what was going on.
edit: It was the leaked-handles import in socket.test.ts!!!
Not sure if we should keep it, this was really confusing and misleading.
The goal is to remove supertest as it does not support typescript well
and there's really no good reason for the dependency. Also no websocket
testing support.
Add a short message above the search box on the Extensions panel. This
helps explain the extension divergence to the user.
If they click dismiss, it stores an item in localStorage to prevent the
message from showing up on subsequent loads.
Co-authored-by: Asher <ash@coder.com>
It requires git-lfs to pull down if you want to adjust the favicon and
also the affinity designer software available only on Windows and Mac.
Might be a good idea to switch to Figma at some point and commit a
.fig file.
This should prevent us from generating different diffs and adding noise
to our PRs. Patience seems like a good one; it generated a diff that I
felt was easier to read in the case of the yarn.lock optionator section.
I've been coding from my iPad to Raspberry Pi going on several months. I feel a pro at it and far prefer it over a cloud service for it has far less lag being local hosted.
`file` doesn't seem to work without a specific git reference, but adding
a reference makes the explorer not follow the tour. Unfortunately
`directory` doesn't show the directory contents so I added the directory
name and "see the explorer" to the comment.
Looks like
```
-r --reuse-window Force to open a file or folder in an already opened window.
-vvv --verbose Enable verbose logging.
--link (beta) Securely bind code-server via Coder Cloud with the passed name. You'll get a URL like
https://myname.coder-cloud.com at which you can easily access your code-server instance.
Authorization is done via GitHub.
```
Based on commits by @JammSpread in #2405Closes#2396
Safari runs code-server horribly. We shouldn't even pretend that it sort
of works.
See the issues tagged browser-safari!
Considered Firefox first but there's too many issues with it as well.
I took our website's SVG favicon and plopped it on a round
white rectangle in Affinity Designer. The I exported it as an SVG and
wrote a script that uses imagemagick to convert to the various sizes and
formats we need.
Closes#2307
Forgot an extra 60 in the check interval and the notification timeout.
Very unfortunate. Check has been allowed every 168 minutes instead of
every week.
Based on the previous commits by @mgmachado but simplified.
I also changed the threshold to error after a single attempt as the
connection has likely been borked and the user should be in the know if
they couldn't reconnect after 5 seconds.
Closes#1791
I disabled code-layering and code-import-patterns as I don't think we
can make them easily pass as we reference all sorts of code from both
browser and node files. At least not worth the headache now to refactor
everything.
Previously anything that wasn't "log" such as "warn" would end up doing
`logger[logger.warn]`. Would have caught this if I hadn't used `any`...
Fixes#2364.
The new fields are from vscodium and make the welcome page
documentation links work correctly.
I also renamed the distribution to "code-server" so that when you're
in a browser, it now says code-server instead of Code OSS.
It's possible that using browser storage makes more sense with settings
sync, so we might want to revisit this once/if we get settings sync
working. As it currently is though, browser storage just causes jank.
The path was also missing a `User` at the end so I added that. This
might affect the Vim extension which would have been writing to the
wrong path previously but I don't believe it should affect anything
else since they would have been writing to browser storage.
- Fixes#2208
- Fixes#2231
- Fixes#2279
- Fixes#2274
The telemetry service depends on this now. I had to move it into
invokeFunction and use accessor.get otherwise getLogger on the service
was undefined.
I also had to move some the extension management service because it
depends on the moved telemetry service. I moved a few other services as
well to better match VS Code (sharedProcessMain.ts).
I swapped some this.services.get with accessor.get since that seems to
be the correct method although for these other services either method
seems to work.
I removed this under the impression the default was to allow it anywhere
but that's not the case. Since the service worker was already registered
in my browser I never got the error during testing.
Also move our memory default to the beginning of NODE_OPTIONS so it can
be overidden. The version of the flag with dashes seems to be the more
correct one now so use that instead of underscores.
Related: #2113.
I think having them combined and relying on if statements was getting
confusing especially if we want to add additional messages with
different payloads (which will soon be the case).
Turns out that while Typescript can't infer the callback return type
from it, Typescript can do the opposite and infer it from the callback
return type.
Unfortunately we can't use node-mocks-http to test a express.Router
that has async routes. See https://github.com/howardabrams/node-mocks-http/issues/225
router will just return undefined if the executing handler is async and
so the test will have no way to wait for it to complete. Thus, we have
to use supertest which starts an actual HTTP server in the background
and uses a HTTP client to send requests.
This is mostly so we don't have to do any wacky patching but it also
makes it so we don't have to keep checking if the request is a web
socket request every time we add middleware.
This way the connection can be initiated by either side. It looks like
sometimes the initial message from the client is lost (it never makes it
into the onControlMessage callback) but I'm still not sure why or if
that is preventable.
Also added a timeout on the server end to clean things up in case the
client never responds.
Now we add a subject alt name, set extendedKeyUsage and use the
correct certificate extension.
The above allow it to be properly trusted by iOS.
See https://support.apple.com/en-us/HT210176
*.cert isn't a real extension for certificates, *.crt is correct
for it to be recognized by e.g. keychain or when importing as a profile
into iOS.
Updates #1566
I've been able to successfully connect from my iPad Pro now to my
code-server instance with a self signed certificate! Next commit
will be docs.
If do not update the UID within the passwd database to match whatever
uid the container is being ran as, then sudo will not work when renaming
the user to match $DOCKER_USER as it will complain about the current
user being non-existent.
Removing them just for peace of mind even though they seem to get
filtered out later. This line is meant to only add remote extensions
that aren't capable of running in the browser. If they are
browser-capable they don't need to run in our shimmed Node environment.
This makes the fetch work independently of the worker's origin which is
no longer the same as the main thread (the main problem is the inability
to send cookies without setting SameSite to None).
This matches with the html in the VS Code repo and also fixes a problem
with the worker which loads HTML using data: and then can't load any
scripts because 'self' doesn't work.
- The .js build files are no longer committed so they're gone.
- ParsedArgs and EnvironmentService are now NativeParsedArgs and
NativeEnvironmentService.
- Interface for environment service was moved.
- getPathFromAmdModule was deprecated.
Otherwise it outputs when trying to open a file in an existing instance
externally. Externally there isn't an environment variable to branch on
to skip this line so instead output it with the other info lines in the
child process.
- Immediately create ipcMain so it doesn't have to be a function which I
think feels cleaner.
- Move exit handling to a separate function to compensate (otherwise
the VS Code CLI for example won't be able to exit on its own).
- New isChild prop that is clearer than checking for parentPid (IMO).
- Skip all the checks that aren't necessary for the child process (like
--help, --version, etc).
- Since we check if we're the child in entry go ahead and move the
wrap code into entry as well since that's basically what it does.
- Use a single catch at the end of the entry.
- Split out the VS Code CLI and existing instance code into separate
functions.
We only want to use an old version for glibc which the centos:7
image takes care of.
The old version of git used in debian:8 was causing problems
with the uid/gid passthrough with no user in passwd.
We do not try renaming $HOME anymore as there is no good way
to do it.
We also only try to convert if the user hasn't been changed.
Finally I added usage to the docker docs in install.md
Closes#2056
VS Code has a short delay before writing storage (probably to queue up
rapid changes). In the web version of VS Code this happens on the client
which means if the page is reloaded before the delay expires the write
never happens.
Storage updates are already promises so this simply returns the promise
returned by the delayer so it won't resolve until the write actually
happens.
Fixes#2021.
Add initial support for opening files / folders in running code-server instance.
Current limitations:
- unable to open a file in a new window, only folders
- unable to use addMode feature
- others...
We need the handler to be recognized as a PWA but we can just let the
original offline browser message show instead of our own message.
See #1925 and #1979.
tsc doesn't check if the output exists when incremental is true.
i.e if I delete the out directory, but keep the tsbuildinfo and
try to rebuild, nothing happens cause it thinks everything is
up to date I guess...
With this change, yarn clean will now remove the tsbuildinfo correctly
so things work as expected.
Otherwise the build keeps failing for me as tsc won't compile anymore.
Not sure why things work on CI/for asher but I don't think this will
cause any additional issues.
It can still be used to check for updates but will not apply them.
For now also remove the update check loop in VS Code since it's
currently unused (update check is hardcoded off right now) and won't
work anyway since it also applies the update which now won't work. In
the future we should integrate the check into the browser update
service.
- Instead we now use CentOS 7 for the static build to guarantee
that we only depend on libc v2.17
- For macOS we now pull in a static node binary and bundle that instead.
This release fixes bugs introduced with the release of v3.3.0
- We've reverted to VS Code 1.45.1 due to bugs in 1.46 #1667
- Accessing code-server from a web browser on Windows has been fixed#1642
- Search in project has been fixed#1665
- The glibc requirement on static releases has been lowered to v2.19 #1656
Pass the user data dir to the browser environment service then derive
all the paths we can based off that path like the global storage path
which the vim extension uses to store history (otherwise it gets stored
in the working directory from when code-server was spawned).
Arguably the better solution is to use the userdata scheme but that
won't work because the vim extension ignores the VS Code API.
Fixes#1551.
See #1532 for more context.
- Errored JSON requests will get back the error in JSON instead of using
the status text. This seems better to me because it seems more correct
to utilize the response body over hijacking the status text. The
caller is expecting JSON anyway. Worst of all I never actually set the
status text like I thought I did so it wasn't working to begin with.
- Allow the update error to propagate for JSON update requests. It was
caught to show the error inline instead of an error page when using
the update page but for JSON requests it meant there was no error and
no error code so it looked like it succeeded.
- Make errors for failed requests to GitHub less incomprehensible.
Previously they would just be the code which is no context at all.
The raw value is now passed back to VS Code so it can do the parsing
with its own URI class rather than trying to parse using Node's url
module first since that has no guarantee of working the same way. It
also lets us keep the vscode-remote bit internal to VS Code.
Removed the logic that keeps trying paths until it finds a valid one
because it seems confusing to open a path and silently get some other
path instead of an error for the one you tried to open. Now it'll just
use exactly what you specified or fail trying.
Fixes#1488. The problem here was that url.parse was encoding the spaces
then the validation failed looking for a literal %20.
- Add type to HTTP options.
- Fix certificate message always saying it was generated.
- Dedent output not directly related to the HTTP server.
- Remove unnecessary comma.
In Google cloud shell the host header is 127.0.0.1:8080 instead of the
actual URL. This is what we write out to the HTML so VS Code can pick it
up. However cloud shell rewrites this string when found in the HTML
before serving it so it becomes https://8080-[...].appspot.com,
resulting in an extra unexpected https:// in the
URI (vscode-remote://https://8080[...]). The resulting malformed URI
causes the extension host to exit.
- Fixes#1471
- Fixes#1468
- Fixes#1440 (most likely).
This will make it work regardless of what the current URL happens to be.
Also move the telemetry setting into the options since we might as well
make use of it seeing as how we have to parse it for the base path
anyway.
By design the disable-telemetry flag does not affect extension
telemetry, only the setting does, so disabling the setting when the flag
is set should cause extensions to also stop sending telemetry.
Fixes#1116.
It still won't work behind a base path, but if you're using a reverse
proxy you can just redirect to HTTPS yourself. And should probably
handle TLS termination there too.
For sockets I just needed to add back the proxy call.
I temporarily removed this during the refactor so it needed to be added
back. This time I bundled it with the nbin loader code since it's all
related (will also make it easier to remove).
- Add VS Code icon
- Trim dashboard to just display dedicated VS Code section
- Version was getting unset during build
- Add back nbin shim which I temporarily took out earlier
- Update tests for log level env var changes
Might fix#1181, although not for the reasons I initially
thought (because the URLs are resolved from the manifest path, not the
path of the current page). This should ensure that the URLs used by the
manifest are always correct regardless of the manifest's path.
When using a query parameter without a scheme, the scheme defaults to
`file`. This results in the files in the explorer being technically
different from the file picker files because they are file:// instead of
vscode-remote://, causing the same file to open twice and causing
numerous issues.
Normally the file explorer wouldn't even load at all in this case but we
provide a file service for file:// URLs as a failsafe for certain files
that wouldn't load correctly in the past. These files load fine now
using the vscode-remote scheme, so I'm also removing that service.
Related: #1351.
Fixes#1294.
"description": "Hello world! code-server's source code lives here in `src` (see the explorer). It's broadly arranged into browser code, Node code, and code shared between both."
},
{
"file": "src/node/entry.ts",
"line": 157,
"description": "code-server begins execution here. CLI arguments are parsed, special flags like --help are handled, then the HTTP server is started."
},
{
"file": "src/node/cli.ts",
"line": 28,
"description": "This describes all of the code-server CLI options and how they will be parsed."
},
{
"file": "src/node/cli.ts",
"line": 233,
"description": "Here's the actual CLI parser."
},
{
"file": "src/node/settings.ts",
"line": 1,
"description": "code-server maintains a settings file that is read and written here."
},
{
"file": "src/node/app.ts",
"line": 11,
"description": "The core of code-server are HTTP and web socket servers which are created here. They provide authentication, file access, an API, and serve web-based applications like VS Code."
},
{
"file": "src/node/wsRouter.ts",
"line": 38,
"description": "This is an analog to Express's Router that handles web socket routes."
},
{
"file": "src/node/http.ts",
"line": 1,
"description": "This file provides various HTTP utility functions."
},
{
"file": "src/node/coder_cloud.ts",
"line": 9,
"description": "The cloud agent spawned here provides the --link functionality."
"description": "We pass sockets to child processes, however we can't pass TLS sockets so when code-server is handling TLS (via --cert) we use this to create a proxy that can be passed to the child."
},
{
"directory": "src/node/routes",
"line": 1,
"description": "code-server's routes live here in `src/node/routes` (see the explorer)."
},
{
"file": "src/node/routes/index.ts",
"line": 123,
"description": "The architecture of code-server allows it to be extended with applications via plugins. Each application is registered at its own route and handles requests at and below that route. Currently we have only VS Code (although it is not yet actually split out into a plugin)."
},
{
"file": "src/node/plugin.ts",
"line": 103,
"description": "The previously mentioned plugins are loaded here."
},
{
"file": "src/node/routes/apps.ts",
"line": 12,
"description": "This provides a list of the applications registered with code-server."
},
{
"file": "src/node/routes/domainProxy.ts",
"line": 18,
"description": "code-server provides a built-in proxy to help in developing web-based applications. This is the code for the domain-based proxy.\n\nAlso documented here: [https://github.com/cdr/code-server/blob/master/docs/FAQ.md#how-do-i-securely-access-web-services](https://github.com/cdr/code-server/blob/master/docs/FAQ.md#how-do-i-securely-access-web-services)"
},
{
"file": "src/node/routes/pathProxy.ts",
"line": 19,
"description": "Here is the path-based version of the proxy.\n\nAlso documented here: [https://github.com/cdr/code-server/blob/master/docs/FAQ.md#how-do-i-securely-access-web-services](https://github.com/cdr/code-server/blob/master/docs/FAQ.md#how-do-i-securely-access-web-services)"
},
{
"file": "src/node/proxy.ts",
"line": 4,
"description": "Both the domain and path proxy use the single proxy instance created here."
},
{
"file": "src/node/routes/health.ts",
"line": 5,
"description": "A simple endpoint that lets you see if code-server is up.\n\nAlso documented here: [https://github.com/cdr/code-server/blob/master/docs/FAQ.md#healthz-endpoint](https://github.com/cdr/code-server/blob/master/docs/FAQ.md#healthz-endpoint)"
},
{
"file": "src/node/routes/login.ts",
"line": 46,
"description": "code-server supports a password-based login here."
},
{
"file": "src/node/routes/static.ts",
"line": 16,
"description": "This serves static assets. Anything under the code-server directory can be fetched. Anything outside requires authentication."
},
{
"file": "src/node/routes/update.ts",
"line": 10,
"description": "This endpoint lets you query for the latest code-server version. It's used to power the update popup you see in VS Code."
},
{
"file": "src/node/routes/vscode.ts",
"line": 15,
"description": "This is the endpoint that serves VS Code's HTML, handles VS Code's websockets, and handles a few VS Code-specific endpoints for fetching static files."
},
{
"file": "src/node/vscode.ts",
"line": 13,
"description": "The actual VS Code spawn and initialization is handled here. VS Code runs in a separate child process. We communicate via IPC and by passing it web sockets."
},
{
"file": "src/browser/serviceWorker.ts",
"line": 1,
"description": "The service worker only exists to provide PWA functionality."
},
{
"directory": "src/browser/pages",
"line": 1,
"description": "HTML, CSS, and JavaScript for each page lives in here `src/browser/pages` (see the explorer). Currently our HTML uses a simple search and replace template system with variables that {{LOOK_LIKE_THIS}}."
},
{
"file": "src/browser/pages/vscode.html",
"line": 1,
"description": "The VS Code HTML is based off VS Code's own `workbench.html`."
},
{
"directory": "src/browser/media",
"line": 1,
"description": "Static images and the manifest live here in `src/browser/media` (see the explorer)."
},
{
"directory": "lib/vscode",
"line": 1,
"description": "code-server makes use of VS Code's frontend web/remote support. Most of the modifications implement the remote server since that portion of the code is closed source and not released with VS Code.\n\nWe also have a few bug fixes and have added some features (like client-side extensions). See [https://github.com/cdr/code-server/blob/master/docs/CONTRIBUTING.md#modifications-to-vs-code](https://github.com/cdr/code-server/blob/master/docs/CONTRIBUTING.md#modifications-to-vs-code) for a list.\n\nWe make an effort to keep the modifications as few as possible."
"description": "## Commands\n\nTo start developing, make sure you have Node 12+ and the [required dependencies](https://github.com/Microsoft/vscode/wiki/How-to-Contribute#prerequisites) installed. Then, run the following commands:\n\n1. Install dependencies:\n>> yarn\n\n3. Start development mode (and watch for changes):\n>> yarn watch"
},
{
"file": "src/node/app.ts",
"line": 68,
"description": "## Visit the web server\n\nIf all goes well, you should see something like this in your terminal. code-server should be live in development mode.\n\n---\n```bash\n[2020-12-09T21:03:37.156Z] info code-server 3.7.4 development\n[2020-12-09T21:03:37.157Z] info Using user-data-dir ~/.local/share/code-server\n[2020-12-09T21:03:37.165Z] info Using config file ~/.config/code-server/config.yaml\n[2020-12-09T21:03:37.165Z] info HTTP server listening on http://127.0.0.1:8080 \n[2020-12-09T21:03:37.165Z] info - Authentication is enabled\n[2020-12-09T21:03:37.165Z] info - Using password from ~/.config/code-server/config.yaml\n[2020-12-09T21:03:37.165Z] info - Not serving HTTPS\n```\n\n---\n\nIf you have the default configuration, you can access it at [http://localhost:8080](http://localhost:8080)."
},
{
"file": "src/browser/pages/login.html",
"line": 26,
"description": "## Make a change\n\nThis is the login page, let's make a change and see it update on our web server! Perhaps change the text :)\n\n```html\n<div class=\"sub\">Modifying the login page 👨🏼💻</div>\n```\n\nReminder, you can likely preview at [http://localhost:8080](http://localhost:8080)"
},
{
"file": "src/node/app.ts",
"line": 62,
"description": "## That's it!\n\n\nThat's all there is to it! When this tour ends, your terminal session may stop, but just use `yarn watch` to start developing from here on out!\n\n\nIf you haven't already, be sure to check out these resources:\n- [Tour: Contributing](command:codetour.startTourByTitle?[\"Contributing\")\n- [Docs: FAQ.md](https://github.com/cdr/code-server/blob/master/docs/FAQ.md)\n- [Docs: CONTRIBUTING.md](https://github.com/cdr/code-server/blob/master/docs/CONTRIBUTING.md)\n- [Community: GitHub Discussions](https://github.com/cdr/code-server/discussions)\n- [Community: Slack](https://community.coder.com)"
1. Microsoft/vscode version 1.47.0 (https://github.com/Microsoft/vscode)
%% Microsoft/vscode NOTICES AND INFORMATION BEGIN HERE
=========================================
MIT License
Copyright (c) 2015 - present Microsoft Corporation
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
This directory contains scripts used for code-server's continuous integration infrastructure.
Some of these scripts contain more detailed documentation and options
in header comments.
Any file or directory in this subdirectory should be documented here.
- [./ci/lib.sh](./lib.sh)
- Contains code duplicated across these scripts.
## Publishing a release
Make sure you have `$GITHUB_TOKEN` set and [hub](https://github.com/github/hub) installed.
1. Update the version of code-server and make a PR.
1. Update in `package.json`
2. Update in [./docs/install.md](../docs/install.md)
3. Update in [./ci/helm-chart/README.md](../ci/helm-chart/README.md)
- Remember to update the chart version as well on top of appVersion in `Chart.yaml`.
- Run `rg -g '!yarn.lock' -g '!*.svg' '3\.7\.5'` to ensure all values have been
changed. Replace the numbers as needed.
- You can install `rg` or `ripgrep` on macOS [here](https://formulae.brew.sh/formula/ripgrep).
4. Update the code coverage badge (see [here](#updating-code-coverage-in-readme) for instructions)
2. GitHub actions will generate the `npm-package`, `release-packages` and `release-images` artifacts.
1. You do not have to wait for these.
3. Run `yarn release:github-draft` to create a GitHub draft release from the template with
the updated version.
1. Summarize the major changes in the release notes and link to the relevant issues.
4. Wait for the artifacts in step 2 to build.
5. Run `yarn release:github-assets` to download the `release-packages` artifact.
- It will upload them to the draft release.
6. Run some basic sanity tests on one of the released packages.
- Especially make sure the terminal works fine.
7. Make sure the github release tag is the commit with the artifacts. This is a bug in
`hub` where uploading assets in step 5 will break the tag.
8. Publish the release and merge the PR.
1. CI will automatically grab the artifacts and then:
1. Publish the NPM package from `npm-package`.
2. Publish the Docker Hub image from `release-images`.
9. Update the AUR package.
- Instructions on updating the AUR package are at [cdr/code-server-aur](https://github.com/cdr/code-server-aur).
10. Wait for the npm package to be published.
11. Update the homebrew package.
- Send a pull request to [homebrew-core](https://github.com/Homebrew/homebrew-core) with the URL in the [formula](https://github.com/Homebrew/homebrew-core/blob/master/Formula/code-server.rb) updated.
## Updating Code Coverage in README
Currently, we run a command to manually generate the code coverage shield. Follow these steps:
1. Run `yarn badges`
2. Go into the README and change the color from `red` to `green` in this line:
NOTE: we have to manually change the color because the default is red if coverage is less than 80. See code [here](https://github.com/olavoparno/istanbul-badges-readme/blob/develop/src/editor.ts#L24-L33).
## dev
This directory contains scripts used for the development of code-server.
- [./ci/dev/image](./dev/image)
- See [./docs/CONTRIBUTING.md](../docs/CONTRIBUTING.md) for docs on the development container.
- Click **Launch Instance** from your [EC2 dashboard](https://console.aws.amazon.com/ec2/v2/home).
- Select the Ubuntu Server 18.04 LTS (HVM), SSD Volume Type
- Select an appropriate instance size (we recommend t2.medium/large, depending
on team size and number of repositories/languages enabled), then
**Next: Configure Instance Details**.
- Select **Next: ...** until you get to the **Configure Security Group** page,
then add a **Custom TCP Rule** rule with port range set to `8080` and source
set to "Anywhere".
> Rules with source of 0.0.0.0/0 allow all IP addresses to access your
> instance. We recommend setting [security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html?icmpid=docs_ec2_console)
> to allow access from known IP addresses only.
- Click **Launch**.
- You will be prompted to create a key pair.
- From the dropdown choose "create a new pair", give the key pair a name.
- Click **Download Key Pair** and store the file in a safe place.
- Click **Launch Instances**.
- Head to your [EC2 dashboard](https://console.aws.amazon.com/ec2/v2/home)
and choose instances from the left panel.
- In the description of your EC2 instance copy the public DNS (iPv4) address
using the copy to clipboard button.
- Open a terminal on your computer and SSH into your instance:
```
ssh -i ${path to key pair} ubuntu@${public address}
```
## DigitalOcean
[Open your DigitalOcean dashboard](https://cloud.digitalocean.com/droplets/new)
to create a new droplet
- **Choose an image -** Select the **Distributions** tab and then choose Ubuntu.
- **Choose a size -** We recommend at least 4GB RAM and 2 CPU, more depending
on team size and number of repositories/languages enabled.
- Launch your instance.
- Open a terminal on your computer and SSH into your instance:
```
ssh root@${instance ip}
```
## Google Cloud
> Pre-requisite: Set up the [Google Cloud SDK](https://cloud.google.com/sdk/docs/)
> on your local machine
- [Open your Google Cloud console](https://console.cloud.google.com/compute/instances)
to create a new VM instance and click **Create Instance**.
- Choose an appropriate machine type (we recommend 2 vCPU and 7.5 GB RAM, more
depending on team size and number of repositories/languages enabled).
- Choose Ubuntu 16.04 LTS as your boot disk.
- Expand the "Management, security, disks, networking, sole tenancy" section,
go to the "Networking" tab, then under network tags add "code-server".
- Create your VM, and **take note** of its public IP address.
- Visit "VPC network" in the console and go to "Firewall rules". Create a new
firewall rule called "http-8080". Under "Target tags" add "code-server", and
under "Protocols and ports" tick "Specified protocols and ports" and "tcp".
Beside "tcp", add "8080", then create the rule.
- Open a terminal on your computer and SSH into your Google Cloud VM:
- Have [yarn](https://classic.yarnpkg.com/en/) installed (which is used to install JS packages and run development scripts)
- Have [nfpm](https://github.com/goreleaser/nfpm) (which is used to build `.deb` and `.rpm` packages and [jq](https://stedolan.github.io/jq/) (used to build code-server releases) installed
The [CI container](../ci/images/debian8/Dockerfile) is a useful reference for all
of the dependencies code-server uses.
## Development Workflow
```shell
yarn
yarn watch
# Visit http://localhost:8080 once the build is completed.
```
To develop inside an isolated Docker container:
```shell
./ci/dev/image/run.sh yarn
./ci/dev/image/run.sh yarn watch
```
`yarn watch` will live reload changes to the source.
### Updating VS Code
If you need to update VS Code, you can update the subtree with one line. Here's an example using the version 1.52:
```shell
# Add vscode as a new remote if you haven't already and fetch
# The standalone release is in ./release-standalone
# .deb, .rpm and the standalone archive are in ./release-packages
```
The `release.sh` script is equal to running:
```shell
yarn
yarn build
yarn build:vscode
yarn release
```
And `release-packages.sh` is equal to:
```shell
yarn release:standalone
yarn test:standalone-release
yarn package
```
For a faster release build, you can run instead:
```shell
KEEP_MODULES=1 ./ci/steps/release.sh
node ./release
```
## Structure
The `code-server` script serves an HTTP API for login and starting a remote VS Code process.
The CLI code is in [./src/node](./src/node) and the HTTP routes are implemented in
[./src/node/app](./src/node/app).
Most of the meaty parts are in the VS Code portion of the codebase under [./lib/vscode](./lib/vscode), which we described next.
### Modifications to VS Code
In v1 of code-server, we had a patch of VS Code that split the codebase into a front-end
and a server. The front-end consisted of all UI code, while the server ran the extensions
and exposed an API to the front-end for file access and all UI needs.
Over time, Microsoft added support to VS Code to run it on the web. They have made
the front-end open source, but not the server. As such, code-server v2 (and later) uses
the VS Code front-end and implements the server. We do this by using a git subtree to fork and modify VS Code. This code lives under [./lib/vscode](./lib/vscode).
Some noteworthy changes in our version of VS Code:
- Adding our build file, which includes our code and VS Code's web code
- Allowing multiple extension directories (both user and built-in)
- Modifying the loader, websocket, webview, service worker, and asset requests to
use the URL of the page as a base (and TLS, if necessary for the websocket)
- Sending client-side telemetry through the server
- Allowing modification of the display language
- Making it possible for us to load code on the client
- Making extensions work in the browser
- Making it possible to install extensions of any kind
- Fixing issue with getting disconnected when your machine sleeps or hibernates
- Adding connection type to web socket query parameters
As the web portion of VS Code matures, we'll be able to shrink and possibly
eliminate our modifications. In the meantime, upgrading the VS Code version requires
us to ensure that our changes are still applied and work as intended. In the future,
we'd like to run VS Code unit tests against our builds to ensure that features
work as expected.
**Note**: We have [extension docs](../ci/README.md) on the CI and build system.
If the functionality you're working on does NOT depend on code from VS Code, please
move it out and into code-server.
### Currently Known Issues
- Creating custom VS Code extensions and debugging them doesn't work
- Extension profiling and tips are currently disabled
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Anmol Sethi
