-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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 project_update role/collection install #14065
Conversation
It looks like project updates are failing with this change but the error handling in the smoke test isn't great
It should be relatively trivial to spin up the dev env and see what's going on. |
In the current system, it installs all files. I'm not sure if it would be preferable to install just 1, when all are present. We need some better establishment of the requirements here. |
Yes, currently all files are used, i thought that was a bug, it seemed preferable to have a single file with all the info vs letting the user 'partition' the info across 4 files. I have checked the few projects i have access to and none seems to use more than one file .. but i have no idea how representative that is. |
I agree with this, and want to ask @ffirg to look it over because it is a behavior change. IMO, it's a sensible change and we should merge it along with #14081, and then use it as an opportunity to better document the policy for which requirements files get installed. Changes:
|
Another change to the project update playbook has merged which is where the conflicts come from. I'm fine to make this change (although needs a release note) after a rebase. If you don't want to do the rebase, I can pick it up. |
i used the online editor, so i dont have a branch to rebase |
I rebased and pushed to your fork. Your change was only previously applied to 2 tasks, but @john-westcott-iv's overlapping change turned those 2 tasks into 3 tasks, so your pattern was applied to that new "unified" requirements.yml task. Also made small style changes to get all 3 tasks more consistent. I think this is ready for review and testing. |
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.
lgtm
Getting some more data now:
|
https://docs.ansible.com/ansible/latest/collections/ansible/builtin/first_found_lookup.html does vars:
req_file: "{{ req_candidates | first_found }}" need to be vars:
req_file: "{{ lookup('ansible.builtin.first_found', req_candidates) }}" |
- avoid looping - avoid using multiple files, only one should be provided and processed per type - use first_found and variables to locate existing file - skip if no file exists
-->
ISSUE TYPE
COMPONENT NAME
AWX VERSION
ADDITIONAL INFORMATION