PP/Scan/Queue/Schedule Script Testing

Discuss newly added features or request new features.
Post Reply
l2g
Posts: 228
Joined: 27 Jun 2014, 22:13
Contact:

PP/Scan/Queue/Schedule Script Testing

Post by l2g » 06 Aug 2015, 17:37

A common gripe with NZBGet would be trying out that new script they saw on here (in the forum) and getting it to work... well only to have it not. Debugging someone else's script can be tedious and annoying. So much so that I could see people just giving up and moving on. It's sad because this tool really is absolutely amazing!

Anyway, I guess what I'm getting to is:
It would be great if we could execute each script we have setup with NZBGet in a Test Mode (5th type) that would basically just takes advantage of piping it's output to the NZBGet logs giving us some idea of whether it's going to work as we expect it to in advance. Some sort of button that becomes available in the NZBGet configuration when previewing a scripts configuration... Perhaps of the colour red and containing the keyword 'Test'.

Each Script maintainer would have to add support for this (so it would be just an optional thing)... When the new Test button was pressed it would execute the script the same way it might have otherwise done so using the other modes (Scan/Post Process/Queue/Schedule) (but as the new Test? mode). You could easily prevent breaking existing scripts by just setting a new Environment Variable when called (this would be how you distinguish that your being ran in a test mode or not). Hence, set the internal variables (passed from the configuration) to something like NZBTEST_VAR (or whatever).

Script maintainers who choose to listen and execute upon these can read in the configuration the user specified and do a test (or series of tests) pertaining to whatever the script function is and report back to the the user through the NZBGet logs. Let the user know that everything looks good... or report to them an error or something they should consider.

You could make it even more backwards compatible by only put the new 'Test' button next to scripts that create some directive they define in their configuration... Something like:

Code: Select all

### TESTABLE ###
I can see lots of use cases for this...For example notification type scripts (such as email,etc); this might even entail sending that type of notification (to test that you got it setup right - a test message). The best part about this is when there is an error... that can be used to post back into the forum for help with solving their problem.

Other scripts that preform other tasks might do something as simple as test that the remote authentication is right. ClintonHall might test the APIs specified to the remote CouchPotato, Sonarr servers, etc. But it would just give the user that warm fuzzy feeling that the new script they've added is set up correctly. It also gives developers a better troubleshooting understanding or starting point.

I know for my TidyIt script; i would just ahead and run it in Disabled mode allowing them to see what it 'would' do if ran fully enabled. Stuff like that...

Thoughts?

Edit: Hugbug; i took out reference to the installation of NZBGet since it's not pertaining to the feature I'm proposing anyway.
Last edited by l2g on 06 Aug 2015, 17:56, edited 1 time in total.

hugbug
Developer & Admin
Posts: 7645
Joined: 09 Sep 2008, 11:58
Location: Germany

Re: PP/Scan/Queue/Schedule Script Testing

Post by hugbug » 06 Aug 2015, 17:49

See issue on tracker - Execute extension scripts from settings page #50.
l2g wrote:I think the biggest gripe people have with NZBGet is how hard it is to set up the very first time.
Can't agree with that. Installing on Windows and OS X is extremely easy (using installers)
Thanks to new Linux installer the installing on most Linux systems is easier than of most other tools.

The only required step after installing is to put news server settings.

l2g
Posts: 228
Joined: 27 Jun 2014, 22:13
Contact:

Re: PP/Scan/Queue/Schedule Script Testing

Post by l2g » 06 Aug 2015, 18:00

Thanks HugBug, i updated my main post to take that line out since you have this installer of yours now. I do find that most installation issues are people who have custom NAS devices that have the python libraries in different locations and file permissions all skewed. But anyway... the installation of NZBGet really wasn't pertaining to my request anyway.

Back on topic:
I didn't realize there was already a enhancement open for this! I'm totally in agreement with it. You can lock this thread up if you want! :)
hugbug wrote:See issue on tracker - Execute extension scripts from settings page #50.
l2g wrote:I think the biggest gripe people have with NZBGet is how hard it is to set up the very first time.
Can't agree with that. Installing on Windows and OS X is extremely easy (using installers)
Thanks to new Linux installer the installing on most Linux systems is easier than of most other tools.

hugbug
Developer & Admin
Posts: 7645
Joined: 09 Sep 2008, 11:58
Location: Germany

Re: PP/Scan/Queue/Schedule Script Testing

Post by hugbug » 06 Aug 2015, 18:35

Nonetheless if you have suggestions how to improve installation experience - please speak :)

l2g
Posts: 228
Joined: 27 Jun 2014, 22:13
Contact:

Re: PP/Scan/Queue/Schedule Script Testing

Post by l2g » 06 Aug 2015, 18:53

hugbug wrote:Nonetheless if you have suggestions how to improve installation experience - please speak :)
I honestly don't have any installation experiences to add at all. I use CentOS/Fedora/Red Hat based systems and have already packaged your product along with all my favourite NZB Scripts (they're packaged individually though) in self installing RPMs that do all the magic and configuration for me. Linux is a tough flavour to accommodate because everyone uses different distributions. I'm impressed alone that you've even got an installer; i need to follow the forums more closely i guess. :). Good on you.

I freely share these RPMs and you're more then welcome to link to it for others if you want:
CentOS 6.x: RPM / Source RPM
CentOS 7.x: RPM / Source RPM

I wrote a blog about it in the past where all the scripts and stuff are all in one location but i won't bore you with that info :)

kloaknet
Posts: 337
Joined: 23 Jul 2014, 08:52

Re: PP/Scan/Queue/Schedule Script Testing

Post by kloaknet » 07 Aug 2015, 17:03

I think its great to run a script via the settings page to test it, must make it way easier to test and debug scripts !

hugbug
Developer & Admin
Posts: 7645
Joined: 09 Sep 2008, 11:58
Location: Germany

Re: PP/Scan/Queue/Schedule Script Testing

Post by hugbug » 07 Aug 2015, 18:25

Not many scripts can be tested this way; the script runs in a different context and doesn't have access to downloaded files, etc.

Post Reply

Who is online

Users browsing this forum: No registered users and 23 guests