[droyad]

Adds LessThan, LessThanOrEqual, GreaterThan and GreaterThanOrEqual filters, so a numeric comparison can be used anywhere a variable expression can be — including as a run condition on its own.

#{Octopus.Action[Get Days Until Expiration].Output.DaysUntilExpiration | LessThan 31}

That replaces the workaround in the issue, which was to #{calc {X} - 31} into a variable and then test it with | StartsWith "-".

Why filters rather than new syntax

The issue proposed three syntaxes with no stated preference: bare #{X < 31}, a | LessThan 31 filter, or #{calc {X} < 31}. The filter form wins on more than just cost:

#{if <expression>} already accepts a full filter chain, so a single filter covers run conditions, conditionals and #{elseif} chains at once:

#{if DaysUntilExpiration | LessThan 31}Expiring soon#{/if}
#{if Count | LessThan 10}low#{elseif Count | LessThan 100}medium#{else}high#{/if}

It also means no grammar change at all — TemplateParser.cs is untouched, so there is no way for this to alter how any existing template containing < or > is parsed. Given that Octostache parses every variable in every Octopus deployment, that seemed worth a lot. It composes with other filters (#{Total | Trim | GreaterThan 100}) for free, and leaves the door open to adding the bare #{X < 31} form later as sugar over the same logic.

#{calc {X} < 31} was rejected on design grounds: calc's entire type model is double?, and a comparison yields a boolean.

Semantics

Each decision follows an existing precedent in the codebase:

Case	Result	Precedent
Both sides numeric	"true" / "false"	StartsWith, EndsWith, Contains, Match
Either side non-numeric	null → token left unevaluated, recorded as missing, not truthy	CalculationVariable.Evaluate
Not exactly one argument	null	StartsWith with 0 or 2+ options

Returning "true"/"false" keeps these consistent with the existing text-comparison filters and with IsTruthy, so they behave correctly as run conditions.

Number parsing is invariant-culture. double.TryParse(value, NumberStyles.Float, CultureInfo.InvariantCulture) — a template gives the same answer regardless of the culture of the machine evaluating it, rather than a run condition that can flip depending on which worker picks it up. NumberStyles.Float deliberately excludes thousands separators, so an ambiguous "1,000" is treated as non-numeric instead of being silently read as 1.

Note this is deliberately not consistent with #{calc}, which parses and formats using the current culture in four places. Nothing in the Octostache readme or the public docs specifies a number format for calc, so there was no documented contract to match, and I did not want to propagate machine-dependent behaviour into something new. calc is left alone in this PR.

NaN and Infinity parse and then follow ordinary double comparison semantics (so NaN | LessThan 31 and NaN | GreaterThanOrEqual 31 are both false). Pinned by a test rather than left to chance.

Out of scope

• AND/OR operators, requested in a comment on the issue. Not blocked by this — they would be additive, as either filters or grammar.
• The bare #{X < 31} and #{calc {X} < 31} forms.
• calc's culture handling.

Testing

TDD: tests written first and watched fail, then the implementation. Full suite is green on both target frameworks — 696 passed, 0 failed on net10.0 and net48 — which is the backwards-compatibility safety net for a library this widely exercised.

Coverage includes each operator's boundary behaviour (5 | LessThan 5 false vs 5 | LessThanOrEqual 5 true), numeric-not-lexicographic ordering (9 | LessThan 10), negatives, decimals, exponents, surrounding whitespace, non-numeric on either side, wrong arity, variable options, filter chaining, case-insensitive filter names, and the invariant-culture decision pinned via "1,5" and "1,000". Integration tests cover the issue's run condition verbatim (indexed output variable and all), a missing/misspelled variable evaluating to false rather than silently passing, and comparisons inside #{if} and #{elseif} chains.

Docs

README.md gains a short "Comparison filters" section. The public docs at octopus.com/docs/projects/variables/variable-filters will need a matching entry under Comparison filters — separate repo, not done here.

Resolves #114

🤖 Generated with Claude Code

[benPearce1]

This looks good, but needs some extra thought might be the error states

[benPearce1]

This should probably return a formatted error

[benPearce1]

This feels like it should just return false, or an error