Summary:
Various time displays weren't quite right.
Details:
- Display date (not just time) of upcoming workspace stop in workspace
page
- Fix ttlShutdownAt for various cases + tests
- manual to non-manual
- unchanged/unmodified
- isBefore --> isSameOrBefore
- use the delta (off by _ error)
- pluralize units in dayjs.add
This does not fully resolve all requests in #2141, but just the piece of
when the workspace is actually stopping.
Next, we will adjust the default extension from 90 minutes to 4 hours.
Lastly, we can look at customizing the extension time in the extension
flow or with a pre-emptive prompt next to the stop time.
This does not fully close#2141, but builds upon #2171 to fulfill each
of the UX requests.
A next step (probably as a separate ticket) is to allow customizing
extension time pre-emptively.
Resolves: #1959
Summary:
The package tzdata is used to create a meaningful select-list for
timezone in the workspace schedule form.
Impact:
Improved UX. Furthermore, we guess your timezone if the form is being
initialized from scratch.
Resolves: #1901
Summary:
We had a homegrown parser that only understood numbers, not strings like
MON or TUES. We replace the homegrown parser with cron-parser.
Details:
This was nearly a straight drop-in.
Impact:
Much less code/maintenance burden :D
What I learned:
Don't trust the README, sometimes you just gotta read the code or import
it and try it out. The `fields` representation of the parsed expression
was missing from their docs. I might open an issue or PR to update them!
Resolves: #1958
Summary:
The workspace schedule form no longer disables certain fields based on
whether or not a start time is filled out. Instead, we validate that a
start time is provided if any of the days are checked.
Resolves: #1460
Summary:
An 'Extend' CTA on workspace schedule banner is added so that a user can
extend their workspace lease from the UI.
Details:
* feat: putWorkspaceExtension handler
* refactor: TypesGen dflt import in workspace.ts
* feat: defaultWorkspaceExtension util
Impact:
This completes the UI<-->CLI parity epic in an MVP way. Of course, a
future improvement to make is extending by times other than the default
90 minutes.
* refactor: isWorkspaceOn utility
Summary:
A utility is function is added that answers the question if a workspace
is on.
Impact:
This is a shared piece of logic in workspace scheduling presentations.
In particular it unblocks work in 1779, or at least allows an
implementation that shares details with the WorkspaceScheduleBanner.
Notes:
We could possibly instead return whether the workspace is "ON",
"UNKNOWN", or "OFF". Maybe a future improvement for that could be made
as the neds arrises.
* fix: derive running ws stop time from deadline
Summary:
When a workspace is on, the remaining time until shutdown needs to be
derived from the deadline timestamp, not implied from the TTL
Resolves: #1681
Summary:
- Moves WorkspaceSchedule out of WorkspaceStats
- Adds WorkspaceScheduleForm directory
Impact:
Improves breadth of our chromatic visual regression tests since the
examples for WorkspaceStats were non-representative of the component
Resolves: #1455Resolves: #1456
Summary:
Adds a page (accessible from Workspace Schedule section on a workspace) to edit a schedule.
Impact:
General parity with CLI for autostart/autostop: that is you can update your schedule from the UI
Summary:
The ErrorSummary accepts a retry callback and received improvements to
style and product copy
Impact:
This allows xstate-controlled pages to send re-fetch events
* feat: ui for editing ws schedule
Summary:
This presents a form component and storybook. The UI will be a routed
page and added into the dashboard in a separate PR. It is likely a
XService will be used at the page level to supply errors and actions to
this form.
Impact of Change:
Further progress on #1455
Squashed Commits:
* refactor: add className prop to Stack
combine classes with internal classes and an optional external className
to better control the Stack.
* fix: getFormHelpers helperText
the helperText logic was incorrect, the helperText would only show if not touched.
This PR is a squash of refactors and improvements in our Workspace and
WorkspaceSection components. An action prop is added to WorkspaceSection
and along the way, I refactored things that were not meeting conventions
or were hard to read. With this addition, I am further unblocked in
making auto-start/off editable in the UI, as I intend to use the Action
prop to trigger a modal (or routed page view) with the form.
Squashed commits:
* refactor: spaces for readability
It's hard to read HTMl markup without spaces on adjacent nodes
* refactor: props
Our components had unused props and arbitrary ordering.
* refactor: allow helperText in getFormHelpers
By passing in helperText, we will not accidentally overwrite it.
* fix: CreateWorkspaceForm name validation
Resolves: #1421
Summary:
There's no reason to build in `test/js`, since we have e2e tests that build.
Details:
- Remove superfluous `yarn build` from `test/js` step in CI
Relates to #1004 but does not fix it.
Summary:
When `maxWorkers` is high, there's a bug in `jest` that causes OOM kills.
Unfortunately, CI is experiencing this as well as local. For now, the best solution
is just reducing `maxWorkers`.
Resolves: #1004
Summary:
This adds the client-side implementation to match the types introduced
in #879 and #844 as well as a card in the Workspaces page to present
workspace the data.
Details:
* Added a convenient line break in the example schedule.Weekly
* Added missing `json:""` annotations in codersdk/workspaces.go
* Installed cronstrue for displaying human-friendly cron strings
* Adjusted/Added client-side types to match codersdk/workspaces.go
* Added new component WorkspaceSchedule.tsx
Next Steps:
The WorkspaceSchedule.tsx card only presents data (on purpose). In order
to make it PUT/modify data, a few changes will be made:
- a form for updating workspace schedule will be created
- the form will wrapped in a dialog or modal
- the WorkspaceSchedule card will have a way of opening the modal which
will likely be generalized up to WorkspaceSection.tsx
Impact:
This is user-facing
This does not fully resolve either #274 or #275 (I may further decompose
that work to reflect reality and keep things in small deliverable
increments), but adds significant progress towards both.
Summary:
Configures storybook with MUI themes as according to their
documentation. We were previously not aligned with their example.
See: https://storybook.js.org/addons/@react-theming/storybook-addon
Details:
- configure a providerFn for MUI with CssBaseline. We were previously
missing the CssBaseline implementation, causing the inconsistency.
Impact:
Resolves inconsistency between Storybook and production. I had tested
the Tabpanel in production vs Storybook. In storybook, the font had
fallen back to Times New Roman, whereas in production it had fallen back
to Inter. This was because of CssBaseline being configured as a child of
ThemeProvider.
Resolves: #914
This is an oversight from #896 . It turns out that because we use the GitHub integration with Chromatic, we don't need to wait for the results to be reported in the action - they get reported in the other checks created by Chromatic.
This option was spit-out in a check:
https://github.com/coder/coder/runs/5859427236?check_suite_focus=true#step:4:38
Relates to #444
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
This refactor introduces the following changes:
* re-order and re-comment items to match v1
* add EnvironmentPlugin for environment variables
* remove target (unnecessary, we will use browserslist)
G r e y