Add testing section for schedules, put schedule examples under test.
Details
Details
test docs build
Diff Detail
Diff Detail
- Repository
- R1 dagster
- Branch
- schedule_testing_story
- Lint
Lint Errors Severity Location Code Message Error examples/docs_snippets/docs_snippets/concepts/partitions_schedules_sensors/schedules/schedule_examples.py:54 E0102 Function Redefined - Unit
No Test Coverage
Event Timeline
Comment Actions
Still a lot of work to do here; putting schedule examples under test and screenshot build
| docs/content/concepts/partitions-schedules-sensors/schedules.mdx | ||
|---|---|---|
| 145 | I know this isn't directly relevant to this diff, but reading this now makes me feel like get_execution_data is a weird name. "execution" and "data" are both extremely general terms, and "execute" normally has a different meaning in Dagster. Also, "get" implies that we're accessing some attribute, rather than triggering some arbitrarily complex computation. Thoughts on renaming this to something like do_tick? @alangenfeld or @dgibson might have opinions. Also, whatever we name it, it's not included in the apidoc, so would be good to add it. | |
| docs/content/concepts/partitions-schedules-sensors/schedules.mdx | ||
|---|---|---|
| 145 | that makes a lot of sense to me as well. get_execution_data is confusing at best, misleading at worst, imo, without really telling you what the function is doing. | |
| docs/content/concepts/partitions-schedules-sensors/schedules.mdx | ||
|---|---|---|
| 145 | Related: ScheduleExecutionContext also feels like a rough name. Execution seems like it doesn't add anything, or fit into our meaning of execution. | |
| docs/content/concepts/partitions-schedules-sensors/schedules.mdx | ||
|---|---|---|
| 145 | Agree. Maybe ScheduleTickContext or ScheduleContext? | |