Add warning when later roles are overridden#48587
Closed
ianw wants to merge 1 commit intoansible:develfrom
Closed
Conversation
Contributor
|
Hi @ianw, thank you for submitting this pull-request! |
Contributor
Contributor
|
The test |
90c7599 to
109dda7
Compare
Member
|
CI failure in integration tests: https://app.shippable.com/github/ansible/ansible/runs/93400/65/console |
Contributor
Author
|
@mattclay would you have any suggestions here? When I run |
Member
|
This seems expensive to have in runtime, |
109dda7 to
2194e27
Compare
You currently don't get any sort of help diagnosing a situation where a role in a later entry of ANSIBLE_ROLES_PATH is overriden by a role with the same name earlier in the path. Although you can pick things out of the task paths from when it's running, since the names are the same (kind of the point :) it can be very confusing as to what's happening. This continues the path walk when importing the roles, and warns if you have later roles that are being ignored due to earlier matches. The documentation is enhanced to discuss the role import precedence. An integration test is added to match the new behaviour.
2194e27 to
2438834
Compare
Member
|
Hi @ianw, sorry for taking so long to get back to this. Unfortunately I think we're going to pass on merging this for now for the following reasons:
If you have any further questions, please let us know by stopping by one of the two mailing lists, as appropriate:
Because this project is very active, we're unlikely to see comments made on closed tickets, but the mailing list is a great way to ask questions, or post if you don't think this particular issue is resolved. Thank you! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
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.
SUMMARY
You currently don't get any sort of help diagnosing a situation where
a role in a later entry of ANSIBLE_ROLES_PATH is overriden by a role
with the same name earlier in the path. Although you can pick things
out of the task paths from when it's running, since the names are the
same (kind of the point :) it can be very confusing as to what's
happening.
This continues the path walk when importing the roles, and warns if
you have later roles that are being ignored due to earlier matches.
The documentation is enhanced to discuss the role import precedence.
An integration test is added to match the new behaviour.
ISSUE TYPE
COMPONENT NAME
playbook/roleADDITIONAL INFORMATION
This situation arose because we moved a role in our git tree. This particular role had a
filter_pluginso it actually left behind a__pycache__directory and.pycfile from when it had run. This meant we had essentially a blank role -- no tasks, variables or anything else in the role -- but it was still being picked up and "run". With no tasks it just appeared that the role was being read (I mean, therole: -roleinquestionwas not giving a not found error) but somehow doing nothing at all. This was even more vexing, as "git status" usually ignores.pycfiles so it was completely opaque as to what was going on, and it had only moved up a directory so you can very easily miss this in long paths.Of course, when it is explained, it all becomes rather obvious. However, I feel a warning like this would have made it much clearer much sooner. I think a warning is justified as it is best practice to avoid pointing guns at your foot by giving roles the same name.