Update IMMICH_BASE to accept optional storage location

[80avin]

Make IMMICH_BASE variable assignment optional with an argument.

Description

Usecase: Since immich can take huge storage, I want to keep it on a separate hard drive while I boot from a small SSD.
With this option, I can setup immich to store data in a custom location.

Issue reference:
fixes #729

Related documentation:
Add optional 2nd argument to module_immich, which sets the base storage location of immich.

Implementation Details

Provide a detailed description of the implementation. Include the following:

• Key changes introduced by this PR
• Justification for the changes
• Confirmation that no new external dependencies or modules have been introduced

Documentation Summary

• Metadata Included:
  Did you include the metadata (associative arrays) in the code? Ensure that metadata for modules, jobs, and runtime has been updated appropriately.

• Document Generated:
  Did you generate the updated documentation using armbian-configng --doc? Confirm if the command was run to update README.md and provide any relevant details.

Testing Procedure

Describe the tests you ran to verify your changes. Provide relevant details about your test configuration.

• Test 1: Description and results
• Test 2: Description and results

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have ensured that my changes do not introduce new warnings or errors
• No new external dependencies are included
• Changes have been tested and verified
• I have included necessary metadata in the code, including associative arrays

[coderabbitai]

Walkthrough

The pull request modifies the module_immich function in the Immich module script to support an optional second positional argument that allows overriding the Immich storage base directory. The IMMICH_BASE variable now initializes to a default value of "${SOFTWARE_FOLDER}/immich" but accepts an override from the second argument if provided. No changes are made to the function's core logic, control flow, or public interface.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: adding support for an optional argument to override the IMMICH_BASE storage location.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Description check	✅ Passed	The pull request description clearly relates to the changeset, explaining the use case for allowing custom storage locations for Immich data and referencing the related issue.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

tools/modules/software/module_immich.sh (2)

140-142: Purge may target wrong directory if custom path isn't re-provided.

If a user installed with a custom IMMICH_BASE (e.g., /mnt/storage/immich) but runs purge without the second argument, the command will attempt to delete the default path ${SOFTWARE_FOLDER}/immich instead—leaving the actual data behind or failing silently.

Suggested approach: persist and retrieve IMMICH_BASE

 		"${commands[0]}")
 			shift
+
+			# Persist the configured IMMICH_BASE for future operations
+			echo "IMMICH_BASE=\"${IMMICH_BASE}\"" > "${SOFTWARE_FOLDER}/.immich_config"
 
 			if ! pkg_installed docker-ce; then

Then at the top, before the case statement:

-	IMMICH_BASE="${2:-"${SOFTWARE_FOLDER}/immich"}" # optional argument = immich storage location
+	# Load persisted config if exists, otherwise use default or provided argument
+	if [[ -f "${SOFTWARE_FOLDER}/.immich_config" ]] && [[ -z "$2" ]]; then
+		source "${SOFTWARE_FOLDER}/.immich_config"
+	else
+		IMMICH_BASE="${2:-"${SOFTWARE_FOLDER}/immich"}"
+	fi

---

151-159: Help text should document the optional storage location argument.

The help output doesn't mention that install accepts an optional second argument for the storage location. Users won't discover this feature without reading the source.

Proposed fix

 		"${commands[4]}")
 			echo -e "\nUsage: ${module_options["module_immich,feature"]} <command>"
 			echo -e "Commands:  ${module_options["module_immich,example"]}"
-			echo -e "\tinstall\t- Install $title."
+			echo -e "\tinstall [path]\t- Install $title. Optionally specify storage location."
 			echo -e "\tremove\t- Remove $title."
 			echo -e "\tpurge\t- Purge $title data folder."
 			echo -e "\tstatus\t- Installation status $title."
 			echo -e "\thelp\t- Show this help message."
 			echo
 		;;

🧹 Nitpick comments (1)

tools/modules/software/module_immich.sh (1)

36-36: Parameter expansion is correct, but the custom path isn't persisted.

The bash syntax ${2:-"${SOFTWARE_FOLDER}/immich"} correctly defaults when $2 is unset. However, the custom IMMICH_BASE value is not persisted to a config file, so subsequent operations (especially purge) require the user to remember and re-provide the same path.

Consider storing the configured path (e.g., in "${SOFTWARE_FOLDER}/immich.conf" or similar) during install and reading it back for remove/purge/status operations to ensure consistency.

[igorpecovnik]

I think this would be useful to setup globally - not just for Immich, but for all. What do you think?

[80avin]

I think this would be useful to set up globally - not just for Immich, but for all. What do you think?

You mean, move SOFTWARE_FOLDER to a different location ?
Sure, it can be useful. The only challenge is the design of it.

[igorpecovnik]

You mean

No. Software folder variable is common to all software titles and thus its overriding should be global.

[80avin]

@igorpecovnik, I am not sure if I understood you.
Making a configuration global brings two questions:

• Where should it be configured in?
  Like /etc/armbian-config/... or something else.
• What if the user wants different storage locations for different software?
  For example, I suspect it will be a common scenario to dedicate one drive/partition for one purpose and another for a different purpose.