Feat(cicd_bot): Allow forward-only plans based on branch suffix#4953
Feat(cicd_bot): Allow forward-only plans based on branch suffix#4953
Conversation
|
FWIW: a more general solution would be to allow more sophisticated commands. For example, we have customized our CI to allow things like: Which categorizes all changes as non-breaking. Similarly for model-a
In practice though, we've found that applying the same categorization on all changes typically works fine... |
erindru
force-pushed
the
erin/cicd-forward-only
branch
from
22cae4b to
4cd4d14
Compare
|
Thanks @plaflamme , we did discuss a more generic solution for specifying plan flags internally but ultimately decided to not go down that path just yet. Regarding categorization in particular, we noticed that most people are using auto categorization so we currently have no plans to provide an interface for manual categorization via the bot. |
| "> [!TIP]\n" | ||
| "> In order to see this forward-only plan retroactively apply to historical intervals on the production model, run the below for date ranges in scope:\n" | ||
| "> \n" | ||
| f"> `$ sqlmesh plan --restate-model {example_model_name} --start YYYY-MM-dd --end YYYY-MM-DD`\n" |
There was a problem hiding this comment.
| f"> `$ sqlmesh plan --restate-model {example_model_name} --start YYYY-MM-dd --end YYYY-MM-DD`\n" | |
| f"> `$ sqlmesh plan --restate-model {example_model_name} --start YYYY-MM-DD --end YYYY-MM-DD`\n" |
quick nit
| """> [!TIP] | ||
| > In order to see this forward-only plan retroactively apply to historical intervals on the production model, run the below for date ranges in scope: | ||
| > | ||
| > `$ sqlmesh plan --restate-model sushi.customer_revenue_by_day --start YYYY-MM-dd --end YYYY-MM-DD`""" |
There was a problem hiding this comment.
| > `$ sqlmesh plan --restate-model sushi.customer_revenue_by_day --start YYYY-MM-dd --end YYYY-MM-DD`""" | |
| > `$ sqlmesh plan --restate-model sushi.customer_revenue_by_day --start YYYY-MM-DD --end YYYY-MM-DD`""" |
same nit
erindru
force-pushed
the
erin/cicd-forward-only
branch
from
4cd4d14 to
b8433e9
Compare
themisvaltinos
left a comment
themisvaltinos
left a comment
There was a problem hiding this comment.
looks good to me, just a small nit typo in the alias
| pr_min_intervals: t.Optional[int] = None | ||
| prod_branch_names_: t.Optional[str] = Field(default=None, alias="prod_branch_name") | ||
| forward_only_branch_suffix_: t.Optional[str] = Field( | ||
| default=None, alias="foward_only_branch_suffix" |
There was a problem hiding this comment.
there is a typo in the alias foward instead of forward in case this affects the config
There was a problem hiding this comment.
Ah, thanks for spotting. The real question is why didn't a test fail 🤔
There was a problem hiding this comment.
Oh, test contains same typo 🤦
erindru
force-pushed
the
erin/cicd-forward-only
branch
from
3366622 to
e9d0a2d
Compare
erindru
force-pushed
the
erin/cicd-forward-only
branch
from
e9d0a2d to
549036c
Compare
4 participants
Prior to this, there was no way to trigger the CICD bot to perform a
--forward-onlyplan.This PR:
forward_only_branch_suffixwhich defaults to-forward-only. This means that any PR's where the git branch ends in-forward-only, egerin/update-sales-model-forward-onlywill have the--forward-onlyflag added to the PR environment and prod deployment plansThe
PR Environment Syncedstep looks like (notice the(Forward Only)indicators andforward_only=Truein the plan flags):The bot comment on the PR after prod deployment looks like:
