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
Support in blueprint schema for input sections #110513
base: dev
Are you sure you want to change the base?
Changes from all commits
945a55b
e1e0605
5fe2888
2c9d1a0
7cca7a1
fd7dd77
703f445
ef031cd
58f68d9
c06074c
312a274
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,6 @@ | ||
# serializer version: 1 | ||
# name: test_extract_blueprint_from_community_topic | ||
NodeDictClass({ | ||
dict({ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe what is happening here is the inputs used to come from the yaml loader, so they were the special class |
||
'brightness': NodeDictClass({ | ||
'default': 50, | ||
'description': 'Brightness of the light(s) when turning on', | ||
|
@@ -97,7 +97,7 @@ | |
}) | ||
# --- | ||
# name: test_fetch_blueprint_from_community_url | ||
NodeDictClass({ | ||
dict({ | ||
'brightness': NodeDictClass({ | ||
'default': 50, | ||
'description': 'Brightness of the light(s) when turning on', | ||
|
@@ -194,7 +194,7 @@ | |
}) | ||
# --- | ||
# name: test_fetch_blueprint_from_github_gist_url | ||
NodeDictClass({ | ||
dict({ | ||
'light_entity': NodeDictClass({ | ||
'name': 'Light', | ||
'selector': dict({ | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,24 +26,38 @@ def blueprint_1(): | |
) | ||
|
||
|
||
@pytest.fixture | ||
def blueprint_2(): | ||
@pytest.fixture(params=[False, True]) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What I'm doing here (I think) is for every test that uses blueprint_2, I'm creating an additional variant that uses the same blueprint, except that the inputs are put into sections. This shouldn't functionally affect the test, so the test code should still pass equally whether the inputs are in sections or not. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, but for the final version of the PR, please add a new There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If I make an entirely new fixture, is it still possible to reuse the existing tests that currently consume blueprint_2? That's why I used the param so I can leverage and don't have to duplicate the tests. I'm not so familiar with pytest so the concept of how to run a test with multiple different fixtures I haven't grasped yet. |
||
def blueprint_2(request): | ||
"""Blueprint fixture with default inputs.""" | ||
return models.Blueprint( | ||
{ | ||
"blueprint": { | ||
"name": "Hello", | ||
"domain": "automation", | ||
"source_url": "https://github.com/balloob/home-assistant-config/blob/main/blueprints/automation/motion_light.yaml", | ||
blueprint = { | ||
"blueprint": { | ||
"name": "Hello", | ||
"domain": "automation", | ||
"source_url": "https://github.com/balloob/home-assistant-config/blob/main/blueprints/automation/motion_light.yaml", | ||
"input": { | ||
"test-input": {"name": "Name", "description": "Description"}, | ||
"test-input-default": {"default": "test"}, | ||
}, | ||
}, | ||
"example": Input("test-input"), | ||
"example-default": Input("test-input-default"), | ||
} | ||
if request.param: | ||
# Replace the inputs with inputs in sections. Test should otherwise behave the same. | ||
blueprint["blueprint"]["input"] = { | ||
"section-1": { | ||
"name": "Section 1", | ||
"input": { | ||
"test-input": {"name": "Name", "description": "Description"}, | ||
"test-input-default": {"default": "test"}, | ||
}, | ||
}, | ||
"example": Input("test-input"), | ||
"example-default": Input("test-input-default"), | ||
"section-2": { | ||
"input": { | ||
"test-input-default": {"default": "test"}, | ||
} | ||
}, | ||
} | ||
) | ||
return models.Blueprint(blueprint) | ||
|
||
|
||
@pytest.fixture | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The requests was to do the flattening in frontend, now the flattening happens in core instead if I understand it correctly. Will this have any side effect on existing blueprinted automations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reread the comment thread but I never saw a request to "do the flattering in frontend", or at least I missed that if it was implied.
I'm not quite sure what that would really mean anyway, don't I need to have a single list of inputs for core to iterate them for replacement?
I'm also not sure what the concern is here for backward compatibility, for BPs without sections (all of them today), isn't this block of code just basically a no-op?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flattening in frontend is what @bramkragten meant here: #110513 (comment) unless I misunderstand.
However, the solution you've come with seems fine too, I just want another pair of eyes on it.