Open m-khvoinitsky opened 1 year ago
I hit this also, trying to install Git from https://github.com/git-for-windows/git/releases/download/v2.42.0.windows.2/Git-2.42.0.2-64-bit.exe
FWIW, I switch the source to a different domain over https, and it worked. I seem to recall having some problem in the past relating to getting files from Github. It wasn't within Ansible but I believe the underlying problem was redirection handling.
Does this help you, @m-khvoinitsky : https://docs.ansible.com/ansible/latest/collections/ansible/windows/win_package_module.html#parameter-follow_redirects
FWIW, I switch the source to a different domain over https, and it worked. I seem to recall having some problem in the past relating to getting files from Github. It wasn't within Ansible but I believe the underlying problem was redirection handling.
Does this help you, @m-khvoinitsky : https://docs.ansible.com/ansible/latest/collections/ansible/windows/win_package_module.html#parameter-follow_redirects
At the moment I can't verify as currently the related code is a bit different. But it seems unlikely since doc says:
follow_redirects: "safe" ← (default), safe will follow only “safe” redirects, where “safe” means that the client is only doing a GET or HEAD on the URI to which it is being redirected.
I don't think that downloading a file requires something different than GET request.
Yeah, confirmed it doesn't work for me sadly (whether safe/all).
This is likely related to the format of the resultant links that Git provides from the redirect. For instance, this URL:
https://github.com/git-for-windows/git/releases/download/v2.35.1.windows.2/Git-2.35.1.2-64-bit.exe
...returns a 302 redirect that seems to change over time. The URL I was redirected to yesterday (that worked just fine then) returns a 401 today. But, the redirect takes the general form of:
https://objects.githubusercontent.com/github-production-release-asset-2e65be/23216272/ec06f3ce-e1e7-4785-9ca4-84b7efb3a906?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F<YYYYMMDD>%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=<YYYYMMDD>T<HHMMSS>Z&X-Amz-Expires=300&X-Amz-Signature=<big hex string>&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=23216272&response-content-disposition=attachment%3B%20filename%3DGit-2.35.1.2-64-bit.exe&response-content-type=application%2Foctet-stream
Notably, the redirected URL doesn't end with .exe
(with or without GET parameters). I'm not sure how to check this, but I wonder whether win_package
is downloading the file with a strange name such as ec06f3ce-e1e7-4785-9ca4-84b7efb3a906
. Or, given CreateProcess
's claim that it can't find the file to start, perhaps win_package
gets so confused by the redirected URL it fails to download any file at all.
Whatever the case, there are 3 reasonable ways I see for win_package
to get a usable filename in this situation:
Content-Disposition
header with the value attachment; filename=Git-2.35.1.2-64-bit.exe
. This probably should be checked for all downloads, even those where the filename provided by the URL seems reasonable.win_package
could be checked. In (some? most?) cases, this should provide at least the correct extension, which is (probably) all that really matters.extension
or filename
parameter could be added to win_package
.
SUMMARY
win_package doesn't work with https URL to msixbundle, only local URLs work
ISSUE TYPE
COMPONENT NAME
win_package
ANSIBLE VERSION
COLLECTION VERSION
OS / ENVIRONMENT
Controller OS: archlinux Target OS: Windows 10
STEPS TO REPRODUCE
This doesn't work:
This works: