Bryan
20faf897c9
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
Coder v2
This repository contains source code for Coder V2. Additional documentation:
Directory Structure
.github/: Settings for Dependabot for updating dependencies and build/deploy pipelines with GitHub Actions.semantic.yaml: Configuration for semantic pull requests\
examples: Example terraform project templates.site: Front-end UI code.
Development
Pre-requisites
gitgoversion 1.17, with theGOPATHenvironment variable setnodeyarn
Cloning
git clone https://github.com/coder/codercd coder
Building
make buildmake install
The coder CLI binary will now be available at $GOPATH/bin/coder
Development
./develop.sh
The develop.sh script runs the server locally on port 3000, and runs a hot-reload server for front-end code on 8080.
Front-End Plan
For the front-end team, we're planning on 2 phases to the 'v2' work:
Phase 1
Phase 1 is the 'new-wine-in-an-old-bottle' approach - we want to preserve the look and feel (UX) of v1, while testing and validating the market fit of our new v2 provisioner model. This means that we'll preserve Material UI and re-use components from v1 (porting them over to the v2 codebase).
Phase 2
Phase 2 is the 'new-wine-in-a-new-bottle' - which we can do once we've successfully packaged the new wine in the old bottle.
In other words, once we've validated that the new strategy fits and is desirable for our customers, we'd like to build a new, v2-native UI (leveraging designers on the team to build a first-class experience around the new provisioner model).