feat: Jinja2 template engine in workflow templates

[korolenkowork]

Closes #4594

📑 Description

This PR added the whole power of Jinja2 templating to the KeepHQ workflow

✅ Checks

• My pull request adheres to the code style of this project
• I have updated the documentation as required
• All the tests have passed

✨ Features

• Users can now choose their preferred template engine for workflows: Jinja2 or Mustache
• Mustache remains the default template engine
• Introduced a syntax validator that raises a RenderError if invalid syntax is used for the selected engine
• If an incorrect templating engine is specified in the YAML, a ValueError is raised

🛠 Improvements

• Mustache (via Chevrone) now uses a tracking dictionary to log missing keys in the context, implemented in a thread-safe way.

⚠️ Known Limitations

• During Jinja2 rendering, only missing top-level keys can be detected — full key paths cannot be tracked.
  Example: {{ alert.namespase }} will report {{ namespace }} as missing, but due to how Jinja2's Undefined class works, it cannot identify the full path to the missing value.

• It’s not possible to use a tracking dictionary for Jinja2 in the same way as Mustache, because Jinja2 internally converts the context to a plain dict during rendering.

[vercel]

@EnotShow is attempting to deploy a commit to the KeepHQ Team on Vercel.

A member of the Team first needs to authorize it.

[shahargl]

@EnotShow lot of unit tests are failing, can you fix that? :)

[shahargl]

tests failing

[talboren]

Also a quick question about backwards compatibility - not sure if I understand if this will still support mustache or we're replacing to Jinja completely? Maybe we should support templating=mustahce or templating=jinja in the top of the workflow to decide which engine we want to use. Will the keep. functions work?

[korolenkowork]

@talboren

1. This PR fully replaces Chevron with Jinja2 in workflows. I’ve proposed sticking with it, since once this is done, the previous workflows need to remain fully compatible. But it makes sense to proceed cautiously, especially since we don’t yet know all the potential issues this might introduce. So if the team decides it has to be done, I’m happy to go ahead with it.

2. Yes, keep functions working perfectly!

[korolenkowork]

@talboren This is ready for review, but I ran into an issue with Jinja2.

Jinja2 doesn't allow hyphens in identifier names when accessed as attributes in templates. To work around this, I implemented a function which replaces code like:

Pod status report:
{% for pod in steps.get-pods.results %}
Pod name: {{ pod.metadata.name }} || Namespace: {{ pod.metadata.namespace }} || Status: {{ pod.status.phase }}
{% endfor %}

with:

Pod status report:
{% for pod in steps['get-pods'].results %}
Pod name: {{ pod.metadata.name }} || Namespace: {{ pod.metadata.namespace }} || Status: {{ pod.status.phase }}
{% endfor %}

This change uses dictionary-style access, which is valid in Jinja2 for keys that contain hyphens. It seems to work, but I not sure if this solution is proper enough. What you think?

[talboren]

@talboren This is ready for review, but I ran into an issue with Jinja2.

Jinja2 doesn't allow hyphens in identifier names when accessed as attributes in templates. To work around this, I implemented a function which replaces code like:

Pod status report:
{% for pod in steps.get-pods.results %}
Pod name: {{ pod.metadata.name }} || Namespace: {{ pod.metadata.namespace }} || Status: {{ pod.status.phase }}
{% endfor %}

with:

Pod status report:
{% for pod in steps['get-pods'].results %}
Pod name: {{ pod.metadata.name }} || Namespace: {{ pod.metadata.namespace }} || Status: {{ pod.status.phase }}
{% endfor %}

This change uses dictionary-style access, which is valid in Jinja2 for keys that contain hyphens. It seems to work, but I not sure if this solution is proper enough. What you think?

makes absolute sense! I'll try to review it ASAP.

[cursor]

🚨 BugBot couldn't run

Pull requests from forked repositories are not yet supported (requestId: serverGenReqId_06c76e83-cbf9-46fb-b4f7-80acc0b782b5).

[korolenkowork]

@shahargl @talboren any updates on this?

[shahargl]

@korolenkowork see comment on the other PR. This is crazy great but I need to see how I prioritize reviewing it.

[cursor]

Bug: Mustache Template Validation Incorrectly Disables Safe Rendering

The MustacheIOHandler._validate_template method unconditionally sets safe=False and logs a debug message about inverted sections. This changes the intended behavior, as the original logic only disabled safe rendering when inverted sections ({{^ or {{ ^) were actually present in the template. Consequently, safe rendering is now always disabled for Mustache templates.

keep/iohandler/iohandler.py#L695-L702

keep/keep/iohandler/iohandler.py

Lines 695 to 702 in 58f0d0a

	def _validate_template(self, template, safe):
	self.logger.debug(
	"Safe render is not supported when there are inverted sections."
	)
	safe = False
	return super()._validate_template(template, safe)

Fix in Cursor • Fix in Web

---

Bug: IO Handler Initialization Typo

The attribute self.io_nandler is a typo and should be self.io_handler. This typo occurs when initializing the IO handler within the Workflow class, leading to the correct self.io_handler attribute never being set. Consequently, any attempt to access self.io_handler later in the workflow will result in an AttributeError.

keep/workflowmanager/workflow.py#L64-L76

keep/keep/workflowmanager/workflow.py

Lines 64 to 76 in 58f0d0a

	self.context_manager.set_consts_context(workflow_consts)
	self.context_manager.set_secret_context()
	self.logger = logging.getLogger(__name__)
	self.workflow_debug = workflow_debug
	self.workflow_permissions = workflow_permissions
	match workflow_templating:
	case TemplateEngine.MUSTACHE:
	self.io_nandler = MustacheIOHandler(context_manager)
	case TemplateEngine.JINJA2:
	self.io_nandler = Jinja2IOHandler(context_manager)
	case _:
	self.io_nandler = MustacheIOHandler(context_manager)

Fix in Cursor • Fix in Web

---

Was this report helpful? Give feedback by reacting with 👍 or 👎

[korolenkowork]

Hey, @shahargl does it means that changes permanently declined?