Skip to content

Updates notification#3119

Merged
rejas merged 5 commits intoMagicMirrorOrg:developfrom
bugsounet:updates-notification
Jun 8, 2023
Merged

Updates notification#3119
rejas merged 5 commits intoMagicMirrorOrg:developfrom
bugsounet:updates-notification

Conversation

@bugsounet
Copy link
Contributor

Hi,

Like some default modules, I propose to send an UPDATES notification in an array with the git information of these modules

This allows developers to create their own auto-update system (which I've been using in my case since 3 years, with automatic things)

Of course, for security reasons MagicMirror is excluded

bugsounet and others added 4 commits June 7, 2023 17:18
update deps incl. electron to v25, fix stylelint segmentation dump (#…
@khassel khassel requested a review from rejas June 8, 2023 15:55
}

return gitResultList;
return this.gitResultList;
Copy link
Collaborator

Choose a reason for hiding this comment

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

now that gitResultList is global we dont need to return it, or do we?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes it's a global value only on the GitHelper class (constructor) but not available somewhere else (like this.gitRepos)
you have to query GitHelper to retrieve this value

I prefert save the result of getRepos in a global value
Why ? because, I reuse it for checkUpdates

it saves time (perhaps minimal) to pick up from the node helper repos values of performFetch function and do the processing.
The values are already present elsewhere (gitHelper) so much to exploit them directly

refreshInterval: 24 * 60 * 60 * 1000, // one day
ignoreModules: []
ignoreModules: [],
sendUpdatesNotifications: true
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we should set it to false for one release cycle so that we can test the functionality in the main branch and set it to true later.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, As you want.
I'm only suggesting, it's a you to decide :)

@rejas
Copy link
Collaborator

rejas commented Jun 8, 2023

Nice PR and functionality. Adding a test for this would be a nice addition (cherry on top) :-)

@bugsounet
Copy link
Contributor Author

After, we (or I) can create a template for an auto-update of a module for testing (it's only for modules of developer)

Note:

  • I use my own protocol for this since 3 years now (works fine ! and makes you lazy)
  • Able to update properly a module and restart MM² when update done
  • Catch any error ? (with alert)
  • Naturally, I will not apply this rules to MM² (and default modules)

Is this what you are looking for?

@bugsounet bugsounet requested a review from rejas June 8, 2023 17:45
@codecov-commenter
Copy link

Codecov Report

Merging #3119 (a03803e) into develop (a56b929) will increase coverage by 0.02%.
The diff coverage is 25.71%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@             Coverage Diff             @@
##           develop    #3119      +/-   ##
===========================================
+ Coverage    25.59%   25.61%   +0.02%     
===========================================
  Files           53       53              
  Lines        11435    11464      +29     
===========================================
+ Hits          2927     2937      +10     
- Misses        8508     8527      +19     
Impacted Files Coverage Δ
...s/default/updatenotification/updatenotification.js 0.00% <0.00%> (ø)
modules/default/updatenotification/git_helper.js 83.33% <33.33%> (-6.25%) ⬇️
modules/default/updatenotification/node_helper.js 87.01% <40.00%> (+3.67%) ⬆️

@rejas
Copy link
Collaborator

rejas commented Jun 8, 2023

After, we (or I) can create a template for an auto-update of a module for testing (it's only for modules of developer)

Note:

* I use my own protocol for this since 3 years now (works fine ! and makes you lazy)

* Able to update properly a module and restart MM² when update done

* Catch any error ? (with alert)

* Naturally, I will not apply this rules to MM² (and default modules)

Is this what you are looking for?

sorry, dont get what you mean. is it about testing?

will merge the PR anyway even without tests, they can be done anytime later

@rejas rejas merged commit e985e99 into MagicMirrorOrg:develop Jun 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants