LAB/coder_code-server
1
0
Fork 0
mirror of https://github.com/coder/code-server.git synced 2026-03-30 00:02:16 +08:00
Code Issues Packages Projects Releases Wiki Activity
coder_code-server/docs/MAINTAINING.md
Asher 2d08e6e95b
Refactor releases to use VS Code packaging 
Instead of building the linux-x64 package, stripping the modules, then
installing them again, we build the correct target and use the modules
as they are.

This means we do not have to copy all the post-processing steps like the
ones that delete unnecessary modules.

For the NPM package we still publish the linux-x64 package (without
modules of course).  This means npm installations do not get that same
post-processing.

Another advantage of this is that we can run the release immediately
without having to wait for the build step, or on a commit that no longer
has a build artifact, since they all build individually now.  We could
try sharing the core-ci build step, but leaving that alone for now.

I also converted the macOS jobs into a matrix.

Deleted the CI readme because it was out of date and seemed to just
repeat what should be described in the scripts anyway.

Removed a section about Homebrew since we do not maintain that anymore.

It looks like there is no need to symlink node_modules.asar anymore.
2026-03-27 16:15:44 -08:00

4.1 KiB
Raw Blame History

Maintaining

We keep code-server up to date with VS Code releases (there are usually two or three a month) but we are not generally actively developing code-server aside from fixing regressions.

Most of the work is keeping on top of issues and discussions.

Releasing

  1. Check that the changelog lists all the important changes.
  2. Make sure the changelog entry lists the current version of VS Code.
  3. Go to GitHub Actions > Draft release > Run workflow on the commit you want to release. For the version we match VS Code's minor and patch version. The patch number may become temporarily out of sync if we need to put out a patch, but if we make our own minor change then we will not release it until the next minor VS Code release.
  4. CI will build an NPM package and platform-specific packages, and upload those to a draft release.
  5. Update the resulting draft release with the changelog contents.
  6. Publish the draft release after validating it.
  7. Update the changelog with the release date and bump the Helm chart version once the Docker images have published.
  8. Merge the PR submitted to coder/code-server-aur repo.

Release Candidates

We prefer to do release candidates so the community can test things before a full-blown release. To do this follow the same steps as above but:

  1. Add a -rc.<number> suffix to the version.
  2. When you publish the release select "pre-release". CI will not automatically publish pre-releases.
  3. Do not update the chart version or merge in the changelog until the final release.

AUR

We publish to AUR as a package here. This process is manual and can be done by following the steps in this repo.

Docker

We publish code-server as a Docker image here, tagging it both with the version and latest.

This is currently automated with the release process.

nixpkgs

We publish code-server in nixpkgs but it must be updated manually.

npm

We publish code-server as a npm package here.

This is currently automated with the release process.

Testing

Our testing structure is laid out under our Contributing docs.

If you're ever looking to add more tests, here are a few ways to get started:

  • run npm run test:unit and look at the coverage chart. You'll see all the uncovered lines. This is a good place to start.
  • look at test/scripts to see which scripts are tested. We can always use more tests there.
  • look at test/e2e. We can always use more end-to-end tests.

Otherwise, talk to a current maintainer and ask which part of the codebase is lacking most when it comes to tests.

Documentation

Troubleshooting

Our docs are hosted on Vercel. Vercel only shows logs in realtime, which means you need to have the logs open in one tab and reproduce your error in another tab. Since our logs are private to Coder the organization, you can only follow these steps if you're a Coder employee. Ask a maintainer for help if you need it.

Taking a real scenario, let's say you wanted to troubleshoot this docs change. Here is how you would do it:

  1. Go to https://vercel.com/codercom/codercom
  2. Click "View Function Logs"
  3. In a separate tab, open the preview link from github-actions-bot
  4. Now look at the function logs and see if there are errors in the logs