You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactor CLI manager to support multiple deployments (#213)
* Remove unused wizard variable
* Add more logs around authenticating
Also rename the function since it loads all workspaces, not just one.
* Test on macOS and Windows
Since the comments are now out of date I removed them; I figure it is
more or less as easy to just read the workflow to see what it does.
* Refactor CLI manager to support multiple deployments
Currently multiple deployments will delete each other's binaries so this
uses a directory for each deployment host to store the binaries.
Add a catch for download errors; previously they would go unnoticed.
Also refactor the download a little; instead of checking for the file's
existence catch the appropriate error and set the permissions from
Kotlin code rather than spawning chmod.
Remove a chunk of code where we configure the CLI again before moving to
the next step; we already do that when we first connect (plus it is
missing some checks like making sure the CLI has actually been
downloaded and is the right version, etc). This also makes it
unnecessary to globally store the version and CLI path on the model
since we now only do it in one spot.
This is just a first step; in a future PR the config code will all be
extracted out since we will want to configure every time we try to
connect (rather than just in the initial setup step) since otherwise the
recent connections can fail if you have configured a different
deployment in the meantime (and probably reconnections would also fail
if you already have an IDE open) or if you have restarted (since the
binaries are currently in tmp). We will also need to configure
ourselves since `config-ssh` does not support multiple deployments and
we want to add an environment variable via SetEnv.
* Encapsulate process execution in CLI manager
We will need to create a new function for config-ssh anyway since we
will be doing our own thing rather than spawning the CLI in order to
support multiple deployments so this preemptively encapsulates that
logic.
* Move CLI config read into CLI manager
* Add tests for config dir
* Redact token from logger output
* Use ETag for downloading binary
This way we will not need to name the binaries with their versions or
otherwise extract the version from each binary since we can just grab
their hash and set that in the request. This also means we will not
need to remove old versions as there will only be the one file.
* Accept gzip when downloading binary
* Store binary in data directory
The @jvmoverloads annotations make Kotlin generate overloads otherwise
the test code thinks the optional arguments are not optional.
* Include port in sub-directory if it is set
* Test against a mocked server
Environment variables can be used to test against a real deployment.
I now just check if the file is executable rather than trying to
actually execute it since we would need to actually compile something
that can run as a .exe on Windows.
* Split out version check for testing
* Handle IDN
* Use real deployment for just one test
That is enough to prove the downloading works and the rest can just test
their own extra assumptions on top of that.
* Mention tests in the readme
@@ -87,7 +87,9 @@ The properties listed define the plugin itself or configure the [gradle-intellij
87
87
88
88
### Testing
89
89
90
-
No functional or UI tests are available yet.
90
+
Run tests with `./gradlew test`. By default this will test against
91
+
`https://dev.coder.com` but you can set `CODER_GATEWAY_TEST_DEPLOYMENT` to a URL
92
+
of your choice or to `mock` to use mocks only.
91
93
92
94
### Code Monitoring
93
95
@@ -127,7 +129,8 @@ In the `.github/workflows` directory, you can find definitions for the following
127
129
- Triggered on `Publish release` event.
128
130
- Updates `CHANGELOG.md` file with the content provided with the release note.
129
131
- Publishes the plugin to JetBrains Marketplace using the provided `PUBLISH_TOKEN`.
130
-
- Sets publish channel depending on the plugin version, i.e. `1.0.0-beta` -> `beta` channel. For now, both `main` and `eap` branches are published on default release channel.
132
+
- Sets publish channel depending on the plugin version, i.e. `1.0.0-beta` -> `beta` channel. For now, both `main`
133
+
and `eap` branches are published on default release channel.
0 commit comments