Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
AAP-17690 Inventory variables sourced from git project are not getting deleted after being removed from source #15928
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
base: devel
Are you sure you want to change the base?
AAP-17690 Inventory variables sourced from git project are not getting deleted after being removed from source #15928
Changes from all commits
9f294fd
178236c
7828164
748329e
1755f6d
f84a562
12b1d9a
9bd1a56
3510711
4c4cd8b
65b024b
b6c2af0
b7ae6a6
6ee08a0
50dac13
ef12483
10504fd
6b15185
349758b
a906012
6568948
7ac8dec
93dac5c
f7137ef
2dff649
a39469c
add8724
a186fa6
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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'd like to ask that someone, like @chrismeyersfsu weigh in on the choice of field type here,
JSONField
. There is some baggage with this, and I seejson.dumps
being used to save to this field.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.
For now I removed the superfluous
json.dumps
andjson.loads
in front of the JSONField. Thanks for the heads-up, I totally didn't see that.If @chrismeyersfsu has some concerns regarding the performance impact of a JSONField here, I could switch to a TextField with explicit serialization through
json.dumps
andjson.loads
.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.
Interesting method. I don't mean to criticize how you solved this problem, but I do want to share how I approached the same problem earlier.
https://github.com/ansible/test-playbooks/blob/main/inventories/changes.py
By using an inventory script, it's possible to put in dynamic values for either keys or values. In your case, a randomized key will result in the "old" key disappearing in a subsequent update. This can allow doing the same full-integration test without needing to run git commands.
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'll look into that!
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 wasn't aware that I can use script-generated inventory files here. Interesting approach, but I guess we cannot preserve state between subsequent calls to such a script. The challenge would be to know what to assert in the test function when we use, e.g., random or timestamp-based variable names.
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.
For the time being I would like to keep the test method simple, because it does verify the issue the PR is supposed to resolve, and I do not want to delay the merge of this PR longer than necessary.
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.
To say it out loud - it is my intent that running
git
commands in a subprocess is in scope for theawx/main/tests/live
tests. For other test suites, something like this would be a blocker, which is why I want to say it. In this space, it's okay to do this stuff.This was apparent as a use case from the get-go for issues like #13845