X Tutup
Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: coder/code-server
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: main
Choose a base ref
...
head repository: coder/code-server
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: asher/module-cleanup
Choose a head ref
Checking mergeability… Don’t worry, you can still create the pull request.
  • 3 commits
  • 19 files changed
  • 1 contributor

Commits on Mar 27, 2026

  1. Allow setting the VS Code build target 

    For the NPM package (and tests, at least for now), we will still use
linux-x64, but this is going to allow using the platform build targets
for our standalone releases so we can avoid having to copy all the
packaging steps (like cleaning up modules).

This does mean that the NPM package when installed will be missing those
cleanup steps.  Possibly we can try to break out the packaging step into
a something that can be ran standalone (which will also require
installing dev dependencies like gulp) but not sure how much work this
would be.
    @code-asher
    code-asher committed Mar 27, 2026
    Configuration menu
    Copy the full SHA
    3f1a650 View commit details
    Browse the repository at this point in the history

  2. Preserve dependencies for e2e tests 

    To avoid having to install them again.

Also moved an env block to the root of the  job.
    @code-asher
    code-asher committed Mar 27, 2026
    Configuration menu
    Copy the full SHA
    d2a395e View commit details
    Browse the repository at this point in the history

  3. 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.
    @code-asher
    code-asher committed Mar 27, 2026
    Configuration menu
    Copy the full SHA
    3c4c09f View commit details
    Browse the repository at this point in the history
Loading
X Tutup