Summary:
There's no reason to build in `test/js`, since we have e2e tests that build.
Details:
- Remove superfluous `yarn build` from `test/js` step in CI
Relates to #1004 but does not fix it.
* Improve CLI documentation
* feat: Allow workspace resources to attach multiple agents
This enables a "kubernetes_pod" to attach multiple agents that
could be for multiple services. Each agent is required to have
a unique name, so SSH syntax is:
`coder ssh <workspace>.<agent>`
A resource can have zero agents too, they aren't required.
* Add tree view
* Improve table UI
* feat: Allow workspace resources to attach multiple agents
This enables a "kubernetes_pod" to attach multiple agents that
could be for multiple services. Each agent is required to have
a unique name, so SSH syntax is:
`coder ssh <workspace>.<agent>`
A resource can have zero agents too, they aren't required.
* Rename `tunnel` to `skip-tunnel`
This command was `true` by default, which causes
a confusing user experience.
* Add disclaimer about editing templates
* Add help to template create
* Improve workspace create flow
* Add end-to-end test for config-ssh
* Improve testing of config-ssh
* Fix workspace list
* feat: Add support for VS Code and JetBrains Gateway via SSH
This fixes various bugs that made this not work:
- Incorrect max message size in `peer`
- Incorrect reader buffer size in `peer`
- Lack of SFTP support in `agent`
- Lack of direct-tcpip support in `agent`
- Misuse of command from session. It should always use the shell
- Blocking on SSH session, only allowing one at a time
Fixes#833 too.
* Fix config-ssh command with socat
* chore: add feature request issue template
* Update .github/ISSUE_TEMPLATE/feature.md
Co-authored-by: G r e y <grey@coder.com>
* Update .github/ISSUE_TEMPLATE/feature.md
Co-authored-by: G r e y <grey@coder.com>
Co-authored-by: G r e y <grey@coder.com>
* ci: Enable forks to run CI
All steps that require tokens are optional for forks,
and will be skipped if the owner is not "coder".
* Empty commit to force CI
This is an oversight from #896 . It turns out that because we use the GitHub integration with Chromatic, we don't need to wait for the results to be reported in the action - they get reported in the other checks created by Chromatic.
This option was spit-out in a check:
https://github.com/coder/coder/runs/5859427236?check_suite_focus=true#step:4:38
Relates to #444
Resolves: #444
Summary:
This commit installs and configures a GH action for chromatic. Chromatic
is used for snapshot testing build-over-build.
Details:
* chore: install chromatic
* chore: add chromatic package.json script
Suggested by the docs for convenience so that we can run chromatic like:
```console
yarn run chromatic ...
```
* chore: gitignore storybook builds
* ci: configure chromatic
This action configures chromatic to run in CI on pushes to all branches.
By running this in CI, we get the following:
- snapshot (build-over-build)
- checks in our CI
The snapshots and build-over-build behavior are per branch; this way we
can work on a feature branch without worrying about changes being made
to mainline independently.
* chore: remove manual storybook build from CI
This is now the responsibility of Chromatic
This should enfore a standardized commit message without a scope.
The repository isn't complex enough to require scopes yet, so we
can punt this down the road!
* ci: Fix dogfood installation by forcing default configurations
The dpkg prompt to override config files was
appearing, but this will auto-approve it.
* Add CAP_NET_BIND_SERVICE to allow listening on :443
* feat: Add TLS support
This adds numerous flags with inspiration taken from Vault
for configuring TLS inside Coder.
This enables secure deployments without a proxy, like Cloudflare.
* Update cli/start.go
Co-authored-by: Colin Adler <colin@coder.com>
* Fix flag help in coder.env
Co-authored-by: Colin Adler <colin@coder.com>
* feat: Add systemd service and production deployment
This modifies CI to use a dpkg produced from release to update and
run Coder on a tiny VM in GCP.
It's intentionally kept simple, because customers should
be able to get this same easy install experience.
* Update globalSetup.ts
* Update globalSetup.ts
* Update globalSetup.ts
* Update coder.yaml
* Use pinned version of Go
* chore: Improve CI builds by caching Go modules
* Skip running with `race` on non-Linux systems
* Fix darwin file descriptor error
* Fix log after close
* Improve PostgreSQL test speeds
* Fix parallel connections with PostgreSQL tests
* Fix CI flake
* Separate test/go into PostgreSQL
Summary:
Partial port of v1 CODEOWNERS -> v2
Impact:
Coder FE will be pinged to review changes in site. We do not have a check that
requires an explicit approval, but it helps review cycle iteration
This fixes#433 - a test flake in E2E (intermittent `ESOCKETTIMEDOUT` errors on MacOS).
The main issue is that, occasionally, for very large dependencies (like `@material-ui/icons`) - yarn can actually time out! We researched this in-depth in v1: https://github.com/coder/m/pull/10040 and fixed it successfully there, by increasing the timeout for yarn.
However, this also highlighted the fact that our `node_modules` caching behavior wasn't correct - we should very rarely see a timeout issue like this, because `@material-ui/icons` should be cached.
It turns out that we weren't falling back to the latest cached `node_modules` if there was a miss - so anytime the lock file changed, we'd invalidate the cache, and not restore the previous one. This can be improved by using the [`restore-keys`](https://github.com/coder/m/pull/10040) parameter of the [`@actions/cache`](https://github.com/actions/cache)... and in fact we already do this for the `go` dependencies.
So this fix does two things:
- Improve the caching behavior, such that we should rarely have to install `@material-ui/icons` (and other large dependencies)
- When we do have to install, update the timeout so that we can avoid random `ESOCKETTIMEDOUT` errors
Fix for #348 - migrate our NextJS project to a pure webpack project w/ a single bundle
- [x] Switch from `next/link` to `react-router-dom`'s link
> This part was easy - just change the import to `import { Link } from "react-router-dom"` and `<Link href={...} />` to `<Link to={...} />`
- [x] Switch from `next/router` to `react-router-dom`'s paradigms (`useNavigation`, `useLocation`, and `useParams`)
> `router.push` can be converted to `navigate(...)` (provided by the `useNavigate` hook)
> `router.replace` can be converted `navigate(..., {replace: true})`
> Query parameters (`const { query } = useRouter`) can be converted to `const query = useParams()`)
- [x] Implement client-side routing with `react-router-dom`
> Parameterized routes in NextJS like `projects/[organization]/[project]` would look like:
> ```
> <Route path="projects">
> <Route path=":organization/:project">
> <Route index element={<ProjectPage />} />
> </Route>
> </Route>
> ```
I've hooked up a `build:analyze` command that spins up a server to show the bundle size:
<img width="1303" alt="image" src="https://user-images.githubusercontent.com/88213859/157496889-87c5fdcd-fad1-4f2e-b7b6-437aebf99641.png">
The bundle looks OK, but there are some opportunities for improvement - the heavy-weight dependencies, like React, ReactDOM, Material-UI, and lodash could be brought in via a CDN: https://stackoverflow.com/questions/50645796/how-to-import-reactjs-material-ui-using-a-cdn-through-webpacks-externals
This brings an initial E2E test (really, an integration test - it's only running the server locally, as opposed to against a deployment - but it'd be easy to point playwright to a deployment).
Demo gif:
This test exercises a minimal flow for login:
- Run the `coderd` binary to start a server on 3000
- Create an initial user as part of setup
- Go through the login flow and verify we land on the projects page
It will be useful to have to ensure that #360 doesn't introduce a regression in the login flow
Future E2E tests that would be useful:
- Create a project & verify it shows in the UI
- Create a workspace and verify it shows in the UI
Joe Previte
