Adjust application of cumulative_type_params to smooth out release process
#298
Conversation
|
Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide. |
courtneyholcomb
changed the title
cumulative_type_params
courtneyholcomb
requested review from
QMalcolm,
graciegoheen and
a team
as code owners
tlento
changed the title
cumulative_type_paramscumulative_type_params to smooth out release process
There was a problem hiding this comment.
This seems fine for now. The PR is like three changes in one, but they're all so tiny it seems silly to split them up. I decided to edit the PR title instead of thinking about this. Seemed like the best balance.
I leave it up to you if you prefer to restructure that test to clean up the conditional handling or just merge as-is.
| else: | ||
| assert len(build_issues) == 1 | ||
| expected_substr1 = "Both window and grain_to_date set for cumulative metric. Please set one or the other." |
There was a problem hiding this comment.
Ew. At least this is temporary.... I don't know that we have much choice given the way this test is structured.
If, instead, we could split the old-style test out from the new style we could just do pytest.mark.skip on the new bit and remove the validator from the DEFAULT_RULES list for now, but I don't know how worthwhile that is. It'll make this test cleaner, so it's not a total waste of time.
Description
2 adjustments related to
cumulative_type_params:SetCumulativeTypeParamsRuleto the set of transformations that actually get applied in prod & test.Also upgrades to a new production patch version so that we these changes can be used in
metricflow-semanticsappropriately.Checklist
changie newto create a changelog entry