Add Deck-Auto-Update plugin

[AkazaRenn]

AutoUpdate/Crontab Auto-Restart

Summary

It accepts a crontab expression and will try to update the system based on that schedule. It will automatically restart either the Steam client or the OS based on the need of the update. It will only restart the client/system if the current battery level is equal to or higher than the user-set value, and the user is not in game.

This plugin is still in early stage but functions well per my tests, but if the system is sleeping, it doesn't wake up the system to do the update...

I use it to keep my Steam Link host up-to-date.

Checklist:

Developer Checklist

• [x] I am the original author or an authorized maintainer of this plugin.
• [x] I have abided by the licenses of the libraries I am utilizing, including attaching license notices where appropriate.

Plugin Checklist

• [x] I have verified that my plugin works properly on the Stable and Beta update channels of SteamOS.
• [x] I have verified my plugin is unique or alternatively provides more/alternative functionality to a similar plugin already on the store.

Plugin Backend Checklist

• No: I am using a custom backend other than Python.
• No: I am using a tool or software from a 3rd party FOSS project that does not have it's dependencies statically linked.
• No: I am using a custom binary that has all of it's dependencies statically linked.

Testing

• [x] Tested on SteamOS Stable/Beta Update Channel.

[TrainDoctor]

I'm wondering if auto-update is too simple a name. No blocking concern but something I think might be important for clarity.

[AkazaRenn]

@TrainDoctor what about deck-auto-update?

[AkazaRenn]

@RodoMa92 Lock should be using 6.0 now @TrainDoctor I renamed it to Deck-Auto-Update Thanks for your help!

[RodoMa92]

Seems to have a missing import in index from the CI output:

[!] Error: Could not resolve '../protobuf/build/steammessages_client_objects_pb' from src/index.tsx
  Error: Could not resolve '../protobuf/build/steammessages_client_objects_pb' from src/index.tsx
      at error (/plugin/node_modules/.pnpm/[email protected]/node_modules/rollup/dist/shared/rollup.js:198:30)
      at ModuleLoader.handleResolveId (/plugin/node_modules/.pnpm/[email protected]/node_modules/rollup/dist/shared/rollup.js:22463:24)
      at /plugin/node_modules/.pnpm/[email protected]/node_modules/rollup/dist/shared/rollup.js:22426:26
  Line:  ELIFECYCLE  Command failed with exit code 1.
  Line: error code: 0
  Line: pnpm build failed, please report this issue to the CI maintainer and the plugin developer.
  Error: Failed to build frontend. There might be more information in the output above.
  Caused by:
      child status was: exit status: 1

[AkazaRenn]

@RodoMa92 Ah protobuf/generate.py needs to be run before building. I modified the VS Code tasks but the PreCI doesn't use that I assume? How do we usually solve dependencies like that? It should be fixed now

[AkazaRenn]

I tried moving the dependency generation part into backend, hope it will work this time. Please try re-triggering the pipeline if you get the chance. Thank you!

[RodoMa92]

Still failing, sadly:

Line: Running command: 

Line: 	/tmp/protoc/bin/protoc --plugin=protoc-gen-ts=//plugin/node_modules/.bin/protoc-gen-ts --ts_out=service=grpc-node://plugin/protobuf/build --proto_path=//plugin/protobuf/source/steam //plugin/protobuf/source/steam/*.proto 

File "//./plugin/protobuf/generate.py", line 68, in <module> 

main() 

File "//./plugin/protobuf/generate.py", line 48, in main 

run(protoc_command, shell=True, check=True, env=env, stderr=DEVNULL) 

File "/usr/local/lib/python3.12/subprocess.py", line 571, in run 

raise CalledProcessError(retcode, process.args, 

subprocess.CalledProcessError: Command '/tmp/protoc/bin/protoc --plugin=protoc-gen-ts=//plugin/node_modules/.bin/protoc-gen-ts --ts_out=service=grpc-node://plugin/protobuf/build --proto_path=//plugin/protobuf/source/steam //plugin/protobuf/source/steam/*.proto' returned non-zero exit status 1.

[AkazaRenn]

@RodoMa92 sorry for being silly 🥲 I've tested this change on my fork and it should really pass this time

[TrainDoctor]

@AkazaRenn just as a heads up, plugins without testing reports submitted have until the end of this month to collect testing reports so the plugin can be approved to go to the production store or it will be removed from testing and the PR closed. A new PR or re-opening the PR can be submitted at any time at your convenience and the plugin is not blacklisted if you can ensure you have a tester to evaluate the plugin within 2 weeks of re-opening the PR. Thanks for your patience and understanding.

[AkazaRenn]

@TrainDoctor got it!

[TrainDoctor]

Closing as untested. If you are able to locate a tester in future we will happily accept a re-submission.

[TrainDoctor]

@AkazaRenn, if you are able to update this PR with a version of your plugin (please also make sure to bump your version by at least a patch to ensure no conflicts will occur in CI/CD etc) that you have verified with the latest stable versions of Loader then I can re-open this PR. (Please note the below text only applies if you are able to make the requested update, thanks for your understanding). The more plugins that can come back the higher chance you are able to see a tester for your plugin is my hope.

I am currently experimenting with a concept for testing plugin submissions and plugin updates. I would request that you submit testing reports for at least 2 other plugin submissions/updates (preferably the oldest PRs still active). Then if no other plugin author (as I will be encouraging all others to do the same) or tester submits a testing report I will request that a member of the SDH team tests your plugin update/submission according to the testing guidelines.