This PR adds a minimum set of Helm tests for the Helm chart.
It's heavily based on the approach in [1], but uses a golden-files-based approach instead.
It also runs helm template directly instead of importing the entire Kubernetes API.
Golden files can be updated by running go test ./helm/tests -update or by running make update-golden-files.
[1] https://github.com/coder/enterprise-helmFixes#6552
* Fix type error in first user setup
* Save auth state
* Add template creation - wip
Remove saved auth state because it wasn't working
* Try adding the rest of the tests
Can't see if they work yet, waiting on a release
* Update playwright
* Update gitignore
* Write tests
* Format
* Update ignores
* Check that start worked
Co-authored-by: Ben Potter <ben@coder.com>
Co-authored-by: Ben Potter <ben@coder.com>
* chore: Improve project-wide prettier formatting and ignored files
* chore: `Run make fmt/prettier`
* Fix gitignore for `.vscode` folder so that ! works
* Add comment in `.prettierrc.yaml` to explain `.editorconfig`
* Remove scripts/apidocgen/markdown-template/README.md
* Use `yq` for processing prettierrc, update lib.sh dependency check
* Add `yq` to Dockerfile and Nix
This PR adds a package lifecycle and an Executor implementation that attempts to schedule a build of workspaces with autostart configured.
- lifecycle.Executor takes a chan time.Time in its constructor (e.g. time.Tick(time.Minute))
- Whenever a value is received from this channel, it executes one iteration of looping through the workspaces and triggering lifecycle operations.
- When the context passed to the executor is Done, it exits.
- Only workspaces that meet the following criteria will have a lifecycle operation applied to them:
- Workspace has a valid and non-empty autostart or autostop schedule (either)
- Workspace's last build was successful
- The following transitions will be applied depending on the current workspace state:
- If the workspace is currently running, it will be stopped.
- If the workspace is currently stopped, it will be started.
- Otherwise, nothing will be done.
- Workspace builds will be created with the same parameters and template version as the last successful build (for example, template version)
* 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
Cian Johnston
Bruno Quaresma
Presley Pizzo
Mathias Fredriksson
Geoffrey Huntley
Cian Johnston
Steven Masley
Bryan
