fix(admin): validate cron expression in launch plan schedule

[peterxcli]

Tracking issue

#4953

Why are the changes needed?

Validate cron expression in launch plan schedule first, preventing "runtime error" when LPs are really scheduled.

What changes were proposed in this pull request?

Validate cron expression in launch plan schedule when they are created or updated.

How was this patch tested?

1. unit test ✅
2. manually test ✅

Setup process

1. Bootstrap cluster

DOCKER_HOST="unix://$(echo ~/.orbstack/run/docker.sock)" flytectl demo start --dev
FLYTECTL_CONFIG=~/.flyte/config-sandbox.yaml
POD_NAMESPACE=flyte flyte start --config flyte-single-binary-local.yaml

2. Define a invalde cron schedule LP in py

# modify from https://github.com/flyteorg/flytesnacks/blob/0ec8388759d34566a0ffc0c3c2d7443fd4a3a46f/examples/basics/basics/launch_plan.py

from flytekit import CronSchedule, LaunchPlan, current_context

# Import the workflow from the workflow.py file
# in order to create a launch plan for it
from .workflow import simple_wf

# Create a default launch plan with no inputs during serialization
default_lp = LaunchPlan.get_default_launch_plan(current_context(), simple_wf)

# Run the launch plan locally
default_lp(x=[-3, 0, 3], y=[7, 4, -2])

# Create a launch plan and specify the default inputs
simple_wf_lp = LaunchPlan.create(
    name="simple_wf_lp",
    workflow=simple_wf,
    schedule=CronSchedule(schedule="* * * * MON#1"),
    default_inputs={"x": [-3, 0, 3], "y": [7, 4, -2]},
)

# Trigger the launch plan locally
simple_wf_lp()

# Override the defaults as follows
simple_wf_lp(x=[3, 5, 3], y=[-3, 2, -2])

# It's possible to lock launch plan inputs, preventing them from being overridden during execution
simple_wf_lp_fixed_inputs = LaunchPlan.get_or_create(
    name="fixed_inputs", workflow=simple_wf, fixed_inputs={"x": [-3, 0, 3]}
)

4. Register it!

pyflyte register launch_plan.py

Screenshots

Check all the applicable boxes

• I updated the documentation accordingly.
• All new and existing tests passed.
• All commits are signed-off.

Related PRs

Docs link

[welcome]

Thank you for opening this pull request! 🙌

These tips will help get your PR across the finish line:

• Most of the repos have a PR template; if not, fill it out to the best of your knowledge.
• Sign off your commits (Reference: DCO Guide).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 50.87%. Comparing base (25cfe16) to head (e467337).
Report is 2 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #5951       +/-   ##
===========================================
+ Coverage   33.09%   50.87%   +17.77%     
===========================================
  Files        1013     1164      +151     
  Lines      107489    89630    -17859     
===========================================
+ Hits        35570    45596    +10026     
+ Misses      68767    40005    -28762     
- Partials     3152     4029      +877     

Flag	Coverage Δ
unittests-datacatalog	51.58% <ø> (ø)
unittests-flyteadmin	54.07% <100.00%> (?)
unittests-flytecopilot	22.23% <ø> (ø)
unittests-flytectl	62.39% <ø> (-0.05%)	⬇️
unittests-flyteidl	?
unittests-flyteplugins	53.84% <ø> (ø)
unittests-flytepropeller	42.90% <ø> (ø)
unittests-flytestdlib	55.31% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kumare3]

Lgtm

[pingsutw]

lgtm, could you update the PR description

[peterxcli]

@pingsutw Thanks for reviewing this

PR desc updated!

please take a look, thanks!

[peterxcli]

Is the codecov decrement a normal situation? Maybe this additional validation make some test fail earlier, which are also expected to fail? Or just a unrelated flake?

[peterxcli]

Oh ok, checks passed after merging master branch😅

[welcome]

Congrats on merging your first pull request! 🎉