feat: workspace view for schedules #991
Conversation
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.
Codecov Report
@@ Coverage Diff @@
## main #991 +/- ##
==========================================
+ Coverage 66.53% 66.77% +0.23%
==========================================
Files 240 242 +2
Lines 14588 14639 +51
Branches 115 119 +4
==========================================
+ Hits 9706 9775 +69
+ Misses 3892 3882 -10
+ Partials 990 982 -8
Continue to review full report at Codecov.
|
|
@johnstcn and @presleyp - I assigned you as UI reviewers on Chromatic. The "overview" of this PR on chromatic where you can approve is here: https://www.chromatic.com/pullrequest?appId=624de63c6aacee003aa84340&number=991 The individual changes/diffs for the latest build are here: https://www.chromatic.com/build?appId=624de63c6aacee003aa84340&number=312 Please note that the latter URL changes on each build whereas the former is static for this PR. If you wish to navigate to the most recent build you can either:
I'm trying to make comments like these until we've had more experience with the Chromatic workflow, sorry if superfluous! |
| * @example | ||
| * expandScheduleCronString("30 9 1-5") // -> "30 9 * * 1-5" | ||
| */ | ||
| export const expandScheduleCronString = (schedule: string): string => { |
There was a problem hiding this comment.
(non-blocking): Would it simplify the frontend code to alter the backend to support a full valid 5-value cron string?
There was a problem hiding this comment.
Good question, hmm. Only if the backend was validating that we always received a full valid 5-value cron string (with optional timezone). The only reason it would help is so that I know I can pass these strings directly from the backend into JS cron libraries for validation and display.
Given that right now I have to first prepare them by using this expandScheduleCronString, which is a simple and well-tested function, I'm not overly concerned about it, but I do think a db migration for it that would have to expand stored values in the same way would be more complicated.
One situation I don't want is a user being able to set a 5-value cron string via CLI or API that sets day of month and month values. While the backend may ignore them, the FE would accidentally produce a confusing human-readable string for them like this:
At 09:30 on day-of-month 1 and on every day-of-week from Monday through Friday in February.
instead of
At 09:30 on Monday through Friday.
I plan on making the C/U form a set of widgets that under the hood produce a cron string. So imagine an input for time and another with the 7 days of the week that you select/deselect.
Conceptually, the form will look like:
time (TIMEZONE)
[ 9:30 c ]
days
[ ] Sun [x] Mon [x] Tues [x] Weds [x] Thurs [x] Fri [ ] Sat
Your workspace will auto-[start/stop] at 09:30 on Monday through Friday.
EDIT: Overall, my opinion is that the backend remains with the 3-value crontab as the cost is simply just this function we're looking at right now, which I think is acceptable. It doesn't seem like we fully bypass cost any which way unless the backend only supports 5-value cron strings and validates that day-of-month and month are *.
There was a problem hiding this comment.
Gotcha. Opened #993 for this; I can make the necessary frontend changes if needed.
There was a problem hiding this comment.
I think the only changes that would be needed in a PR targeting #993 would be removing this function, which is ezpz 🎉
| * DEFAULT_TIMEZONE is the default timezone that crontab assumes unless one is | ||
| * specified. | ||
| */ | ||
| const DEFAULT_TIMEZONE = "UTC" |
| // Must be kept in sync with backend Workspace struct | ||
| /** | ||
| * @remarks Keep in sync with codersdk/workspaces.go | ||
| */ |
|
This resolved #1059 |
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:
json:""annotations in codersdk/workspaces.goNext Steps:
The WorkspaceSchedule.tsx card only presents data (on purpose). In order
to make it PUT/modify data, a few changes will be made:
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.