feat: lua script commands triggers

[Abhishek84313]

What changes are being made and why?

Adds ScriptTrigger and CommandsTrigger to plugin-script-lua, which was one of the submodules still missing them.

Part of #313, closes #428.

Both triggers live in io.kestra.plugin.scripts.lua — the same package as the Script and Commands tasks, with no nested subpackage — matching the existing implementations in plugin-script-go, plugin-script-node, plugin-script-python, plugin-script-ruby and plugin-script-shell.

ScriptTrigger polls by running an inline Lua script through the Script task and emits an execution when the condition matches.

CommandsTrigger does the same for a list of commands through the Commands task.

Each trigger exposes:

Property	Default	Description
containerImage	nickblah/lua	Image used to run the script/commands
script / commands	—	Required; same semantics as the corresponding task
exitCondition	—	Required; decides whether the trigger fires
interval	PT60S	Polling interval
edge	true	Emit only on a not-matching → matching transition

exitCondition accepts either exit N, which compares against the process exit code, or any other string, which is treated as a regex (falling back to a substring match if the regex is invalid) against vars emitted via the ::{"outputs":{...}}:: convention.

The trigger output carries timestamp, condition, exitCode and vars; execution id, namespace and flow id come from the standard TriggerService.generateExecution context. A failed evaluation is logged and returns empty rather than propagating, so a broken script cannot block the scheduler.

plugin-script-lua/build.gradle gains the scheduler and worker test dependencies that the trigger tests require, matching the other submodules.

Note on the issue's proposed properties

The issue sketches commandPattern and argumentsPattern alongside exitCondition. This PR implements only exitCondition, consistent with all five existing reference implementations. These triggers run the script themselves rather than observing externally-launched executions, so there is no command stream to pattern-match against — the command is whatever the trigger was configured with. Adding the two pattern properties to Lua alone would diverge from every other submodule; if they are wanted, they belong in a separate change applied across all of them.

---

How the changes have been QAed?

Unit and condition-matching tests were added for both triggers (ScriptTriggerTest, CommandsTriggerTest, ScriptTriggerConditionTest, CommandsTriggerConditionTest), covering exit-code conditions, regex and substring matching against emitted vars, empty/null conditions, and edge-mode transition behaviour.

The 36 tests that do not require Docker pass locally, and compileJava, compileTestJava and build all succeed. The four Docker-backed cases in CommandsTriggerTest could not be run on the development machine, which has no Docker available — they need a CI run to confirm. They use lua -e "os.exit(1)" / os.exit(0) against nickblah/lua:latest, consistent with the existing CommandsTest and the all_lua.yaml sanity check that already invoke lua in that image.

Trigger on a failing script:

id: lua_script_trigger
namespace: company.team

triggers:
  - id: script_failure
    type: io.kestra.plugin.scripts.lua.ScriptTrigger
    interval: PT10S
    exitCondition: "exit 1"
    edge: true
    containerImage: nickblah/lua
    script: |
      -- This fails with a non-zero exit code.
      os.exit(1)

tasks:
  - id: log
    type: io.kestra.plugin.core.log.Log
    message: "Triggered with exitCode={{ trigger.exitCode }} (condition={{ trigger.condition }})"

Trigger on commands matching emitted output:

id: lua_commands_trigger
namespace: company.team

triggers:
  - id: commands_match
    type: io.kestra.plugin.scripts.lua.CommandsTrigger
    interval: PT10S
    exitCondition: "status=\\w+"
    edge: true
    containerImage: nickblah/lua
    commands:
      - lua -e 'print("::{\"outputs\":{\"status\":\"status=ready\"}}::")'

tasks:
  - id: log
    type: io.kestra.plugin.core.log.Log
    message: "Triggered with vars={{ trigger.vars }}"

---

Contributor Checklist ✅

• I have read and followed the plugin contribution guidelines

[Malaydewangan09]

This PR doesn't contain any Lua.

The branch is feat/lua-script-commands-triggers and the description walks through the Lua triggers, the properties table, and 36 passing tests, but the diff is:

AGENTS.md
plugin-script-perl/...  (7 files)
plugin-script-r/...     (7 files)

Zero files under plugin-script-lua. The two commits on the branch are feat/r-script-commands-triggers and feat/perl-script-commands-triggers. plugin-script-lua on main still has only Script.java, Commands.java and package-info.java, so the work genuinely isn't here.

Separately, this diff is byte-identical to #446 (both 1950 lines), and #438 is the R subset of both. So #438, #446 and #447 are three PRs carrying overlapping copies of the same commits rather than one module each. Merging any one of them will conflict the other two.

Could you rebase each onto current main with only its own module: #438 R, #446 Perl, and this one Lua? I'll review them properly once they're separated. Nothing here reflects on the code itself, I just can't review Lua triggers that aren't in the diff.