Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

feat: send native system notification on scheduled workspace shutdown#1414

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
johnstcn merged 6 commits intomainfromcj/gh-861/cli-autostop-notify
May 13, 2022

Conversation

johnstcn
Copy link
Member

@johnstcnjohnstcn commentedMay 12, 2022
edited
Loading

This commit adds a fairly generic notification package and uses it
to notify users connected over SSH of pending workspace shutdowns.

It usesgithub.com/gen2brain/beeep under the hood for actually doing the platform-specific heavy lifting.

I've tested it out on MacOS and Windows and it seems to work fine there; I don't have a Linux desktop around with dbus and all of that associated stuff setup to test it there though.

Theautobuild/notify package might be a bit of a step too far, but it lets me easily test the notification timing logic without worrying about anything else -- which is arguably the most important part.

Subtasks

  • Added a basic proof-of-concept
  • Refactored notification scheduling logic to its own package, unit tests.
  • Moved the actual notification meat and bones to the SSH command.

Additions

  • Ensured only one process at a time can notify per workspace (usinggofrs/flock)
  • Added a convenience methodnotifier.Notify for folks who don't like making their own timers.

Fixes#861

This commit adds a fairly generic notification package and uses itto notify users connected over SSH of pending workspace shutdowns.
@johnstcnjohnstcn requested a review froma teamMay 12, 2022 21:08
@johnstcnjohnstcn self-assigned thisMay 12, 2022
@codecov
Copy link

codecovbot commentedMay 12, 2022
edited
Loading

Codecov Report

Merging#1414 (4f39908) intomain (64e408c) willincrease coverage by0.08%.
The diff coverage is70.96%.

@@            Coverage Diff             @@##             main    #1414      +/-   ##==========================================+ Coverage   67.13%   67.22%   +0.08%==========================================  Files         287      288       +1       Lines       19307    19424     +117       Branches      241      244       +3     ==========================================+ Hits        12962    13057      +95- Misses       5007     5025      +18- Partials     1338     1342       +4
FlagCoverage Δ
unittest-go-macos-latest54.28% <70.96%> (+0.13%)⬆️
unittest-go-postgres-65.56% <70.96%> (-0.03%)⬇️
unittest-go-ubuntu-latest56.65% <70.96%> (+0.17%)⬆️
unittest-go-windows-202252.65% <70.96%> (+0.13%)⬆️
unittest-js75.26% <ø> (+0.61%)⬆️
Impacted FilesCoverage Δ
cli/ssh.go39.53% <35.71%> (-1.24%)⬇️
coderd/autobuild/notify/notifier.go100.00% <100.00%> (ø)
site/src/components/Section/Section.tsx61.11% <0.00%> (-5.56%)⬇️
site/src/xServices/auth/authXService.ts78.12% <0.00%> (-4.49%)⬇️
coderd/workspaceagents.go55.34% <0.00%> (-2.56%)⬇️
peer/channel.go85.96% <0.00%> (ø)
coderd/rbac/object.go100.00% <0.00%> (ø)
coderd/provisionerdaemons.go63.31% <0.00%> (ø)
provisionerd/provisionerd.go77.37% <0.00%> (ø)
site/src/xServices/auth/authSelectors.ts100.00% <0.00%> (ø)
... and8 more

Continue to review full report at Codecov.

Legend -Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered byCodecov. Last update64e408c...4f39908. Read thecomment docs.

@bpmct
Copy link
Member

bpmct commentedMay 12, 2022
edited
Loading

I've tested it out on MacOS and Windows and it seems to work fine there; I don't have a Linux desktop around with dbus and all of that associated stuff setup to test it there though.

Sounds like we need to add some templates for test desktops on v2 dogfood

Copy link
Member

@ammarioammario left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Per my other comment, if the notification triggers onevery open coder-cli instance, then this may overwhelm the user.

Copy link
Member

@mafredrimafredri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Sorry for the sheer amount of comments 😅. I like how you managed to keep the condition logic simple!

