15beb98016
This adds a couple of missing pieces to the docs: - More info about `./develop.sh` - Steps to run the built coder binary manually - Starting the server - Logging in - Creating a project I attempted to keep them relatively agnostic so they wouldn't be out of date immediately when https://github.com/coder/coder/pull/422 is merged
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
Running
After building, the binaries will be available at:
dist/coder_{os}_{arch}/coder
For the purpose of these steps, an OS of linux and an arch of amd64 is assumed.
To manually run the server and go through first-time set up, run the following commands in separate terminals:
dist/coder_linux_amd64/coder daemon<-- starts the Coder server on port 3000dist/coder_linux_amd64/coder login http://localhost:3000<-- runs through first-time setup, creating a user and org
You'll now be able to login and access the server.
To create a project, run:
dist/coder_linux_amd64/coder projects create -d /path/to/project
Development
./develop.sh
The develop.sh script does three things:
- runs
coder daemonlocally on port3000 - runs
webpack-dev-serveron port8080 - sets up an initial user and organization
This is the recommend flow for working on the front-end, as hot-reload is set up as part of the webpack config.
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).