-
Notifications
You must be signed in to change notification settings - Fork 289
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
Ci #1218
Ci #1218
Changes from all commits
ffcc4e0
85cfabe
7a17bb5
fad5f2e
b905546
3cef724
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 |
---|---|---|
|
@@ -3,8 +3,8 @@ ansible==7.0.0 | |
ansible-compat==3.0.0 | ||
ansible-core==2.14.2 | ||
docker==6.1.3 | ||
molecule==4.0.4 | ||
molecule-docker==2.1.0 | ||
molecule<5 | ||
molecule-docker @ git+https://github.com/ansible-community/molecule-docker@main | ||
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. Is there a reason to change the source to straight to github? 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. Yes, there's a fix that went in after 2.1.0, cb1c1c31a4a468fb243fc2000656504a3ca00bb3 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. Also, the repo is deprecated/archived, so there won't come any further changes to it, but I could pin it to the hash instead? We should probably go over to molecule 5, but I'd rather get these refactors in before overhauling the new molecule version. |
||
netaddr==1.2.1 | ||
pytest==7.2.1 | ||
pytest-testinfra==7.0.0 | ||
|
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.
Why do this? In my mind we should be testing against what we publish in the galaxy.yml file otherwise we may have an issue of experiencing/not experiencing failures that we should/shouldn't during CI/CD testing. Not to mention having to change versions in 5 places instead one 1.
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.
This part where galaxy looks up every single version, for every single dependency where we use
*
takes multiple minutes, multiply that by the matrix of configurations we're testing in github workflows, you're looking at a couple hours just to resolve these dependencies. (Yes, it's really that stupid, I've provided links to reported issues in ce6b2da)I think it's better we pin this for CI only, as a user could have installed a different collection that pins postgresql to X.Y.Z and if we're fine with that (given we set it to
*
), galaxy will say requirements are already met and leave it alone anyway, right?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.
Pinning in CI is not ideal, and especially since it's in this many places, but pinning in galaxy.yml would be the worse of two options.
In any case we should probably specify minimum requirements for all the
*
dependencies though.