feat(provisioner): integrate custom templates into dependency resolver (#565)

[ArangoGutierrez]

Summary

• Integrate custom templates into the DependencyResolver with five execution phases: pre-install, post-runtime, post-toolkit, post-kubernetes, post-install
• Support inline, file, and URL script sources with SHA256 checksum verification
• Add custom template validation to Dryrun() (phase validation, source presence check)
• Add comprehensive test coverage (dependency resolver, dryrun, YAML integration)
• Add user documentation at docs/guides/custom-templates.md

Closes #565 (partial - resolver/dryrun/docs portion)

Test plan

• TestDependencyResolver_CustomTemplates - 10 Ginkgo specs covering all phases, file/inline sources, env vars, continueOnError, checksum
• TestDryrun_CustomTemplates - 6 tests covering valid, invalid phase, no source, multiple, URL, file
• Custom Templates Integration - 2 Ginkgo specs for YAML parsing and dependency order
• All 81 existing provisioner tests continue to pass
• go vet ./pkg/provisioner/... clean

[coveralls]

Pull Request Test Coverage Report for Build 22715272967

Details

• 50 of 56 (89.29%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.4%) to 49.842%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/provisioner/dependency.go	32	34	94.12%
pkg/provisioner/dryrun.go	18	22	81.82%

Totals
Change from base Build 22714317868:	0.4%
Covered Lines:	2847
Relevant Lines:	5712

---

💛 - Coveralls

[Copilot]

Pull request overview

This PR adds first-class support for user-provided “custom templates” (scripts) to Holodeck’s provisioning flow by integrating them into the provisioner dependency resolver with phase-based insertion, plus dry-run validation/logging, tests, and end-user documentation.

Changes:

• Extend DependencyResolver to insert custom templates across five provisioning phases.
• Add custom template validation and dry-run logging for custom template sources/phases.
• Add fixtures, integration/unit tests, and a user guide for configuring custom templates.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
pkg/provisioner/dependency.go	Adds phase-based custom template insertion and baseDir support for file sources.
pkg/provisioner/dryrun.go	Adds custom template validation and dry-run logging of template sources/phases.
pkg/provisioner/dependency_custom_test.go	Adds Ginkgo coverage for resolver ordering and custom template behaviors (env, continueOnError, file).
pkg/provisioner/dryrun_custom_test.go	Adds unit tests for dry-run validation scenarios (phase/source/url/file).
pkg/provisioner/custom_integration_test.go	Adds YAML parsing + dependency-order integration tests using a fixture environment.
tests/data/test_custom_templates.yaml	Adds a YAML fixture exercising multiple phases and options.
docs/guides/custom-templates.md	Adds end-user documentation for configuration, phases, and security considerations.

---

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

This guide says "HTTPS is strongly recommended" for URL sources, but the Security Considerations section (and ValidateTemplateInputs) indicate HTTPS is required and non-HTTPS URLs are rejected. Please make these statements consistent (either require HTTPS everywhere or document the actual behavior).

Suggested change

	HTTPS is strongly recommended for URL sources.
	HTTPS is required for URL sources; non-HTTPS URLs are rejected during validation.

[Copilot]

Adding pre-install custom templates before other dependencies can break the existing microk8s path: withKubernetes(microk8s) resets d.Dependencies to nil, which will drop any pre-install (and post-runtime/post-toolkit) custom templates appended earlier in Resolve(). Consider preserving already-added custom template funcs when switching to microk8s, or handling microk8s in Resolve() before adding phase templates so pre-install scripts still run.

[Copilot]

Dryrun only calls templates.ValidateTemplateInputs(env) when custom templates are present. Since ValidateTemplateInputs validates many non-custom fields (versions, git refs, key paths, etc.), this makes dryrun validation behavior depend on whether customTemplates is set (invalid inputs may slip through otherwise, or unrelated fields may start failing when a single custom template is added). Consider calling ValidateTemplateInputs unconditionally, or splitting out an exported custom-template-only validator and calling that here.

Suggested change

	// Validate custom templates
	if len(env.Spec.CustomTemplates) > 0 {
	if err := templates.ValidateTemplateInputs(env); err != nil {
	cancel(logger.ErrLoadingFailed)
	return err
	}
	// Validate template inputs (includes both custom and non-custom fields)
	if err := templates.ValidateTemplateInputs(env); err != nil {
	cancel(logger.ErrLoadingFailed)
	return err
	}
	// Log custom templates if present
	if len(env.Spec.CustomTemplates) > 0 {

[Copilot]

The non-HTTPS URL warning here is effectively unreachable because ValidateTemplateInputs rejects any custom template URL that doesn't start with "https://". Either remove this branch to avoid dead code, or relax validation if the intent is to allow non-HTTPS URLs with a warning during dryrun.

[Copilot]

DependencyResolver supports baseDir for resolving relative custom template file paths, but there are no non-test call sites setting it (SetBaseDir only appears in tests). As a result, relative paths will resolve relative to the process working directory rather than the config file directory (which also contradicts the docs). Consider wiring the config file directory into the resolver (e.g., via NewDependencies(...) param or by setting it in Provisioner.Run / CLI config load path).

[Copilot]

The custom template ProvisionFunc closure ignores its "env" argument and later executeCustomTemplate uses *d.env instead. This differs from other dependencies (which operate on the env passed to the ProvisionFunc) and can produce surprising behavior if the caller executes the returned funcs with a different env value than the resolver was created with. Prefer passing the ProvisionFunc's env through to executeCustomTemplate / executor.Execute.

Suggested change

	return d.executeCustomTemplate(buf, tpl)
	})
	}
	}
	// executeCustomTemplate loads and executes a single custom template using the templates package.
	func (d *DependencyResolver) executeCustomTemplate(buf *bytes.Buffer, tpl v1alpha1.CustomTemplate) error {
	content, err := templates.LoadCustomTemplate(tpl, d.baseDir)
	if err != nil {
	return err
	}
	executor := templates.NewCustomTemplateExecutor(tpl, content)
	return executor.Execute(buf, *d.env)
	return d.executeCustomTemplate(buf, env, tpl)
	})
	}
	}
	// executeCustomTemplate loads and executes a single custom template using the templates package.
	func (d *DependencyResolver) executeCustomTemplate(buf *bytes.Buffer, env v1alpha1.Environment, tpl v1alpha1.CustomTemplate) error {
	content, err := templates.LoadCustomTemplate(tpl, d.baseDir)
	if err != nil {
	return err
	}
	executor := templates.NewCustomTemplateExecutor(tpl, content)
	return executor.Execute(buf, env)

[Copilot]

The guide documents a per-template timeout setting, but the generated custom template script/execution path does not appear to enforce this timeout (it isn't used in the executor script generation, and provisioner execution uses session.Wait() without a timeout). Either implement timeout enforcement or clarify in the docs that this field is currently not enforced.