Add selective preloading of Bash script modules

[kube89]

This PR introduces an opt-in way to preload Bash script modules before the user’s Bash script runs.

New variable: Octopus.Action.Script.PreloadScriptModules

If that variable is set, Calamari will source specific script modules in the bootstrapper first.
Then it sources the actual user script as usual.

Usage

Set the project variable and scope it to a process. Can scope to specific steps for different requirements, and maintain an entry not scoped at step-level if you want to define a default across the process.

Test scenario

Modules defined:

Project variables:

Deployment process with 2 steps (both running same inline script):

Logs (verbose) Step 1:

Logs (verbose) Step 2:

[zentron]

Thanks @kube89.
Im interested to know what problem this is solving that using the existing script modules doesn't provide?

[kube89]

Thanks @kube89. Im interested to know what problem this is solving that using the existing script modules doesn't provide?

Thanks @zentron.

This introduces a "pre-script lifecycle phase" that existing script modules don't provide, as they only execute when explicitly sourced from within the user script body.

Script modules already solve reusability well; this PR aims to leverage what's already there. By allowing selected script modules to be sourced before the user script runs, we can remove a significant amount of repeated boilerplate from step scripts and allow more control over the deployment context from outside individual steps.

Currently, orgs can define reusable helper functions in script modules and make them available to projects onboarded to an Octopus instance. However, each step script must still explicitly source those modules, which introduces duplication, misconfiguration (e.g. forgetting to add or update it in one script). Automatically sourcing selected modules would facilitate a predictable baseline environment across projects and align with a broader effort to introduce standardisation, guardrails, and organisational conventions (complementing features provided in Platform Hub).

Example: if we have a deployment process with ~20 steps, where most scripts require the same configuration-related environment variables derived from Octopus project variables and access to shared helper functions...
Current state: each script must manually source the required modules (usually the same ones for each step), resulting in repeated boilerplate and multiple places that need to be updated when conventions change.
Proposed state: script modules are automatically sourced by Calamari based on a centralised project-level configuration (provided the deployment process has access to the module), before the script body executes.

Project maintainer perspective: control over which modules run and where, can be managed centrally, scoped to various granularity (e.g. down to individual deployment steps). Changing or updating a shared module by name no longer requires editing multiple scripts; it can be done in one place via configuration.

Developer perspective: this means the deployment context is already wired with the organisation’s standard functions and environment setup, allowing scripts to focus on deployment logic rather than setup code. Project-specific helper functions are sourced for all steps out of the box.

So one of my goals is to facilitate maintainers to provide org standards, reduce duplication, reduce misconfiguration, which should support scaling Octopus usage up to many teams/projects with minimal friction.

Even if this type of functionality could be better suited to Platform Hub when looking at it from the angle of providing org-wide standards and centralisation, there's still alot of a benefit of configuring it at the project level for those project-specific helper modules that are repeatable inside the project but useless outside of that context.

Doesn't have to be Octopus.Action.Script.PreloadScriptModules specifically, but it seemed to characterise the behaviour well and seemed inline with Octopus conventions.

Thoughts on all the above?