-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix/stringify codes #459
Fix/stringify codes #459
Conversation
Codecov Report
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. @@ Coverage Diff @@
## main #459 +/- ##
==========================================
- Coverage 93.13% 93.05% -0.09%
==========================================
Files 123 123
Lines 5083 5096 +13
==========================================
+ Hits 4734 4742 +8
- Misses 349 354 +5
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Again, how were these failing tests not caught when the earlier pull request was made? |
Are the github actions configured to checkout the relevant branch when they run? I think actions/checkout uses the repository main branch unless told otherwise. |
Thank you for digging into this @SLornieCYC However, if we leave it to run on on the main branch, as it does now, then it checks if the incoming changes might cause the main branch to fail. This works sometimes (since some pull requests have failed tests while being on non-main branches) but seems to not work all the time. |
Can't you use the github environment variable there in place of E.g. something like: (Not 100% sure on the right syntax)
https://stackoverflow.com/questions/60300169/how-to-get-branch-name-on-github-action |
The previous change made on this branch, to change the rule codes to strings at the point where they are read into the registry, caused the in-rule-file tests to fail.
This was because, the type conversion happened in the validation func so that by the time the test_validation function was being run, the rule code had changed already.
For example, for a rule defined with
code=100
(int) the @rule_definition decorator will read it in, convert, then store it as a string. such that by the time we get to thetest_validate
function,assert
rule_code == 100
will fail. instead we'd have to do assertrule_code= "100"
Considerations:
The changes in this pull request implement the second consideration and updates the type expectation in the definition of
rule_definition
such that it expects only str rule codes and will flag if otherwise.