We use the cookie parser to remove the code-server token but by default
it encodes using encodeURIComponent, which encodes more than is strictly
necessary and can break proxied applications.
Now we pass the cookies through unchanged (other than removing the
code-server token).
Fixes#7927.
This can happen if you run the update multiple times and it was already
deleted from another run but not regenerated yet due to an early
failure like from a conflict.
The problem was that whenever the hashe needed an update, the current
patch would create a conflict which cannot be easily auto-resolved.
Instead, put the hashes in a separate patch that is deleted and
regenerated each time, avoiding the conflicts.
Also the web worker iframe hash was not being updated.
It needs to parse the version *after* the VS Code update, otherwise it
is just pulling whatever the previous version was.
That means we cannot use it in the step title without some refactoring;
opted to just omit it for now.
- Get rid of the global isActive mock; in particular the way it shadows
local ones seemed sketchy.
- No need for requireActual from my testing.
- Reword the comment for why we need setImmediate.
- Add the setImmediate to another test that seemed to only pass because
of an await on the timer call which is not actually a promise but had
the side effect of yielding.
- Always set fake/real timers in the before/after handlers and never in
individual tests.
Since this functionality requires information placed onto the request by
code-server (req.args) and Express (req.cookies), move the standalone
tests into the integration tests as the proxy can no longer run
correctly on its own without that context.
We could strip the header elsewhere or refactor in some way (pass in a
callback function for the stripping or something) but this seems like
the simplest and safest place at the moment to ensure we catch all uses
of the proxy.
In any case, I think it does lend more confidence to know we are testing
the proxy the way it will be used in practice. The downside is some
additional complexity when setting up tests, but at the moment I do not
think that exchange is overly burdensome.
Still had the old code that copied the system Node, which in the case of
cross-compilation will be the wrong one. Instead copy the one VS Code
downloads, which should be for the correct platform.
Before this was handled by an extra CI step, now we can just do it in
the release script.
Pulling it from the product.json since we already set it there, rather
than ask for it again via env var.
* 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.
* Preserve dependencies for e2e tests
To avoid having to install them again.
Also moved an env block to the root of the job.
* 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.
Just to be consistent with the other workflow. They are the same except
inputs treats booleans as booleans instead of strings, which seems like
it might be better anyway.
It has been broken for a long time (No available formula with the name
"code-server") but it looks like they have their own bot publishing
updates anyway.
Mostly because express-serve-static-core is an implicit dependency. We
could make it explicit, but the type we imported from it is just an
alias for qs.ParsedQs anyway.
Asher