[](https://github.com/coder/coder/actions/workflows/coder.yaml)

[](https://codecov.io/gh/coder/coder)

- `.github/`: Settings for [Dependabot for updating dependencies](https://docs.github.com/en/code-security/supply-chain-security/customizing-dependency-updates) and [build/deploy pipelines with GitHub Actions](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions).

- [`semantic.yaml`](./github/semantic.yaml): Configuration for [semantic pull requests](https://github.com/apps/semantic-pull-requests)

- `examples`: Example terraform project templates.

- `site`: Front-end UI code.

- `git`

- `go` version 1.17, with the `GOPATH` environment variable set

- `node`

- `yarn`

- `git clone https://github.com/coder/coder`

- `cd coder`

- `make build`

- `make install`

The `coder` CLI binary will now be available at `$GOPATH/bin/coder`

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.

- `dist/coder_linux_amd64/coder projects create -d /path/to/project`

- `./develop.sh`

The `develop.sh` script does three things:

- runs `coder daemon` locally on port `3000`

- runs `webpack-dev-server` on port `8080`

- 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.

Note that `./develop.sh` creates a user and allows you to log into the UI, but does not log you into the CLI, which is required for creating a project. Use the `login` command above before the `projects create` command.

While we're working on automating XState typegen, you may need to run `yarn typegen` from `site`.

For the front-end team, we're planning on 2 phases to the 'v2' work:

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 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).