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
* Install and configure XState
* userXService - typegen not working yet
* Lint, fix error transitions
* Lint
* Change initial state to handle loss of state
* Fix gitignore
* Fix types by hook or by crook
* Use xservice in all pages
* Glue/visual component separation
* Fix dependency merge
* Lint
* Remove UserContext
* Remove inspector
* Add typegen command to site/out
* Fix index page redirects
* DRY up nav and redirects
* Moves based on merge
* Moving Page helpers into Page dir
* Move xservice into src, update script
* Move and storybook navbarview
* Update docs
* Install MSW
* Reorganization, with apologies
* Missed spots
* Add mock handlers
* Configure jest for msw
* Fix typos
* Shift unit test to NavbarView
* Fix test types
* Rename NavbarView test
* Attempt at test, wip
* Fix config
* Be logged out, only warn
* Conditionally show text to help test
* Use a Context for MSW's sake
* mocks -> test_helpers
* Enable dev tools
* Format
* Fix import
* Fixes
* Lint
* run typegen postinstall
Co-authored-by: Bryan Phelps <bryan@coder.com>
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
Fixes#244
- Adds `jest-junit`
- Configures `jest-junit` to output `junit.xml` in `site/test_results`
- Uploads the emitted `junit.xml` to datadog as part of the `test/js` workflow
This hooks up `storybook`, which the front-end team has enjoyed using in the v1 codebase - it makes it quick and easy to view and test components in isolation.
The `<LoadingButton />` has a simple story added now, so if you run `yarn storybook`, you can preview it in various states:
This will be helpful as we bring more front-end devs to help build v2 out.
This refactors the front-end collateral to all live within `site` - so no `package.json` at the root.
The reason we had this initially is that the jest test run and NextJS actually require having _two_ different `tsconfig`s - Next needs `jsx:"preserve"`, while jest needs `jsx:"react"` - we were using `tsconfig`s at different levels at the hierarchy to manage this.
I changed this behavior to still use two different `tsconfig.json`s, which is mandatory - but just side-by-side in `site`.
Once that's fixed, it was easy to move everything into `site`
Follow up from: https://github.com/coder/coder/pull/118#discussion_r796244577
This change bundles the static assets like we have for v1 - using the [`embed`](https://pkg.go.dev/embed) go package. Fixes#22
In addition, it sets up a development script that runs `coderd` locally and serves the front-end, with hot-reloading. The script used is `./develop.sh`:
> NOTE: The UI is still placeholder, of course. Need to start testing out a simple, placeholder flow for the new v2 world as a next step
Summary of changes:
- Add build steps for `go` in the `Makefile`
- Add a step for production build, in which we use the `embed` tag
- Add a step for development, which doesn't need the `embed` tag - so we don't need to build the front-end twice
- Add `next export` build step to output front-end artifacts in `out`
- Add a `site` package for `go`
- Add `embed_static.go` and `embed.go`. This is mostly brought in as-is from v1, except removing some intercom/sentry CSP entries that we aren't using.
- Add a [next development server](https://nextjs.org/docs/advanced-features/custom-server)
- Add a `v2-dev` script, that runs `coderd` and the `next` dev server side-by-side
- Use the `site` package as the fallback handler.
- Add `.gitignore` entries for additional build collateral
* chore: Initial database scaffolding
This implements migrations and code generation for interfacing with a PostgreSQL database.
A dependency is added for the "postgres" binary on the host, but that seems like an acceptable requirement considering it's our primary database.
An in-memory database object can be created for simple cross-OS and fast testing.
* Run tests in CI
* Use Docker instead of binaries on the host
* Skip database tests on non-Linux operating systems
* chore: Add golangci-lint and codecov
* Use consistent file names
This implements an initial GitHub Actions workflow for us - to be run on PRs and on `main` commits.
This just implements a really simple `style/fmt` check - running `prettier` on the `README.md`.
I assumed we'll stick with using a top-level `Makefile` for commands like in `m` and `link` - but open to alternatives, too!
Since I was adding a `package.json` and `node_modules` for this, I realized we were missing `.gitignore`s, so I added some a subset of the ignore files from `coder/m`
Colin Adler
