Add option to test notification

[stepdg]

Since notify.sh is dependent on values passed along by the main script you cannot set up notify.sh and run it alone to test notification will work. I set it up a few days ago and sure enough I haven't had any image updates. I suppose I could force a lower version then switch to :latest but I still think this would be a nice option. -o or some other switch.

Disclaimer: Developer knows I am a dummy dumb so this may be way off the rails.

[mag37]

I've been thinking of this too, I think it's reasonable (even if you're nuts 😅).

Though my thoughts was to just make a minor test script that calls the notification with dummy data.

And sometimes when I just want to see output I modify the line at 405, adding a ! (not equal):

## from
    if [[ "$LocalHash" = *"$RegHash"* ]]; then
## to
    if [[ "$LocalHash" != *"$RegHash"* ]]; then

That flips the logic partly and show the ones with no updates as they've got updates.

[stepdg]

Solid idea!

[mag37]

This is a rough one, but does the trick:

templateTester.sh

#!/usr/bin/env bash

PrintReleaseURL=true
PrintMarkdownUrl=false
GotUpdates=( "dummy-one" "caddy" "dozzle" "homer" "mqtt" )
UrlsList="urls.list"

ScriptArgs=( "$@" )
ScriptPath="$(readlink -f "$0")"
ScriptWorkDir="$(dirname "$ScriptPath")"
NotifyTemplate=${ScriptArgs[0]:="notify.sh"}
Notify=true

printHelp() {
  printf "Use with specifying filename of notification template (need to be in same directory)\n"
  printf "Example: ./templateTester.sh notify_test1.sh\n"
  printf "Optionally also have urls.list in the same directory for testing.\n"
  exit 1
}

releasenotes() {
  unset Updates
  for update in "${GotUpdates[@]}"; do
    found=false
    while read -r container url; do
      if [[ "$update" == "$container" ]] && [[ "$PrintMarkdownURL" == true ]]; then Updates+=("- [$update]($url)"); found=true;
      elif [[ "$update" == "$container" ]]; then Updates+=("$update  ->  $url"); found=true;
      fi
    done < "${ScriptWorkDir}/${UrlsList}"
    if [[ "$found" == false ]] && [[ "$PrintMarkdownURL" == true ]]; then Updates+=("- $update  ->  url missing");
    elif [[ "$found" == false ]]; then Updates+=("$update  ->  url missing");
    else continue;
    fi
  done
}

[[ "${ScriptArgs[0]}" == "-h" ]] && printHelp

if [[ -s "${ScriptWorkDir}/${NotifyTemplate}" ]]; then
  source "${ScriptWorkDir}/${NotifyTemplate}"
else printHelp
fi

if [[ -n ${GotUpdates[*]:-} ]]; then
  printf "\n--- Dummy containers ---\n"
  if [[ -s "${ScriptWorkDir}/${UrlsList}" ]] && [[ "$PrintReleaseURL" == true ]]; then releasenotes; else Updates=("${GotUpdates[@]}"); fi
  printf "%s\n" "${Updates[@]}"
  [[ "$Notify" == true ]] && { type -t send_notification &>/dev/null && send_notification "${GotUpdates[@]}" || printf "\nCould not source notification function.\n"; }
fi

[mag37]

Though there might be some upcoming changes to notifications (see https://github.com/mag37/dockcheck/discussions/156) so I will hold on adding this to main for a bit.

[vorezal]

I apparently unintentionally threw a bit of a wrench in this. But while I was working on notify_v2 I was running a lot of tests and added some logic temporarily that skipped all of the container checks. Maybe we could use that in combination with populating dummy containers and notify_v2 to create a flag that does this though? There are a lot of flags already, but we could treat it like a dry-run/dry-run with dummy images. Perhaps -b/-B for bench-test/bench-test with dummy images and update notifications? They could also be used together with -u to perform a kind of self-update only execution.

Does any of that sound useful or am I just complicating things unnecessarily to solve problems that don't exist? Alternatively I think all we would have to do is switch the NotifyTemplate variable to pull notify_v2.sh, either by default or as a fallback, to get this to work with the new notification feature mostly as-is.

[mag37]

Haha well, no problem. I think due to the wrapper it would be easier/cleaner to implement it now anyway.

A dry-run kind of functionality sounds very reasonable. Maybe it doesn't need dummy containers but just use all local containers from something like

docker ps --format '{{.Names}}'

But force-skip any container checks and update logic.

[yoyoma2]

I like the dry-run concept like tailscale --dry-run. Go through the motions exactly but don't actually update anything when it comes to that step.

You know how -e can prevent updating specific containers that need it. How about an opposite option to fake specific container(s) as having a need to update. Useful for testing with dry-run when no updates are pending.

[Radoom]

Just wanted to drop a line: Thanks for the script, very helpful. And +1 for a "dryrun-and-notify" (or even a "test-notify-only") option - though the tweak with == => != was good enough for now.

Small update for other total noobs like me potentially getting confused: The line number in dockcheck.sh as of 28-10-2025 is more like 439; and the original comparator is == and not =:

## from
    if [[ "$LocalHash" == *"$RegHash"* ]]; then
## to
    if [[ "$LocalHash" != *"$RegHash"* ]]; then

[yoyoma2]

How about a -N "enhanced no updates" option that additionally sends update notifications unconditionally. Tried this and it works on DSM.

fakenotify.txt

The wording and option vs config file is arguably not ideal.

[mag37]

Thank you for the input @Radoom - and clarification!

@yoyoma2 - your suggestion looks sound, I'll need to think about the phrasing some but the -N option flag feels good. Maybe it can be phrased around notify debugging / forcing? "forced notification" instead of faked?

And also a help message / config comment clearly stating it'll force notification and skip all updates and interaction.

[yoyoma2]

Agreed, the word "faked" doesn't sound professional. Do you want me to take a shot at writing a message / config comment? Might not come out too clear/understandable. No rush on this issue, it's been around since May...

[mag37]

You're welcome to give it a go if you'd like, otherwise I'll keep it in my list and get to it asap :) it's just been another lingering "to-do", so its no stress while it'd be a nice to have.

[Radoom]

Just my 2 Cents:

" -N : send a test Notification message only, but do nothing else (i.e.: any other actionable options provided at the same call will be ignored)"

Would be sufficiently clear for me I guess.

The test message could be as simple as : "Test Notification triggered by 'dockcheck.sh -N' on {hostname} sent at {DD-MM-YYYY Hh:mm:ss}" .

Or thelike....

Edit: can't code, so no point in trying to provide this proposal as a pull request, sorry.

[mag37]

Thanks @Radoom , good input.

Discussion, feedback and critique is just as valuable as code contribution!

I'll think some more on this before I do any implementations, happy for any discussion.

Also not sure I'll tweak the actual notification message - need to think about that and do some testing.

[yoyoma2]

Also not sure I'll tweak the actual notification message - need to think about that and do some testing.

I was considering tweaking the actual notification message when doing the prototype. On one hand you don't want someone to be fooled into thinking a test notification is real. On the other hand you want the test notification to use mostly the same code path as a genuine notification. I chose the latter and just gave a shell warning mostly because lazy me usually opts for less code changes so not a clear cut decision.