I’m using unarchive with copy=no and src=/tmp/archive.tar.gz dest=/wherever/ (i.e. the src is already on the machine and I just want to extract it under /wherever)
It’s currently failing on the _remote_md5 check - it should be returning the string “3” because it’s a directory (and running the code locally on the machine prints out 3 and then exits) but stdout is actually empty.
unarchive is in general a bit strange because it does an os.path.dirname on dest which actually removes the directory unless you add a trailing slash, even though this is not at all what the documentation suggests. I have a patch for that (https://github.com/willthames/ansible/compare/ansible:devel...willthames:unarchive_dest_fix?expand=1) but it doesn’t fix my md5 problem anyway (the only reason I tried it was to see if removing the trailing slash made the _remote_md5 test do the right thing)
Any thoughts? The main logic is in lib/ansible/runner/action_plugins/unarchive.py. I’m getting the message
dest /wherever must be an existing dir
“Fair point. I just want unarchive to work at all, and preferably as documented.”
Unarchive does have integration tests that proves it works in the integration test directory so it’s not like it doesn’t work at all, but it appears you have a bug report to file with copy=no, and there may be a problem there in some cases. That would be appreciated.
“My secondary question is whether people are happy with unarchive’s behaviour not being as documented”
I’m not sure why a blog post is a way to fix a project rather than contributing back to the documentation.
Both of these points you make seem to just involve a slight bug in the copy=no handling, which was added after the original functionality of the module, and I agree would benefit from extending the existing integration tests.
At the time I just thought it was odd - that note was really an aside in documenting how to use unarchive on already remotely downloaded artifacts. I didn’t think it was a way to fix the project.
However, now I think it’s a bug. And I’m happy to update the tests, and implement the fix.
Looking at unarchive, the problem is if the destination’s parent directory is not writable but the destination is writable. So e.g. for a standard user unarchiving into /tmp, it will fail through permission checks on /
The integration tests succeed if you’re running them as instructed as the root user because the writeability checks never fail.
I’ve added an integration test that fails test_unarchive if you run it as non root using --tags test_unarchive.