t.Run(testCase.Name, func(t *testing.T) {
ch := make(chan time.Time)
numConditions := atomic.NewInt64(0)
numCalls := atomic.NewInt64(0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Cool use ofatomic, I need to remember this!☺️

Copy link
Member

@mafredrimafredri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Just one more question but overall very nice!

type Notifier struct {
lock sync.Mutex
condition Condition
notifiedAt map[time.Duration]bool
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Would it make sense to move this intopollOnce? My thought is that this map never reset, and a notification can only be shown once percountdown entry (for the lifetime of theNotifier). Not sure if that's a problem or not though.

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

We could move intoPoll, but not intopollOnce.
If we did that, we could probably also remove thesync.Mutex.
I like the idea of the sameNotifier instance keeping track of what it's already notified between successive calls toPoll() though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Ok that makes sense. I guess it's mostly a question of how the package is to be used and what the user (might) expect to happen. I imagine this will not be a problem forssh since when the workspace stops, so does the command, so the notifier doesn't outlive its purpose.

Comment on lines +196 to +212
// Attempt to poll workspace autostop. We write a per-workspace lockfile to
// avoid spamming the user with notifications in case of multiple instances
// of the CLI running simultaneously.
func tryPollWorkspaceAutostop(ctx context.Context, client *codersdk.Client, workspace codersdk.Workspace) (stop func()) {
lock := flock.New(filepath.Join(os.TempDir(), "coder-autostop-notify-"+workspace.ID.String()))
condition := notifyCondition(ctx, client, workspace.ID, lock)
return notify.Notify(condition, autostopPollInterval, autostopNotifyCountdown...)
}

// Notify the user if the workspace is due to shutdown.
func notifyCondition(ctx context.Context, client *codersdk.Client, workspaceID uuid.UUID, lock *flock.Flock) notify.Condition {
return func(now time.Time) (deadline time.Time, callback func()) {
// Keep trying to regain the lock.
locked, err := lock.TryLockContext(ctx, autostopPollInterval)
if err != nil || !locked {
return time.Time{}, nil
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I wonder if it'd be best to place as much of this as possible in thenotify package. eg. forcoder port-forward we'd probably want to do the exact same type of thing.

I could imagine for the frontend too, we would send a notification via WebSocket or something!

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

That could be a good idea when we have a better idea of what different use-cases crop up.
I fear I've already over-engineered this enough as it is!

Copy link
Member

@ammarioammario left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I didn't review the code, but if onlyone notification is sent acrossall coder-clis, I'm good with this.

@johnstcnjohnstcn merged commitb2760b1 intomainMay 13, 2022
@johnstcnjohnstcn deleted the cj/gh-861/cli-autostop-notify branchMay 13, 2022 17:09
@missknissmisskniss added this to theV2 Beta milestoneMay 15, 2022
@greyscaledgreyscaled mentioned this pull requestMay 21, 2022
kylecarbs pushed a commit that referenced this pull requestJun 10, 2022
…#1414)* feat: send native system notification on scheduled workspace shutdownThis commit adds a fairly generic notification package and uses itto notify users connected over SSH of pending workspace shutdowns.Only one notification will be sent at most 5 minutes prior to the scheduledshutdown, and only one CLI instance will send notifications if multipleinstances are running.
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@mafredrimafredrimafredri approved these changes

@kylecarbskylecarbskylecarbs left review comments

@ammarioammarioammario approved these changes

@f0sself0sselAwaiting requested review from f0ssel

Assignees

@johnstcnjohnstcn

Labels
None yet
Projects
None yet
Milestone
V2 Beta
Development

Successfully merging this pull request may close these issues.

On SSH connection, notify users of scheduled auto-stop for Auto On/Off
7 participants
@johnstcn@bpmct@mafredri@kylecarbs@ammario@f0ssel@misskniss

[8]ページ先頭

©2009-2025 Movatter.jp