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!

[skynetigor]

LGTM

[korolenkowork]

Hi @talboren, @shahargl!
All tests are passed, and I received approval from @skynetigor, so it seems ready for merge!

[shahargl]

I think there is a better and simpler way to check jinja2 expressions,

e.g.:

from jinja2 import Environment, TemplateSyntaxError
 env = Environment()

# valid
In [4]: env.parse("Hello, {{ name }}!")
Out[4]: Template(body=[Output(nodes=[TemplateData(data='Hello, '), Name(name='name', ctx='load'), TemplateData(data='!')])])

# invalid
In [8]: a = """{% for item in items %}
   ...:   {{ item }}
   ...: {% endif %}"""

In [9]: env.parse(a)
-------------------------------------------------------------------
TemplateSyntaxError               Traceback (most recent call last)
Cell In[9], line 1
----> 1 env.parse(a)

File ~/git/keep/.venv/lib/python3.11/site-packages/jinja2/environment.py:616, in Environment.parse(self, source, name, filename)
    614     return self._parse(source, name, filename)
    615 except TemplateSyntaxError:
--> 616     self.handle_exception(source=source)

File ~/git/keep/.venv/lib/python3.11/site-packages/jinja2/environment.py:942, in Environment.handle_exception(self, source)
    937 """Exception handling helper.  This is used internally to either raise
    938 rewritten exceptions or return a rendered traceback for the template.
    939 """
    940 from .debug import rewrite_traceback_stack
--> 942 raise rewrite_traceback_stack(source=source)

File <unknown>:3, in template()

TemplateSyntaxError: Encountered unknown tag 'endif'. Jinja was looking for the following tags: 'endfor' or 'else'. The innermost block that needs to be closed is 'for'.

[korolenkowork]

It’s a good approach, but my goal here isn’t to check whether the Jinja2 template is syntactically valid. Instead, I want to detect if the user accidentally used Mustache syntax when they selected Jinja2 as the template engine (or vice versa), and raise an informative error.

So it's more about catching cross-engine mistakes — for example, using {{#section}}...{{/section}} inside a Jinja2 context, or {% if ... %} inside a Mustache one.

That said, I agree this logic could probably be simplified. I’ll take another look and try to clean it up.

[shahargl]

👑

[shahargl]

seems almost done, see comments.

and if you can add more tests it will be great <3 just a big change so want to make sure we are ok.

[shahargl]

@EnotShow let me know when you want the final review + merging

[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.